Re: display-buffer-alist simplifications

[martin rudalics]

>> Unfortunately not.  An OTHER-WINDOW argument must sill be interpreted
>> consistently with what the user expects.
>
> I don't know what you mean, here.

`other-frame' if `pop-up-frames' is non-nil, `same-frame-other-window'
if `pop-up-frames' is nil.

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

See above, the thread I recommended earlier, and what Drew said in this
thread.

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

It was so a couple of weeks ago.

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

It is philosophical from where I stand.  What made you use the term
"only" here?

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

They get the old behavior, presently.  If what you say here were valid,
I'd be pleased if users continued to be pleased and said nothing.

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

Not really.  The questions are still raised for Emacs-23.

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

That's precisely what distinguishes the philosophy of a maintainer from
that of a person who just happens to contribute code.  The former has to
make and deal with compromises.  I don't envy you for that.

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

OK.

>>> 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.  Drew uses `special-display-popup-frame'
without dedicating frames IIRC.  The only person insisting on the
dedicated feature is you.  And you still didn't give me an answer why
you need it.

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

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

The old code is inherently tied to rebinding variables around
`display-buffer' calls.  We wanted to replace the rebindings with an
argument.

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

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

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

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

In 100% of the cases because this function is not useful for people who
can't reuse a window on another frames.

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

Unfortunately so.  Suppose you removed the dedicatedness setting from
`special-display-popup-frame' for a moment and told me about the ensuing
disasters.

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

Fine.  All these should work with the quit-restore window parameter.
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.  I intended this as one of the features the majority
could like ...

martin