Re: q doesn't always quit *Help*

[martin rudalics <rudalics@gmx.at>]

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