[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: display-buffer-alist simplifications
From: |
martin rudalics |
Subject: |
Re: display-buffer-alist simplifications |
Date: |
Sun, 17 Jul 2011 11:41:46 +0200 |
User-agent: |
Thunderbird 2.0.0.21 (Windows/20090302) |
>> - 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.
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