Re: display-buffer-alist simplifications

[Stefan Monnier]

[ Joining the thread after a leave of absence.  ]

>> 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.

If they're afraid of regexp, they'll run away screaming from
display-buffer-alist (and probably from Emacs as well).  So I'm not
too concerned.

>> 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.

I can guess that from its "definition" but that doesn't tell me why you
considered it was worth adding.  That's really what I'm generally
asking: a rationale document/comment that explains for each feature why
it was added (with concrete use cases).  Without it, it's difficult for
me to understand why we have so much complexity here.

BTW, rather than select based on a `label' may we should make it
possible for the user to set parameters that depend on the caller's
params, and/or on the place where the buffer gets displayed (whether it's
reusing a window, using a new frame, ... which of course could only
apply to params that do not influence which window to use).

> 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?

Of course:
- special-display-regexps is a strict superset of
  special-display-buffer-names, so we can remove
  special-display-buffer-names (modulo backward compatibility).
- same for same-window-buffer-names and same-window-regexps.
- AFAIK the same-window param of special-display-regexps also makes
  special-display-regexps a superset of same-window-regexps.
So from a complexity point of view, there are just 4 redundant ways to
do the same thing.  Whereas display-buffer-alist adds many more things
we can do, so it adds a very different kind of complexity.

The way to think about it is: imagine when you did your rewrite, the
thing to which you needed to preserve backward compatibility was not
special-display-regexps but display-buffer-alist.  That would be
insanely more difficult.

> 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 it.

Yup, and your code is even more complex.

> 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'.

I don't know what are atomic windows, nor side windows.  I don't know
when they might be used either, nor where they've been requested.
And neither do I know why they should be introduced by display-buffer.
So, as explained above (and in my previous email), I need a rationale
giving concrete usage example for each such feature, without which this
all seems way too complex.

> 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.

I can't tell you that without first knowing what each thing is used for.

Eli wrote:
> A comment from a naive bystander: these values are getting more and
> more close to Lisp code than to a value of a user variable.  Aren't we

Very true.  And in the Lisp world, we generally know very well how to
solve this problem: push the complexity to the point where any Lisp is
allowed, at which point it suddenly becomes a lot simpler and powerful
since you can just say "any Lisp expression".

I suspect that such a change could tremendously simplify the design,
while making it even more powerful.

BTW, I also agree with Jury that display-buffer-alist's default value
should be nil, to make it easier to change the default behavior (which
is hence kept elsewhere) in the future.

Martin wrote:
> The question whether and how to merge such a specifier is central to the
> question whether we should change the semantics of the not-this-window
> argument of `display-buffer' at all.

I think some form of merging is indispensable, but the rule should be
simple.  I don't know in which way the needs of merging influence the
current design, so again I can't judge the current design without first
some kind of explanation showing use cases, the problems they introduce
and the solution(s) you provide.

> Since most people do find `display-buffer-alist' much too complicated
> and Stefan is apparently opposed to almost all new features it provides,

That's a misunderstanding.  I only have a gut-feeling that we can
provide the same features (or even more features) with a simpler design,
and furthermore I can't intuitively see how you got to the current
design, so I'd like to pick your brain to understand your motivations.
The end result may very well be "Aha! Yes, your design makes a lot of
sense!".

> we should seriously consider reverting the changes
> introduced by buffer display specifiers.  In this context it makes
> also sense to discuss whether the Emacs 23 system is or is
> not complicated.

I don't much like the Emacs-23 system, largely because it is not
powerful enough.  So, no, going back is not a good option either, I think.

Eli wrote:
> Alternatively, we could postpone the pretest and invest the time into
> this issue now.

Indeed, I think that's what we should do.  This is an important matter
that's been a source of problem for Emacs users such as myself for
a long time, it's time to fix it.

Chong wrote:
> Another difference is that in default-frame-alist, each stored value
> (i.e. the cdrs of an alist entry) has a straightforward meaning: it is a
> value of a frame parameter.  In display-buffer-alist, each stored value
> is a _list_ of specifiers, and each specifier has its own no-obvious
> meaning.  For example, in the specifier

Indeed.  To me that's one of the reasons why I think
display-buffer-alist needs to be improved: each param should be as
clear, simple, and independent as is the case for frame params.
Ideally that is: before deciding it's actually true, I need to understand
why it's not already the case.


        Stefan