Re: q doesn't always quit *Help*

[martin rudalics]

> My point was that `quit-window' (or equivalent) is correct and sufficient
> here - for both me and users without non-nil `pop-up-frames'. That behavior
> is all that is necessary, IMO. I don't see why anyone would (ever) need more
> than to quit the window.

`quit-window' deletes the frame iff

    (and (or (window-minibuffer-p) (window-dedicated-p window))

holds.  Hence to get rid of the frame `quit-window' is not sufficient in
`view-mode'.

> FWIW, in my case, `quit-window' is sufficient because I have modified
> `delete-window' to delete the frame also if `one-window-p'. Beyond the
> current bug, Emacs does not play well with frames. Fixing this bug should
> not attempt to fix more than this bug, and the behavior of `quit-window' is
> enough to fix this bug, IMO. To go beyond this bug, `delete-window' should
> do what I just described - but that is a different deficiency.

`delete-window' is a primitive function.  I doubt you modified it.  Did
you advise it or do you run a `window-configuration-change-hook'?

>>`view-mode-exit' has the
>>following code to cope with stand-alone frames:
>>
>>             ((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))))))
>
>
> I do have `view-remove-frame-by-deleting' = t, yet *Help* was iconified
> (after your fix). Sorry, I don't have a recipe now.

There is only one single instance of `iconify-frame' in the code of
view-mode, the one cited above.  Hence the only explanation for getting
an iconfied frame is that `view-remove-frame-by-deleting' was nil.

> In any case, `q' in *Help* does various things (before your fix - I haven't
> tested enough with the fix) in various contexts - (1) sometimes it does
> nothing - no feedback, nada - useless; (2) sometimes it deletes the window
> (& frame) - correct; (3) sometimes it iconifies the frame - awful. I assume
> this variety is due to the complexity of the View mode code, but I don't
> pretend to understand the causes. Besides the fact that #3 is awful and #1
> is useless, it is not good that the behavior is variable.

`q' has to cope with split windows as well as with the single
frame/window case, hence the solution is necessarily more complex.

Anyway (1) should not occur any more.  I fixed that by making
`view-exit-action' bury the buffer in help-mode.  (2) should work if
`pop-up-frames' and `view-remove-frame-by-deleting' are non-nil.  (3)
should happen iff `view-remove-frame-by-deleting' is nil.  If you
observe deviant behavior please tell me.

> In my ignorance, I think the whole approach of View mode for `q' since Emacs
> 22 is a mistake - trying to keep track of what series of events set up the
> current context, to determine the smartest way to "quit".
>
> To me, it doesn't make much sense for a function to try to keep track, in a
> complex way, of how (it thinks) it was called and change its behavior in
> complex ways accordingly. View mode worked fine in Emacs 20 and 21, IMO, and
> now it is beyond hope. Call me a pessimist.

The problem is not in view-mode as I explained earlier.  view-mode
hardly changed from Emacs 21 to Emacs 22.  The problem is with the
help-mode interface.