RE: q doesn't always quit *Help*

[Drew Adams]

>  >>`quit-window' deletes the frame iff it's a minibuffer-window - which
>  >>should not hold here - or it's a dedicated window - do you set that?
>  >
>  > As I said, it deletes the frame in my code. And yes, *Help* is
>  > probably also a dedicated window for me - it is a special-display
>  > frame for me, in any case.
>
> If you change this manually I can't help you.  Any solution I provide
> here must rely on the standard settings.

Yes, of course.

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.

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.

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

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.

> Hence if your view-mode frame is not the only frame it should get
> deleted provided you have set `view-remove-frame-by-deleting' to
> non-nil.  `quit-window' should never delete such frames.

Don't worry about `quit-window' not deleting the frame - deleting the window
is suffient. With my own code it also deletes the frame, but don't worry
about that. Without my code, if other users eventually complain that the
frame too should be deleted, then the place to fix that is not in View
mode - it is by simply making `delete-window' delete the frame when
`one-window-p'.

>  Did you customize `view-remove-frame-by-deleting'?

Yes, it is `t'.

>  >>But I agree that the behavior you describe is logical and desirable (as
>  >>long as you never display anything else in that window).
>  >
>  > I don't [think] the part in parentheses is needed - so what if you do
>  > at some time display another buffer in that window?
>
> If it's a view-mode buffer it should always rely on the _latest_
> information established by `with-help-window'.  This information should
> be kept when you follow links or xrefs.  For any other buffer "q"
> hopefully has the effect the respective major mode assigns it.

OK, I don't pretend to follow the View-mode logic; I'm sure you're right.

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.

And I do admit to ignorance on this - I'm just relating my experience as a
user. I am not claiming I know how to design View mode so that it does TRT
in all contexts. It just feels terribly wrong when I look at the code.

>  >> Hence, I have to invent something here.  Did you try this with
>  >>`help-window-select' customized?
>  >
>  > No, I never heard of it. And I don't see it in Emacs 22.1 (or
>  > in 21 or 20), which is what I use. What is it, and how might
>  > it help here?
>
> That's the new option I wrote for help.el.  With pop-up frames it
> shouldn't make much difference I suppose.

Was it in the patch? I didn't notice it.

Anyway, thanks for fixing this bug. For the rest, we shall see. If I get a
recipe for other problems I'll let you know. My general wish is that someone
revamp the View-mode code to simplify it and remove the klunky "cleverness".
I think it should not try to have 18 zillion different behaviors, depending
on how it thinks it might have been called and what it thinks the user might
be intending.