Re: display-buffer-alist simplifications

[Stefan Monnier]

>>> The absurd consequence of this is that with `pop-up-frames' non-nil
>>> `ctl-x-4-map' becomes identical to `ctl-x-5-map' and
>>> `find-file-other-window' an alias for `find-file-other-frame'.  You
>>> won't find any explanation of this phenomena in the doc-strings of
>>> `pop-up-window' and `pop-up-frame' or in the documentation.
>> This just goes back to the problem of code let-binding pop-up-<foo>
>> instead of providing a SPECIFIER/RULE argument to display-buffer.
> Unfortunately not.  An OTHER-WINDOW argument must sill be interpreted
> consistently with what the user expects.

I don't know what you mean, here.

> The other-window-means-other-frame specifier I use is a gross hack in
> this regard.  I suppose that if I had known about this issue from the
> very beginning, I would never have started to rewrite `display-buffer'
> which would have spared us the present discussion.

I don't know when/why other-window would mean other-frame.

>>> It shouldn't be up to the code to decide whether a window shall be
>>> reused.
>> I already said that same-frame and same-window parameters in
>> special-display-regexps were mistakes, so there's no point complaining much
>> more about their quirks.
> This is not about the same-frame and same-window parameters.  It's about
> the reuse-window-already-showing-the-buffer part.

[TOBEFILLED]

>> I tend to read it in another way: users are not interested in changing
>> this part of the behavior because it's good enough (and also the
>> FUNCTION of special-display-regexps provides the same flexibility, tho
>> in a typically more convenient way).
> OK.  Let's hope that your view is correct.

We can mark special-display-function obsolete right now.

>>> In fact.  Users have to write their own function in order to _avoid_
>>> that `display-buffer' does certain things.  It's precisely this behavior
>>> I wanted to put an end to.
>> If you oppose the FUNCTION hook, then we're in an
>> irreconcilable disagreement.
> Isn't the function specifier of `display-buffer-alist' enough argument
> that I'm in favor of such a hook?  What I said was that users should not
> have to write a function in order to make `display-buffer' _not_ behave
> in a certain way.  They should write functions because that's how they
> want `display-buffer' to behave like.

The difference between the two is only philosophical, from where I stand.

>> I'm not sure why you choose to interpret it as a way to "avoid that
>> display-buffer does certain things" rather than, like any other Emacs
>> hooks, a way to override the default.
> Read for example the posts about `split-window-sensibly' on
> emacs-help.  All people ask for is how to avoid that Emacs splits the
> window horizontally and how to turn it off.  I want a default that
> doesn't provoke users to ask how to turn something off that's bad for
> them.  I want a default that provokes users to ask how to turn
> something on that's good for them.

You're in for a big disappointment, then.  Users, especially in response
to changes, will by and large either be pleased and say nothing or else
ask for "how do I turn this thing off to get back the old behavior".

That has nothing to do with the actual behavior they want or the
behavior they don't want.  It's just how humans work: it's much easier
to see a behavior you don't like and point it out, then to imagine a new
behavior you'd like (and of course, we don't help by forcing users to
report feature requests through M-x report-emacs-bug).

So if you want to avoid questions about how to avoid something or how to
turn it off, your best bet is to revert to the Emacs-23 code.

>> Of course, among all the things you can do with a hook, some of them are
>> to do less than the default.
> Ideally, this should not be necessary.  The default should be the minimum.

While you don't hear them, a majority of users like the new features we
enable in each Emacs release.  So, even if keeping the default
minimalistic would satisfy the few people who complain, it would not
satisfy the silent majority (who otherwise might not even have known
that such a feature could exist).

>> but it's part of the normal experiment/design/experiment/design cycle
>> and it doesn't mean your work was wasted, only that it was
>> instrumental in coming up with the final design, rather than the
>> final code.
> Don't be concerned about this.  The only extra thing I'd ask you to
> spare is the side-window stuff simply because I don't have a better idea
> to ask people to experiment with it.

Sounds good.  Tho, I'd suggest we only document it in the NEWS (and the
docstrings, but not the lispref&manual) and mark it as experimental in
the NEWS.
It looks fairly promising, but I'd like to try and keep it open
for tweaking in the future.

>>>>> The complexity is built into the code of `special-display-popup-frame'.
>>>> I don't find it particularly complex.  It just tries each one of
>>>> the 5 different cases in turn: use FUNCTION,
>>> No.  If it calls FUNCTION it won't try any of the others.
>> If FUNCTION is not provided, it will try the others, so clearly it
>> tries the cases in turn.
> This wasn't my point: If FUNCTION is provided and doesn't produce a
> result, the other cases are ignored.  If any of the others is present
> and doesn't produce a result, the remaining cases are processed.

That's a nitpick.  From where I stand the only problem is that the
docstring does not say what FUNCTION should return.

>> I'm not sure why you're so concerned about this reuse-window behavior of
>> special-display-popup-frame.
> Because I had some very hard time here discussing this with a user who
> can't live with such behavior.

And yet he wants to use dedicated frames?  Can you give some more
details, because that sounds pretty odd.

>> This said, I wonder which systems you're thinking of where "reusing
>> [dedicated] frames doesn't work".  I added [dedicated] since it's 99%
>> sure that the frame is dedicated in the scenario you're talking about.
> The emacs-devel thread is called
> "[display-buffer] a way to make it behave as before?"

I don't understand: this seems to be a discussion about your new code,
not about special-display-popup-frame and its reuse-window behavior.
As a matter of fact he's asking to recover the old behavior.

>> Maybe the issue is that you want to be able to reproduce every detail of
>> the previous behavior in buffer-display-alist, whereas I don't.
> I have to deal with the complaints that something doesn't work as before.

Use the old code whenever possible, rather than trying to reproduce the
old behavior by re-implementing it.

>> No: the whole point of `same-window' was to unify everything into
>> special-display-regexps and make the same-window-* horrors obsolete,
>> just like you're trying to unify everything under buffer-display-alist.

> Ahh ...  yet an another failed attempt to unify things.  Since
> `special-display-regexps' was my reference point for
> `display-buffer-alist' history repeats itself.

The main reason why my attempt failed is because I did not mark
same-window-* as obsolete, and that I didn't mark it as obsolete because
I did not dare to turn the NOT-THIS-WINDOW into a SPECIFIER/RULE
argument which could then make same-window-* really obsolete.

So I think this time around we're in a better position.  But we still
have to take it for granted that the old settings will be with us for
a long time.  All we can do with them is mark them obsolete, provide
similar replacement behavior in the new settings and only use the old
settings by calling the old code which we might even want to move to
lisp/obsolete a some point.

>>>> pop-up-frame.
>>> Which is the original and only reasonable motivation for
>>> `special-display-popup-frame'.
>> The already-displayed is intricately linked to the pop-up-frame because
>> the frame is dedicated.  That's why the already-displayed behavior has
>> been in special-display-popup-frame from the very beginning.
> I don't dispute that all this works for you.  But if we want to
> generalize this concept we have to deal with users who don't want to
> `display-buffer-reuse-frames' and with applications that insist on
> `NOT-THIS-WINDOW'.

In my paper design, the equivalent to the "default
special-display-regexp behavior" (which is the one that includes the
"forcefully reuse-window regardless of display-buffer-reuse-frames")
would be implemented by the display-buffer-dedicated-frame, so (just as
in the original special-display-regexp design) it would only apply to
buffers which are configured to be displayed in dedicated frames.
For those rare users where this is a problem, we can provide some other
function, or some special arg to that function to turn off the "reuse
window" part of the behavior, but that part of the behavior will stay as
the default, because it's the one that makes sense in 99% of the cases.

>>> Why did you have to dedicate the window for this purpose?  If
>>> `pop-up-frames' is non-nil, you get another frame before Emacs even
>>> tries to reuse a window not showing the buffer already.
>> A lot of code uses switch-to-buffer, kill-buffer, bury-buffer, ...
> I lost you here.  If it goes through `display-buffer', all you need is
> `pop-up-frames'.  If it doesn't, `display-buffer-mark-dedicated' won't
> have any effect.

Marking a window dedicated is done in display-buffer but has later on an
effect on what happens in switch-to-buffer, in kill-buffer, in
bury-buffer, ...
I don't set the windows as dedicated to influence display-buffer, but to
influence those other functions.

>>>> It might be an OK replacement for the soft dedication, yes.
>>> Then please try it by using `quit-restore-window' instead of
>>> `quit-window'.
>> I pretty much never use quit-window.
> What do you use then?

I iconify the window, I kill the buffer, I use a command which deletes
the frame and (if it's the last window displaying that buffer) kills the
displayed buffer, I use some other command that ends up calling
kill-buffer or bury-buffer, ...

> With `display-buffer-alist' a user can override everything that
> impedes her to do something on a lower level (like strongly dedicated
> windows or unsplittable frames).  This is part of giving the user
> special rights wrt the behavior of `display-buffer'.  I have no
> problems throwing these out.

Then let's throw them out.

> The consequence is, however, that applications have to be more
> conservative about using them in order to not step on the users' toes.

Not at all: the user can still override them by using the FUNCTION form.
If/when such overrides become common because code starts to use those
things more often, then we can provide the override option in a more
direct way than through FUNCTION, but right now it's not clear it'll
ever be needed.

>> Look more closely.  It'd be like:
>> - removing same-frame and same-window from special-display-popup-frame.
>> - removing the "ignore the 3rd arg of display-buffer" bug because we
>> removed that 3rd arg.
>> - removing the "ignore the 2nd arg of display-buffer" bug because we
>> redefined how it works.
> Which is not entirely trivial since we have to pass this as an argument.
> If we remove `special-display-function' this might be OK.  Now if we
> find someone out there who does we can pass that argument only to
> `special-display-popup-frame' ...

special-display-function is part of the old obsolete interface.  I don't
think we need to worry too much about how it might fail.

>> - at this point special-display-popup-frame is limited to
>>   - reuse a window that shows the given buffer.
> As soon as we have resolved the question whether this may reuse a window
> on another frame.  Please read the thread mentioned above and consult
> with its author if possible.

I don't have time to read the whole thread, but from my cursory look,
I really don't see anything that is a cause for concern since that
"reuse-window" would only be implemented in
special-display-dedicated-frame (which basically be a new name for the
trimmed down special-display-popup-frame).


        Stefan