From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: C-g while exiting the minibuffer Date: Wed, 27 Nov 2013 16:15:00 -0500 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1385586915 6234 80.91.229.3 (27 Nov 2013 21:15:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Nov 2013 21:15:15 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 27 22:15:19 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VlmS6-0005eQ-3M for ged-emacs-devel@m.gmane.org; Wed, 27 Nov 2013 22:15:18 +0100 Original-Received: from localhost ([::1]:37835 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlmS5-0006w8-KL for ged-emacs-devel@m.gmane.org; Wed, 27 Nov 2013 16:15:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32862) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlmRw-0006tV-Dc for emacs-devel@gnu.org; Wed, 27 Nov 2013 16:15:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VlmRp-0007C8-5O for emacs-devel@gnu.org; Wed, 27 Nov 2013 16:15:08 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:10780) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlmRp-0007C2-0e for emacs-devel@gnu.org; Wed, 27 Nov 2013 16:15:01 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoGABK/CFHO+KEh/2dsb2JhbABEtyKHbBdzgkwvciYYDYhIoAuhIo1hgykDiGGcGYFegxWBSAQ X-IPAS-Result: AsoGABK/CFHO+KEh/2dsb2JhbABEtyKHbBdzgkwvciYYDYhIoAuhIo1hgykDiGGcGYFegxWBSAQ X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="40549476" Original-Received: from 206-248-161-33.dsl.teksavvy.com (HELO pastel.home) ([206.248.161.33]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 27 Nov 2013 16:15:00 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 1B00460069; Wed, 27 Nov 2013 16:15:00 -0500 (EST) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:165815 Archived-At: I've been trying to track down a performance problem I've been experimenting for a while now. Along the way I found that the problem shows up when frame-focus is redirected (at least, it's a necessary ingredient, tho not sufficient). But I also found out that sometimes I have a redirected frame-focus for no reason. And I finally yesterday caught the bugger that causes this: C-h right while exiting the minibuffer: my minibuffer is in a separate frame, so while in the minibuffer, the frame-focus is redirected (this is perfectly normal so far). When exiting the minibuffer, this focus is supposed to be canceled, but this cancellation can fail: the cancellation is done implicitly by the restoration of the previous window-configuration. The problem being that Fset_window_configuration does /* In the following call to `select-window', prevent "swapping out point" in the old selected window using the buffer that has been restored into it. We already swapped out that point from that window's old buffer. */ select_window (data->current_window, Qnil, 1); BVAR (XBUFFER (XWINDOW (selected_window)->contents), last_selected_window) = selected_window; just before if (NILP (data->focus_frame) || (FRAMEP (data->focus_frame) && FRAME_LIVE_P (XFRAME (data->focus_frame)))) Fredirect_frame_focus (frame, data->focus_frame); IOW just before resetting the frame-focus, we select the selected-window. So far this looks innocuous, but select_window (with a 1 as last argument) calls record_buffer which calls Fdelq which uses QUIT, so if you happen to hit C-g at the right time, the frame-focus redirection is not properly canceled. Now I wonder what should be the best way to fix this. I can just switch the above two code blocks, which will fix the immediate problem (a C-g will not prevent canceling the frame-focus redirected), but I think this points to a larger problem of hitting C-g while processing unwind forms. Of course binding inhibit-quit during processing of unwind forms could be a source of problem in itself (if those forms fail to terminate). Any comment/idea/suggestion? Stefan