Re: display-buffer-alist simplifications

[martin rudalics]

>> why do you think it's better to pay for removing the (override . t)
>> entries (which should be fairly rare BTW) with another variable and a
>> doc-string that would either have to refer to that of
>> `display-buffer-alist' or replicate most of the latter.
>
> Because that would simplify the meaning of both variables, by making
> every specifier be a particular way to finding a window to display
> in---with no exceptions.

This is not an argument for using two variables.  The "making every
specifier be a particular way to finding a window to display in---with
no exceptions" can be applied to the current one variable approach as
well.

> One cost is that, from your previous message, it conflicts with using a
> plist syntax like
>
>   (display-buffer buf
>     '((reuse-window :buffer same :window other)
>       (pop-up-window :root lru :side right :min-width 10)))
                       ^^^^^
                       :window

It conflicts only in the sense that a value may be non-scalar like a
list because you would have to say something like

'((reuse-window :window-buffer-frame (other same)))

instead.  But a list-like value would be needed anyway for the
`pop-up-frame-alist' specifier.

> This syntax is (IMO) much more readable.  It is easy to guess what every
> element means---one problem I have with the current design is that I
> have to delve into the docstring to work out what the different elements
> and special tags mean.  And it has the advantage of similarity with
> other facilities in Emacs, like defface specs.

Agreed.

> I like the display specifier argument to `display-buffer' (with the
> aboves changes to the syntax to make them easier to understand); it
> seems like a real improvement in the way Lisp programs handle window and
> buffer switching.
>
> What I find problematic is `display-buffer-alist' and specifier merging.

As I explained earlier, you don't have to merge specifiers for
processing `display-buffer-alist'.  If you really want to avoid that, I
can fill in the unspecified elements so there's a 100% guarantee that no
merging occurs within the elements of `display-buffer-alist'.  Which
means that the above specifiers would become semantically equivalent to

 '((reuse-window :buffer same :window other :frame nil :even-sizes t
                 :dedicated nil :dedicate nil :no-other-window nil)
   (pop-up-window :window lru :side right :min-height 40 :min-width 10
                  :desired-height nil :desired-width nil
                  :split-unsplittable nil :no-other-window nil))

But if you want to process the `display-buffer' argument, you have to
merge.  You can't ask all applications that call `display-buffer' to
provide all possible specifiers in the argument.  So you have to merge
in the rest from `display-buffer-alist' or `split-height-threshold',
`special-frame-alist', `pop-up-frame-alist', ....  And I can't merge in
default specifiers as for `display-buffer-alist' because I have to
remain compatible with the Emacs 23 behavior where option values are
merged in.

> I don't like the idea that each specifier lacks a self-contained
> meaning, because it can be modified by other specifiers.  IIUC, even
> with these complications it's still not as flexible as real Lisp code
> (e.g. in situations where you want to merge in a specifier if and only
> if the original specifier had some specific form).

You would have to give me an example here.

> My inclination would be to keep the display specifier argument to
> `display-buffer', switching to the plist syntax, but leave out
> `display-buffer-alist' until we can work out a better way to do merging
> (e.g. in 24.2).

I don't understand you.  If we want to process the display specifier
argument, we have to merge.  If, with Emacs 23, the second argument of
`display-buffer' is non-nil, all `display-buffer' does is to mark the
selected window as not usable.  It merges in the values of all relevant
options wrt finding a suitable "other" window.  Note that Emacs 23 even
merges when you don't provide the argument.  For example, the call in
`message-mail-other-window'

    (let ((pop-up-windows t)
          (special-display-buffer-names nil)
          (special-display-regexps nil)
          (same-window-buffer-names nil)
          (same-window-regexps nil))
      (message-pop-to-buffer (message-buffer-name "mail" to))))

merges in the value of `split-height-threshold' (which can have the
effect of not popping up a new window but reusing an existing one) and
`even-window-heights' (which may adjust the height of a reused window).
And, if `pop-up-frames' is non-nil, it will merge in the values of
`pop-up-frame-function' and `pop-up-frame-alist' too.

> This way, the display specifier functionality is at
> least accessible to Lisp programs for 24.1.  Do you think this is
> feasible, or do you think that it's impractical, e.g. because the plist
> syntax is fundamentally incompatible with merging?

The display specifier argument is already there.  But in its current
implementation it gets merged.  That is if you call

(display-buffer
 "*scratch*"
 '((reuse-window other same) (reuse-window other) (reuse-window-even-sizes . 
t)))

the two attempts to reuse another window will both try to even sizes.
And if you do

(display-buffer
 "*scratch*" '((reuse-window other same) (reuse-window other)))

it will try to even window sizes provided `even-window-heights' is
non-nil.  So nothing would be gained wrt your concerns.

> If so, it might be
> good to revert everything and postphone these changes to 24.2.

I intend to start doing that by the end of the week ;-)

martin