Re: display-buffer-alist simplifications

[Stefan Monnier]

>>>> 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.
> Have you ever tried the customization interface of
> `display-buffer-alist'?  What's so frightening about it?

I'm not yet concerned about the ease of customizability.  I'm concerned
about the complexity of the semantics.

And I'm concerned about the ease with which someone will be able to
replace display-buffer-alist with something better 10 years from now
while preserving the compatibility with your (then legacy) code.

> When labels were discussed on emacs-devel you wrote:

>   I might want that, indeed, but what I wrote above is not directly
>   related, it's just that if ediff uses symbols `ediff-A' and `ediff-B',
>   I might like to be able to have a single entry that covers both (and
>   covers the ediff-ancestor one as well).  That would naturally extend to
>   a more general form of classification of buffers (e.g. `ediff' for all
>   things related to ediff... I'd probably also like to be able to use
>   a major-mode name as a classification).

> If you meant something different than what I implemented you should tell
> me (1) what you meant then and (2) how you wanted that implemented.  If
> all you meant in that text was to _not_ provide labels you should simply
> have said so then.

Ah, so that's what labels are for, now that makes more sense.  But then
`switch-to-buffer' should not be a label.  The labels I want are about
the "kind of buffer", not "the command used to display it".  The reason
for such a label is that buffer-names aren't good enough.
Maybe we can rely on major and minor modes instead, BTW.

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

> Have you ever looked into the Elisp manual of the window-pub branch?

No.  Any reason it's not in the trunk yet?
I had the window-pub moved to old-branches because I thought it had
been merged.

> If not, please take a look there and tell me what is missing.

I just looked at it but I don't see any rationale for the design.
I only see a description of how the specifiers work (which is fine for
the Lispref, BTW: what I'm asking is not documentation for users of the
feature, but a rationale that explains how you got to this design).

>> 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 current trend intitiated by Chong aims at reducing expressiveness.
> How do you want me to reconcile your proposal with this trend?

As explained already, I don't understand the current design, so I'm just
throwing out random comments which shouldn't be taken too seriously.

Note that I generally try to design things to be simpler and more
expressive (I don't see a contradiction here, because the
expressiveness is obtained by adding a few "hooks" where random elisp
code can be plugged).

> weeks mostly by trial and error.  In all that time no one else
> complained.  I suppose you use it as well but since you apparently
> advice `display-buffer' (or some subset of its routines) you were not
> hit by these bugs.

No, I don't advise display-buffer, and yes I was hit by these bugs as
well but was busy with other things, and Drew took care of the bug
reporting for me ;-)

> `special-display-buffer-names' is complex because it prescribes behavior
> for reusing the same window, reusing some other window on the same
> frame, popping up a new window, reusing a window on another frame and
> popping up a new frame.  That's the kind of expressiveness Drew needs
> because he's got no other choice.  It's far too expressive for all other
> users.

- the same-frame and the same-window parameters are one needed
  complexity.  But these should be consolidated into a single `where'
  parameter which could specify same-frame, same-window, and many other
  things (e.g. near-minibuffer).
- I don't see how you can specify "reusing a window on another frame" in
  special-display-buffer-names.
So I don't see the enormous complexity.  It's basically just:
- pop up a new frame and mark it dedicated.
- except when `where' says otherwise.
- and except for the hook case (where you can say "use this function to
  display the buffer").
The hook case gives you a lot of expressiveness since you get complete
control, but it adds very little complexity to the design.

There is added complexity coming in with the interaction with
pop-up-frames which also causes frames to be popped up, but they are not
marked dedicated, but that's another issue.

> Atomic windows were discussed in a thread on how to implement tabs in a
> separate window since you were opposed to using the headerline for them.

I don't think we should try and provide support for atomic windows with
display-buffer.  At least not yet.  I expect that any place where we
might want to use atomic windows will need to set things up
manually anyway.

BTW, I don't see any use of this feature in the window-pub branch.
Do you have some sample code showing how it works (the minimap package
in GNU ELPA seems like a good candidate)?

Same remark (don't integrate support for it in display-buffer, yet) and
same question (do you have sample code using it, ideally some attempt at
making ECB use that feature?) for side-windows.

>>> 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.
> So either you read the manual from window-pub or you have to wait until
> I rewrote the manual for the trunk and we continue the discussion from
> there.

I'm not asking for "what does it do" (that which needs to be in the
manual), but "why did you add it, which use-case prompted you to add it
and what alternative solutions did you throw out" (things which are
typically not added in a manual, but could be welcome in the Commentary
section of window.el).

To take a concrete example: what use-cases did you have in mind that
required going from the 4 different cases of the old code
(i.e. `same-frame', `same-window', `new-frame-non-dedicated' and
`new-frame-dedicated), which in my mind should be something like
4 different values of the `where' parameter, to:
- `reuse-window' with 3 extra parameters.
- `reuse-window-dedicated' (AFAIK this is only used in switch-to-buffer
  so it's not clear why it needs to be supported in display-buffer).
- `pop-up-window' with a host of different values.
- `pop-up-window-split-unsplittable'.
- `pop-up-frame'.
- ...

...[time passes]...
...[BTW, could someone rewrite the docstring of display-buffer-alist to
use things like "if it has the form (label LABEL)" rather than "if it is
a cons cell whose car is `label'"?]...

IIUC the reason why you don't have just a single `where' parameter is so
that the merge between the specifiers given in display-buffer and
display-buffer-alist can be more fine-grained, right?  What were the
use-cases where you thought that was important?

>> 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.
> It is nil for a couple of weeks now.

Yes, I saw that, thank you.

>>> 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.
> The rule is simple.  You scan a list of expressions until you find the
> first method specifier that delivers a result.  You scan the tail of the
> list for the first additional specifier that is needed for implementing
> a specific behavior like evening window sizes and use it.

The problem I have with it is that the specifiers thingy acts in
2 different ways:
- an alist for some kinds of parameters, like the old special-display-regexps.
- an `or' that tries elements one after the other until one succeeds.
That adds conceptual complexity.

Along the same idea, some parameters that refine the way `reuse-window'
works are passed as "args" to `reuse-window' while others are provided
separately as specifiers.  That also adds conceptual complexity.

If we're willing to use a single `where' and give up on the finer
grained merging, then the specifiers can really be an alist, the
`where' parameter can be defined to always be a function (i.e. it's
somewhat like your `function' specifier) and we can cut down the
docstring of display-buffer-alist by a crap load, it just needs to
mention typically useful values of this parameter, such as
`display-buffer-same-window', or `display-buffer-same-frame' and those
functions can then document that they understand params such as
min-height.

This is still very flexible (except for the merging, obviously), since
you can write any function you want for the `where' arg.

> I'd immediately jump at any suggestion that is compatible with Emacs 23
> options.  Unfortunately, till now the discussion didn't get us very far
> because I didn't get satisfactoy answers on how to stay compatible with
> the behavior of Emacs 23.

Compatibility seems under control (not quite perfect, but you've been
very good with fixing the issues we bump into).

> Making a frame either succeeds or fails in one attempt.  But when one
> method for displaying a buffer fails, another one must be tried ...

In my experience when the preferred method fails, it's sufficient to
fallback on the default.  Do you have use-cases where this is not true?


        Stefan