Re: display-buffer-alist simplifications

[martin rudalics]

> I meant "user-specific behavior can override the _default_ and
> function-specific behavior", i.e. I forgot to mention that
> users can override the default behavior as well.  If now the default
> behavior is based on the users old settings, then users new settings
> should override them.  For instance, when old customization in .emacs
> sets `pop-up-frames' to t, and the user customizes `display-buffer-alist'
> to not create a frame, then settings from `display-buffer-alist'
> should override the old settings `pop-up-frames'.

That's what the current code does, hopefully.

> My concern is how users will be able to override parts of the
> default behavior?  For instance, how users can specify a rule
> to override the default and to not to balance/even window sizes?
> I understand that using settings like (reuse-window-even-sizes . nil)
> and (reuse-window-even-sizes . t).

Yes.

> How easy is to add new macros like `near-minibuffer' and `below-selected'?
> Can users add own macros?

Currently there's only the constant `display-buffer-macro-specifiers'.
I made it a constant because I considered modifying it unsafe.  We could
make it customizable.

> I'm sure that most authors will be lazy or forget to add labels.
> And how users are supposed to deal with the lack of labels?
> Should they send mails to the authors asking them to add labels?
> Honestly, I think adding labels was good intention but they are useless.

Maybe.  I have no strong opinion.

> For some exceptional cases where it's impossible to override the
> function-specific behavior based on `buffer-or-name' or `this-command',
> then a label could be specified as part of specifiers like
> `((label . "info-other-window") ...)'.
>
> Or maybe we can't remove the 3rd argument of `display-buffer'
> for backward-compatibility with the old version that had 3 arguments,
> so we should keep the 3rd argument and use it for something?

That was part of the idea of the labels concept.

martin