[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 (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.


reply via email to

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