Re: display-buffer-alist simplifications

[Juanma Barranquero]

On Mon, Jul 18, 2011 at 20:52, martin rudalics <address@hidden> wrote:

> The label case would specify the calling function so users can change
> the behavior if the name of the buffer is not distinctive enough.  It
> can be easily removed if people think it's not needed.

No, I think it can be a very useful last resort and would like it to be kept.

> Emacs 23 was
> not less complex in this regard: If you wanted to display a buffer in
> the same window, you had at least four options to say so, namely
> `same-window-buffer-names', `same-window-regexps',
> `special-display-buffer-names' and `special-display-regexps' all with a
> separate documentation of the individual behavior, leaving mostly
> unexplained which option prevailed.  `display-buffer-alist' provides one
> specifier to do that.  Do you really think `display-buffer-alist' is
> more complex than the four options listed above taken together?

FWIW, I couldn't agree more with this.

> Admittedly, atomic windows and side windows provide some considerable
> additional complexity but there have been frequent requests that putting
> a buffer into a window should practically always pass through
> `display-buffer'.  Although I don't necessarily share that opinion I
> tried to incorporate them in the design.  And people don't have to care
> about these as long as they don't need them.  But I have no problems
> removing support for them either.
>
> There have been requests that `display-buffer' should be able to set the
> size of a popped-up window and optionally specify a function to set the
> height by calling a function like `fit-window-to-buffer'.  These can be
> easily removed and we get a doc-string that is 35 line shorter.  So
> we've got plenty of room for down-engineering `display-buffer-alist'.
> Just tell me what you want to remove.

IMHO, you've taken a lot of time to think of this, and the added
complexity, if any, is added flexibility.  I think we should strive to
make the current funcionality of your changes clearer and better
documented. If we stat removing things now, we'll be doomed to re-add
them some day, not long, when people starts to ask for ways to make it
work like it was before (you've seen enough of my private bug reports
to know how true that is ;-)

    Juanma