From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: Re: q doesn't always quit *Help* Date: Fri, 28 Sep 2007 20:17:05 +0200 Message-ID: <46FD4521.5010600@gmx.at> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1191003490 2851 80.91.229.12 (28 Sep 2007 18:18:10 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 28 Sep 2007 18:18:10 +0000 (UTC) Cc: Bug-Gnu-Emacs To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Sep 28 20:18:06 2007 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IbKPV-0007WG-HK for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Sep 2007 20:17:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IbKPR-0007FA-Sj for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Sep 2007 14:17:53 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IbKPP-0007Et-Ej for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2007 14:17:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IbKPN-0007EZ-Vm for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2007 14:17:51 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IbKPN-0007EU-Py for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2007 14:17:49 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1IbKPN-00028t-Fd for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2007 14:17:49 -0400 Original-Received: (qmail invoked by alias); 28 Sep 2007 18:17:47 -0000 Original-Received: from M3129P003.adsl.highway.telekom.at (EHLO [88.117.39.3]) [88.117.39.3] by mail.gmx.net (mp058) with SMTP; 28 Sep 2007 20:17:47 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+YiFN/5jmYLDhKWUvNO43RDdHgYsGjBd+K/m3fB7 L46Bff6IIokJ/V User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en In-Reply-To: X-Y-GMX-Trusted: 0 X-Detected-Kernel: Linux 2.6 (newer, 1) X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:16647 Archived-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.