Re: display-buffer-alist simplifications

[martin rudalics]

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

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.

> 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?  If
not, please take a look there and tell me what is missing.  It's
difficult to adapt a manual text to constantly changing design requests.

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

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

Let's agree to disagree on that.  `special-display-buffer-names' had
only one serious user, namely Drew Adams.  I know that because my
rewrite had a number of bugs which we eliminated in a period of two
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.

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

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

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.
Side windows are a first step in solving the problem of how to implement
IDE like window configurations without having to advise basic functions
like `delete-other-windows'.  Both are described in separate sections of
the manual in the window-pub branch.

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

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

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

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

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.

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

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

martin