Re: display-buffer-alist simplifications
Juanma Barranquero
> 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
martin rudalics
>> 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.
I just took this over from `special-display-regexps',
`same-window-buffer-names' and friends. So I'd like to have an opinion
from people with some practice in customizing these options.
>> - 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'.
This was an attempt to unify things like `special-display-regexps` and
`special-display-buffer-names' into one option. Can we say, in
retrospect, that having kept these two options distinct was not TRT?
>> - 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!
Hmmm... As I tried to explain there are two types of contradictions.
Some of them are dynamic and some of them are static (and, if such a
specifier is used as argument, can be even detected at compile time).
So I do have to rewrite the doc-string.
>> - 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!!!
OK. I'll look into this.
martin
martin rudalics
> 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.
I currently produce these via `display-buffer-alist-set'. But Sam
Steingold earlier bemoaned that
> it produces a lot of separate entries like
> (((name . "*acl-listener*"))
> fun-with-args
> (fun-with-args special-display-popup-frame #1#))
> (((name . "*scheme*"))
> fun-with-args
> (fun-with-args special-display-popup-frame #1#))
> (((name . "*allegro*"))
> fun-with-args
> (fun-with-args special-display-popup-frame #1#))
> (((name . "*cmu*"))
> fun-with-args
> (fun-with-args special-display-popup-frame #1#))
>
> I think it would be better to group them together like I do above.
and I think he's right. So I'd rather keep the list approach here (but
can be easily convinced of the contrary ;-) ).
> - 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.
Stefan earlier suggested something similar last year. I can do that
easily but it somehow precludes that we add other string- or symbol-like
types later (not that I can give or even think of an example). So if
people agree on this, I'll do it.
> - 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?
Hopefully that `display-buffer' can't find a window meeting this
specification. It's obviously a static case which means it could be
detected at the time the user sets the customization.
> And what happens if it's
> impossible for Emacs to meet the requirements of the specifier? This
> is not explained in the docstring.
It's not taken. Like when you specify to use the selected window if it
shows the same buffer and the selected window shows another buffer. Or
you want to split a window but `display-buffer' can't find one which is
large enough.
> - 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.
That's an incorrect deduction, probably because the doc-string is
written badly. If you add
(reuse-window (reuse-window-even-sizes . t))
as last element to `display-buffer-alist' it will apply to all
reuse-window operations that don't override it.
> 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.
I haven't looked into how to present plists in the customization
interface. If I find a good way to do it, I'll make that change.
martin