Re: q doesn't always quit *Help*

[martin rudalics]

> Getting a `one-window-p' frame to be deleted when its window is deleted
> should not be the job of `quit-window' or View-mode quitting, IMO. It should
> be the job of `delete-window'.
>
> I fixed `delete-window' to do that for myself, and I think it should be
> fixed to do that in Emacs also. But that is not part of this bug.

We can't change the standard semantics of `delete-window'.  We could
provide a `delete-window-deletes-frame-if-there-is-only-one-window-left'
option and delete the frame if it has one window only and this option is
non-nil.

> (or (fboundp 'old-delete-window)
>     (fset 'old-delete-window (symbol-function 'delete-window)))
>
> (defun delete-window (&optional window)

That's cannibalism!  Mr. Adams ...

> As far as the single frame case is concerned, as I said, I think that it
> should not be up to view-mode to worry about that - that should be what
> `delete-window' does. Whether it is appropriate to delete a `one-window-p'
> frame when code tries to delete the window is not specific to view-mode.
>
> Again, however, I am ignorant of the complexities and needs of view-mode.
>
>
>>Anyway (1) should not occur any more.  I fixed that by making
>>`view-exit-action' bury the buffer in help-mode.
>
>
> I haven't tried the new code much, but I've found that `bury-buffer' is
> usually the worst thing for my one-frame-per-buffer-by-default setup. It
> almost never DTRT for me. Usually just deleting the frame or killing the
> buffer is more appropriate in my context. But don't worry about this now. If
> I find a specific problem I'll report it specifically.

Earlier you complained "sometimes it does nothing - no feedback, nada -
useless" hence burying the buffer should be an improvement.  Why is
`kill-buffer' better than `bury-buffer' for the *Help* buffer?

>>(2) should work if
>>`pop-up-frames' and `view-remove-frame-by-deleting' are non-nil.
>
>
> Don't forget that it is not enough to test `pop-up-frames'. There are other
> reasons that a user might systematically display *Help* in a separate frame.
> Special-display buffers, for instance. The only thing you can count on
> `pop-up-frames' to indicate, wrt the user's intention, is whether
> `display-buffer' should systematically use a separate frame - nothing more.
> A nil value does not imply that *Help* (or whatever other buffer) is not to
> be displayed in its own frame.
>
> FWIW, I've found that the first thing that a library author does, when I
> inform him that his code does not work with one-frame-per-buffer-by-default,
> is to change the code to test `pop-up-frames'. It's not so simple.

IMHO `pop-up-frames' should be tested _exclusively_ in `display-buffer'.
That's one reason why I want to deprecate `print-help-return-message'.

> IMO, the proper thing to test is not `pop-up-frames' but `one-window-p'.

`view-mode-exit' should do that: The frame-handling code is executed
only if `one-window-p' holds:

             ((not (one-window-p t)) (delete-window))
             ((not (eq frame (next-frame)))
              ;; Not the only frame, so can safely be removed.
              (if view-remove-frame-by-deleting
                  (delete-frame frame)
                (setq notlost t)                ; Keep the window. See below.
                (iconify-frame frame))))))

> Now, maybe some users don't want the frame to be always be deleted if
> `one-window-p', and maybe there should therefore be some other option to
> indicate the user's preference. If so, it should not be limited to view-mode
> (e.g. `view-remove-frame-by-deleting'). It has nothing to do with view-mode.
> Perhaps we need an option `delete-window-deletes-single-window-frame'; I
> don't know. In any case, this is about `delete-window', not about
> `display-buffer' (i.e. `pop-up-frames').

That's precisely what `view-remove-frame-by-deleting' is for, as far as
view-mode is concerned.  But I wouldn't oppose adding such an option for
`delete-window'.  Note, however, that `quit-window' has become the
synonym for "quitting" in a number of modes.  Hence, maybe an option
like `quit-window-always-kills-solitary-frame' is more appropriate.

> Whenever I tried to debug this in the past, to follow what was happening, it
> was in the view-mode code that I got lost and tangled in the undergrowth.
> For one thing, there is a plethora of different view-mode exit functions
> (View-exit, View-exit-and-edit, View-leave, View-kill-and-leave, View-quit,
> View-quit-all). For another thing, the code apparently tries to keep track
> of the context in which it was called, and it tries to DTRT based on that
> context. The latter, in particular, is bound to be tricky. If, in the
> meantime, some of that original context no longer makes sense (e.g. deleted
> windows), then it needs to try to adjust to the changed context, and so on.
>
> To me, both of those things (multiple ways to exit and trying to handle
> different calling contexts) raise a red flag that signals a probable
> complicated mess. No, I don't know that it is a mess; it just seems that
> way. I was overwhelmed by what I saw, and I gave up. Mea culpa.

Most of the exit functions you mention are creeping featurism.  The fact
that they are here should teach us not to install such functions in the
future.  Once they're in Emacs it's hard to get rid of them.

Restoring the context where a help function was called _is_ convenient
when you have, for example, split a window to show two distinct parts of
the same buffer and you don't want to pop-up a new frame.  In this case
you should be able to temporarily view *Help* in one of these windows
and have quitting restore the previous state.

I can't change view-mode much.  It's already used by too many parts of
Emacs.  I can only try to make it behave better with help-mode.