Re: display-buffer-alist simplifications

[martin rudalics]

> I'd make a "display method" be a function, i.e. one of
> `display-buffer-reuse-window', `display-buffer-pop-up-window', ...
> At which point you can get rid of the idea of a "macro specifier" since
> function definitions work just as well.

At which point you can give up the idea of merging.  I meanwhile know
that no one here likes the idea of merging specifiers and don't have the
slightest intention to fight for it any more.  But no one so far has
cared to explain how to support all the things people have piled up over
the years like split-height-threshold, even-window-heights, or
display-buffer-mark-dedicated.  I'd be all in favor of functions if you
told me how to write a function that within a year has not been
rewritten completely because it's oh so important to add a little thingy
here and there.

>>> (I'll use the word "macro" for now, but we might want to pick another
>>> word since "macro" can be confused with keyboard macros.)
>> I'd very much appreciate if someone could invent a more useful term for
>> these.
>
> The name exists already, it's called a function definition.  It's really
> well supported by a lot of Emacs code: you can document those "macros"
> in a very simple way, let users get that doc via C-h f, see them work
> step by step with edebug, have feedback about their correctness/style
> with M-x byte-compile-file, ...

We currently have many ways to specify a function for displaying a
buffer: `display-buffer-function', `special-display-function',
`pop-up-frame-function', `split-window-preferred-function', the function
one can specify via `special-display-regexps'.  I know of two people who
customized the latter - Drew and you.  This doesn't strike me as a story
of success.

>>> - `display-buffer-alist' is an alist that maps a matcher (regexp,
>>> label, or matcher function) to an alist of display specifiers.
>
> If display specifiers are of the form (VAR . VAL), then you presumably
> mean "a list of display specifiers" rather than "an alist of ...".

It's an alist where the key of each element is a display specifier.

>>> - `display-buffer-macro-specifiers' is an alist that maps a "macro
>>> specifier" to an alist of display specifiers.  It must include a
>>> `display-buffer-method' specifier.
>> OK.  We have to invent a mechanism that makes `display-buffer' work even
>> if someone removes more essential associations from the list.  The
>> SPECIFIERS argument below should be able to reference it safely.
>
> I hope by now you all know what I think of "macro specifiers".

They are what macros are: Rewrite rules for the users' convenience.

>> Good.  Would `display-buffer-fallback-alist' be constructed from the
>> user's Emacs 23 options, from the Emacs 23 default options, or be nil?
>
> I think that, as much as possible, the old options should only be used
> by the old code.  Trying to translate them into the new framework is
> generally a bad idea.  Especially if it may end up influencing the end
> design: let's first design something clean and flexible regardless of
> details of the old behavior.  Then figure out how to provide backward
> compatibility, without impacting the design.

OK.  I agree with the idea to support the old code and its options as
fallback and try to get a new behavior.  But what I'm missing is a
strategy for how to merge-in the re-bindings of the old options within
the old _and_ the new code.  Things like

(defun message-mail-other-window (&optional to subject)
  "Like `message-mail' command, but display mail buffer in another window."
  (interactive)
  (unless (message-mail-user-agent)
    (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))))

which I intended to rewrite as

(defun message-mail-other-window (&optional to subject)
  "Like `message-mail' command, but display mail buffer in another window."
  (interactive)
  (unless (message-mail-user-agent)
    (message-pop-to-buffer (message-buffer-name "mail" to) 'other-window)))

would then become

(defun message-mail-other-window (&optional to subject)
  "Like `message-mail' command, but display mail buffer in another window."
  (interactive)
  (unless (message-mail-user-agent)
    (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) 'other-window)))

for approximately as long as how we are supporting the old code.

Or am I missing something?

> So, as is the case now, your list of specifiers is not truly an alist
> (i.e. earlier elements don't override later elements), instead it's
> a mix between an alist and an `or block'?
> That sounds like a problem.

If someone told me how to address the problem of merging specifiers in a
different way I'd be all ears.  So far people addressed purely cosmetic
issues like using a function instead of a macro or a plist instead of an
alist.

martin