Re: display-buffer-alist simplifications

[martin rudalics]

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

> Fixing this is indeed (for me) the main goal of buffer-display-alist.
>
>>>> If the buffer is already displayed in some window, these options
>>>> are ignored by that function.
>>> That's often the right thing to do, so it's just a lack of flexibility
>>> in the old code.
>> 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.

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

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

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

> As a matter of fact, all my uses of FUNCTION (and I think Drew's as
> well) are designed to make display-buffer do things that it otherwise
> never does (e.g. redirect focus).

I never disputed that.

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

> But yes, I want to throw out a large part
> of buffer-display-alist.  I know this is hard to take,

Not at all.  Personally, I would take out much more than anyone on this
list.  But I hate the idea that someone will put them in again ...

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

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

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

> Ignoring the failed same-frame and
> same-window parameters, you'll see that this reuse-window is almost
> always the right thing to do: display-buffer would display the buffer in
> a new dedicated frame, so if it's already displayed it's presumably in
> a dedicated frame built previous with the same params and it would be
> bad to create a second dedicated frame showing the same thing.
>
> As for "calling get-buffer-window redundantly":
> - I wouldn't worry about the redundancy performancewise.
> - It's not always redundant.

In the cases where it's not redundant it violates either an argument or
a user setting.

> - You're talking about the Emacs-23 implementation, whereas I'm
>   concerned (and I'm talking here only) about the API.

The discussion was about whether we need a fine-grained interface.  The
interface provided by `special-display-popup-frame' is coarse-grained.

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

>> So `special-display-popup-frame' silently ignores a user option and
>> overrides arguments in a much more aggressive and uncontrolled form than
>> would be possible with `display-buffer-alist'.
>
> Right, to some extent it sucks.  To some extent it provides
> a good default.  Still: irrelevant to the design of buffer-display-alist.
>
> 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.

>>> same-window,
>> Useless because overridden by `same-window-regexps' and
>> `same-window-buffer-names'.
>
> 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.

>>> same-frame,
>> Necessitated by the `pop-up-frames' overrides `pop-up-windows' paradigm
>> explained above.
>
> No: added because pop-up-frames applies to all buffers whereas we're
> taking here about options which depend on the buffer name.

Almost precisely what I meant for ".*".

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

>>>> You don't know what `special-display-buffer-names' does unless you read
>>>> the code of that function.
>>> I don't know what makes you think so.
>> The two weeks I spent with Drew trying to understand it.
>
> If there's complexity it's not really in special-display-buffer-names but
> in how it sometimes behave similarly to (yet subtly differently from)
> the rest of display-buffer.
> And from where I stand the complexity is on the display-buffer side
> rather than the special-display-buffer-names ;-)

Because too much has been built into `display-buffer' already.  Agreed.

> In any case it's still not relevant to streamlining buffer-display-alist.
>
>>>> The correct doc-string of `special-display-buffer-names' would have to
>>>> explain in full what the code of `special-display-popup-frame' does.
>>> What's missing?
>> Are the arguments above not enough?
>
> So, IIUC the missing parts are:
> - the third arg of display-buffer is ignored.
> - the second arg of display-buffer is ignored.
> - it reuses windows regardless of (the ill-named) display-buffer-reuse-frames.
> The first is a largely irrelevant bug since that arg is pretty much
> never used (and your new code indeed gets rid of it).
> The second is a real bug.  We don't usually document bugs.
> The third is a pretty logically-evident behavior (tho only if you
> ignore the same-frame and same-window failures), but sure, feel free to
> document it.  Still a far cry from the complexity of buffer-display-alist.

Let's disagree ;-)

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

>>>> I specially installed the quit-restore parameter for this
>>>> purpose but it's currently mostly overridden by the dedicated status
>>>> of the window.  Couldn't you try in your private code whether you
>>>> could use that parameter instead and leave window dedication to what
>>>> it should stand for according to its name: Avoid that `display-buffer'
>>>> and/or `set-window-buffer' reuse a window for showing another buffer.
>>> 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?

>>>>> - `pop-up-window-split-unsplittable'.
>>>> A silly leftover from the old code, IIUC.  I'd do away with it at any
>>>> time.
>>> You mean it's inherited from Emacs-23 or from your old code?  If it's
>>> from your old code, then please remove it.  If it's from Emacs-23, maybe
>>> as well, tho I'd first like to see where that feature was.
>
>> A frame can have the parameter unsplittable
>
>> `unsplittable'
>>      If non-`nil', this frame's window is never split automatically.
>
> I do know that part, yes.
>
>> The specifier tells `display-buffer' to ignore that parameter.  If you
>> say it's useless, I'll remove it.
>
> The old code never ignored that parameter, right?  So I don't think we
> should add a special feature to ignore that parameter, because I haven't
> heard any request for such a feature.

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.  The consequence is, however, that applications have to be more
conservative about using them in order to not step on the users' toes.
With my approach there's always one trivial advice: If you don't like
what I do, you can override it in `display-buffer-alist'.

>>> I think writing a display-buffer-near-minibuffer function will be
>>> simpler/cleaner than trying to come up with some clever way to
>>> combine various specifiers.
>> Any such function would run into just the same problems as
>> `special-display-popup-frame'.
>
> I do not regard those problems as significant.

I do.  I wouldn't bother otherwise.

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

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

>   - otherwise create a new frame with the provided params.
>   I.e. as clean as it started, trivial to document and code.
> - then, yes, provide multiple instances of such simple and clean things.

Sounds good.

martin