[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: display-buffer-alist simplifications

From: martin rudalics
Subject: Re: display-buffer-alist simplifications
Date: Mon, 18 Jul 2011 20:52:50 +0200
User-agent: Thunderbird (Windows/20090302)

> We can combine them with a "a\\|b\\|c" regexp.

I wonder whether users who don't know much about regexps would like such
a thing but it can be obviously done.

> I don't even know why you added the `label' case, so I don't think we
> should worry about adding more types.

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.

> More generally, I have the impression it's a bit overengineered.
> I can't find any comment anywhere that explains/justifies
> the complexity.  Could you explain it here to help us refine the design
> (or to add the explanation to the code)?

The complexity derives from the complexity of `display-buffer' and
probably from an attempt to handle each possible variant.  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?  I don't
know how many times I went through the code of
`special-display-buffer-names' but I know that I still don't understand

> AFAIK, the only feature I know to be needed compared to what was
> provided in Emacs-23 is a parameter `where' to display-buffer which
> generalizes the `same-frame' parameter by turning it into a value of the
> `where' and allowing other values such as `same-window' or
> `near-minibuffer'.

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]