emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: display-buffer-alist simplifications


From: Juanma Barranquero
Subject: Re: display-buffer-alist simplifications
Date: Sun, 17 Jul 2011 03:38:30 +0200

On Sat, Jul 16, 2011 at 22:35, Chong Yidong <address@hidden> wrote:

> Here are several suggestions, and one question.

>From someone who has read the docstring of `display-buffer-alist' once
too many and gleaned way too little meaning from it (no offense,
Martin, I love your work, just not this variable's doc)...

>  - Instead of allowing the car of each `display-buffer-alist' element to
>   be a _list_ of matchers, let it just be a matcher.  This is
>   semantically cleaner, and more consistent with other facilities in
>   Emacs, e.g. font-lock-keywords.  Any caller desiring multiple
>   matching conditions can just add multiple alist elements.

Well, perhaps. No biggie IMHO.

>  - Instead of buffer matchers that are cons cells like (name . NAME),
>   (regexp . REGEXP), and (label . LABEL), just use strings or symbols.
>   Strings are to be treated as regexps (if an exact match is desired,
>   the caller uses regexp-quote); symbols are treated as label matchers.

Yes, though the `name' case is perhaps common and it's a bit of a PITA
having to go through `regexp-quote'.

>  - Some of the display specifiers seem to allow contradictory meanings,
>   e.g.
>
>      (reuse-window same nil other)
>
>   means to reuse the selected window, provided the window is not on the
>   selected frame.  What does this mean?  And what happens if it's
>   impossible for Emacs to meet the requirements of the specifier?  This
>   is not explained in the docstring.

Yes!

>  - I don't like the fact that different specifiers are set up in a way
>   that the meaning of each specifier depends on the presence of other
>   specifiers.  For example, in the spec list
>
>   ((reuse-window same nil nil) (reuse-window-even-sizes . t))
>
>   the second element only has a meaning if the first element is
>   present---they are not independent.  It would be cleaner to use a
>   plist, like this:
>
>    (reuse-window :window same :reuse-window-even-sizes t)
>
>   where ALL the behaviors are grouped together.

YES!!!

    Juanma



reply via email to

[Prev in Thread] Current Thread [Next in Thread]