[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: q doesn't always quit *Help*
Re: q doesn't always quit *Help*
Fri, 28 Sep 2007 20:17:05 +0200
Mozilla Thunderbird 1.0 (Windows/20041206)
> 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
> 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.
>> (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