Re: display-buffer-alist simplifications

[martin rudalics <rudalics@gmx.at>]

 > This is not important.  If this is an issue, it would be cleaner to use
 > global variables to specify defaults.

FWIW, that's the Emacs 23 way of handling this.  The global variables
are `pop-up-windows' or `split-height-threshold' and to override them
you can use `special-display-regexps' with a user defined function.  The
problem with such an approach is that you have to explain precedence in
the doc-strings like that from `special-display-regexps' saying

   If this variable appears \"not to work\", because you added a
   name to it but the corresponding buffer is displayed in the
   selected window, look at the values of `same-window-buffer-names'
   and `same-window-regexps'.  Those variables take precedence over
   this one.

or leave things completely unexplained as for `pop-up-windows'

   Non-nil means `display-buffer' should make a new window.

failing to mention that this is overridden by practically all other
options.

Not to mention that global options inevitably provoked two developments:
Applications overriding them in all sorts of ways and users asking for
adding more and more options like `display-buffer-reuse-frames' -
apparently a workaround for Emacs' inability to raise frames with some
window managers - or `split-window-preferred-function' with people
asking over and over again how to turn off horizontal splitting.

 > IIUC, the current system also has a limitation: there is no way to use
 > display-buffer-alist to tell Emacs to apply even-sizes selectively,
 > e.g. only when reusing a window already containing the buffer.

Did you tried doing

(setq
  display-buffer-alist
  '((((regexp . ".*"))
     (reuse-window other same)
     (reuse-window-even-sizes . t)
     (reuse-window other other)
     (reuse-window-even-sizes . nil))))

It works for me here.  That is, if I want to display *scratch* and
another window shows it already, window sizes are evened out.  If no
other window shows it, window sizes are left alone.

Things like reuse-window-even-sizes are relicts from the days when most
users were happy to accomodate two windows within a frame.  It's hardly
suited for frames showing more than two windows.  Anyway, it comes from
a global option, currently enabled by default, so I have to respect it
for compatibility reasons.  It's hardly justifiable to bother users with
repeating their settings for all `pop-up-window' specifiers, though.

 > I think this indicates that the idea of "merging" specifiers is flawed.

Hopefully not.  IMHO not merging specifiers would be a real pain.  You
couldn't manage the size of `display-buffer-alist' after a few months.

 > display-buffer-alist is trying to serve two purposes: "merging"
 > specifiers passed to display-buffer, and "overriding" them completely.
 > That makes it very complicated to use/understand.

Merging should be the rule.  Overriding should happen only in a few
cases, when a user is completely dissatisfied with the application's
specifier.  In practice, this means that we can either tell a user on
Emacs-devel something like "this should get fixed by the application
soon, meanwhile try to override this by ..." or "the behavior you want
is very unusual so could you please try overriding it by ...".

 > Why not let display-buffer-alist exclusively perform the "override"
 > case---i.e. let it take precedence over display-buffer's argument
 > specifiers?

Impossible.  The first consequence of this would be applications
rebinding `display-buffer-alist' to nil around `display-buffer' calls.
How would you implement `info-other-window' or `find-file-other-frame'
when the user has a `display-buffer-alist' entry for *Info* or the file
in question?

 > As for the "merge" functionality, some of it is already handled using
 > global variables, like `even-window-heights'.  In the future, we could
 > provide a more versatile way to do merging (e.g.  provide an abnormal
 > hook that accepts the display specifier that Emacs is told to use, and
 > return a modified specifier for it to actually use).  But I think we can
 > defer that part to post-24.1.

These Emacs 23 options are converted to buffer display specifiers which
`display-buffer' handles just like any other display specifiers supplied
by `display-buffer-alist' or the application.  The main idea of
`display-buffer-alist' is to obsolete all these "global variables" in
favor of one.

martin