Re: display-buffer-alist simplifications

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> We can mark special-display-function obsolete right now.
> It was so a couple of weeks ago.

Yes, and I asked you to remove the obsolete signs, but now I realize
that the one for special-display-function should have stayed.

>>>> 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.
> That person can't use `special-display-popup-frame' because it doesn't
> work correctly on his system.

Again, I don't know where in that thread he says that nor why.
All I saw was requests to get back the Emacs-23 behavior (tho I don't
really understand what was different there either).

> Drew uses `special-display-popup-frame' without dedicating frames IIRC.

I don't think so.

> The only person insisting on the dedicated feature is you.
> And you still didn't give me an answer why you need it.

I did: so that kill-buffer, bury-buffer, switch-to-buffer, and friends
"do the right thing" (i.e. prefer to delete or iconify the window, or
use some other frame, rather than show me some unrelated buffer in the
selected window).
And also so that display-buffer doesn't reuse that window.

>>> 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.
> It's about the reuse-window behavior in general.  The one of
> `special-display-popup-frame' is a special case.

Than I'm lost.  Not sure if it matters, tho.

>> 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.
> Sure.  But using the old code _as is_ is impossible if you want "to turn
> the NOT-THIS-WINDOW into a SPECIFIER/RULE argument which could then make
> same-window-* really obsolete".

Maybe not absolutely "as is", but it should be possible to keep most of
the code unchanged, I think.

>> 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.
> And I'm still asking why frames must be dedicated.

They don't.  But based on the fact that `same-frame' and `same-window'
params only appeared "recently" and that FUNCTION is only used by
a minority of users, then the vast majority of users of
special-display-regexps use it to get dedicated frames.

Now maybe they don't really want dedicated frames, they just want some
way to say that some special buffers should be displayed in some
separate frame, but since Emacs-20 this has made those windows/frames
dedicated (and it made the code reuse any existing window) without
hearing too many complaints about it.

So I think it's a useful feature which we will want to provide through
something like display-buffer-dedicated-frame which users will be free
to use or not.

> It's just as if you wanted to reperesent one of those users who want
> the old behavior back.  What would happen in your setup if a frame
> were not dedicated?

It all depends, but when your code recently failed to mark windows as
dedicated, I pretty quickly noticed it because I ended up accumulating
lots of frames showing the same buffer (often a buffer I didn't even
ask to see).

>> 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, ...
> Fine.  All these should work with the quit-restore window parameter.

Oh, that's nice.

> And as a plus you should get it right when you just reused a window
> showing another buffer on the same frame.  If any of these doesn't work
> please complain.

It'll take me a while to change my setup to avoid dedicating windows, so
don't hold your breath,


        Stefan