RE: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[Drew Adams]

>  > I should have said "special-display".
>  > (add-to-list
>  >  'special-display-buffer-names
>  >  (list "*Help*" 'my-display-*Help*-frame...))
>
> I did understand you the first time.  The Elisp manual tells me:
>
>       By default, special display means to give the buffer a dedicated
>       frame.
>
> No special semantics for "quitting" or "deleting" dedicated frames are
> given.  There's a short remark in the Emacs manual
>
>       "Killing the special buffer deletes its frame automatically."
>
> but I'm not sure whether you want to kill the Help buffer and I don't
> know what to do when you manually switched to another buffer in that
> frame in between.

As I said, I do *not* switch to another buffer in the same window as *Help*
(which is dedicated). I don't think that's even possible, but I could be
mistaken.

As far as I am concerned, quitting *Help* can delete the buffer or the
window. Either way, my own code will then delete the frame. For me, at
least, quitting *Help* should never just do nothing (which it does
sometimes), and it should never iconify the frame (which it does sometimes).
All that's needed for my own use case is for `q' to call `quit-window', as
I've said before. I can't speak for others, who might have different needs.

>  >>If you "dedicate" a frame to the Help buffer why do you want to switch
>  >>to a different buffer in that frame?  Why do you want to split that
>  >>frame's window?
>  >
>  > I don't; I never said I did. I was describing my overall use,
>  > including my use of `pop-up-frames', not my use of *Help*.
>  > You expressed some assumptions about users with non-nil
>  > `pop-up-frames' and their never reusing a window
>  > and never splitting a window. I was explaining that although I have
>  > `pop-up-frames' non-nil, I still sometimes reuse or split some
>  > windows (not *Help*, but others).
>
> If you do not "reuse" Help windows I don't understand why the proposed
> patch doesn't work for you.  You would have to give me a recipe to
> reproduce the incorrect behavior.  Problems may arise if and only if a
> Help window was reused to display another buffer.

I don't recall how well your patch worked for me. I tried it and reported
what I saw to you quite a while ago. I don't even have the patch anymore.

I sent my recent message in reply to yours, which summarized the possible
use cases. I mentioned that, FWIW, my own preferred *Help* behavior was not
represented in your summary, and I indicated the *Help* quitting behavior
that I would like to see. If your patch satisfies that, then there is no
problem. If, however, the *Help* window is not deleted (`q' does nothing) or
the *Help* frame is iconified, then it still does not provide the behavior I
need. And so on, wrt non-dedicated buffers and what I said about them in my
last mail (quoted below).

>  >>I already explained that by default Help buffers are not dedicated thus
>  >>`quit-window' won't necessarily delete the associated frame.
>  >
>  > And I explained that I don't personally need you to delete the
>  > frame - I do that myself. Deleting the window is sufficient
>  > (for *Help* or any other buffer).
>
> Your personal modifications won't be of any help to other Emacs users.
> Let's make this generally usable.

I proposed for vanilla Emacs that `delete-window' delete also the frame if
the window is alone there (`one-window-p). I think that would be "generally
usable". But some people with different use cases disagreed. I also proposed
that an option be available to at least let users choose that behavior. That
too was rejected.

So anyone who wants the delete-sole-window-also-deletes-frame behavior will
need to either use my code or roll his/her own. (FWIW, my code is here:
http://www.emacswiki.org/cgi-bin/wiki/OneOnOneEmacs.)

If you would simply delete the *Help* window upon quitting, then I would be
happy wrt *Help*, and no one else would be required to share my desire for
the frame also to be deleted.

Again, (1) `q' = `quit-window' suffices for me, and probably for some others
in your use-case list. Alternatively (for me), (2) deleting the *Help*
window or (3) the *Help* buffer is sufficient. Any of those 3 approaches
works for me.

>  > If there was a buffer in the window before the view-mode
>  > buffer is placed in it, then it's OK to show that buffer
>  > after quitting the view-mode buffer. If there was no other
>  > buffer in the window before the view-mode buffer, then
>  > there is no reason to display any buffer at all there -
>  > just delete the window.
>
> I already explained that tracking the appearance of buffers in a window
> is non-trivial and has to be done in `window-configuration-change-hook'.
> So far the decision about how to quit view-mode must be established when
> _entering_ view-mode.

You asked me to describe the behavior I prefer, so I did. I think that what
I wrote (and you just quoted) makes sense; it is reasonable behavior to
expect: When you quit view-mode, if there was another non-view-mode buffer
in the window prior to the viewed buffer, then return to it; otherwise,
delete the window.

More exactly, return to the most recent non view-mode buffer previously in
the same window, if any; if none, then delete the window. I doubt that
anyone wants to return to a view-mode buffer, but I might be mistaken. Even
that would be OK: if there was any buffer at all in the window before the
view-mode buffer, then return to it; if not, then delete the view-mode
window when quitting view mode.

What is definitely not useful is to put some other buffer in the window,
which was never shown in that window before. When a view-mode window pops up
(new frame), quitting the mode should not stick some unrelated buffer in
that window. In this use case, think of a window such as *Help* as a
(non-modal) dialog box. When you quit that dialog box, you don't want its
window to remain, filled with some extraneous buffer that you happened to
access half an hour ago or 3 days ago. That just doesn't make sense.

Anyway, those are the behaviors I see as reasonable and unreasonable. I
cannot speak to the difficulty of implementation. I can say, however, that
Emacs 20 has no such problems.

I'm no expert on this, but my impression is that the view-mode code (or
perhaps it is the help-mode code) is trying to be too smart these days, and
it fails to be smart enough. It was better, IMO, when it was simple,
reliable, and stupid. Users then knew what to expect; the behavior was
predictable and reasonable. Emacs 22.1 sometimes does nothing for `q' in
*Help*, sometimes deletes the window, and sometimes iconifies the frame -
there is a UI problem. (I'm not speaking about your patch; I'm speaking
about Emacs 22.1.)

>  > And if the view-mode buffer is `one-window-p', then delete the frame
>  > also.
>
> If people agree that typing `q' should be allowed to unequivocally
> delete a frame.

Again, if people don't agree about deleting the frame (and I'm sure that
some do not agree), there is still no problem. Those who want that behavior
can use my code or roll their own. It would be preferable, however, that
they have the possibility of choosing that behavior within vanilla Emacs
(e.g. via an option).

I admit that I don't fathom the view-mode and help-mode code. I can only
speak as a user here. Maybe help mode should not use view mode, but should
deal with quitting itself; I don't know. I do know that things are not quite
right yet (in Emacs 22.1).

Again, I sincerely thank you for trying to make sense of this and improve
the code. I know it's not easy to satisfy everyone. I hope it's clear at
least, what I would like to see, if possible.