From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: question about `sit-for' and `C-g' Date: Fri, 11 May 2012 15:46:50 -0700 Message-ID: <5748F9CC12384B5BB267D14496E2D51E@us.oracle.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1336776428 6588 80.91.229.3 (11 May 2012 22:47:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 11 May 2012 22:47:08 +0000 (UTC) Cc: 'Christopher Schmidt' To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 12 00:47:07 2012 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 1SSyc6-0002KE-EE for ged-emacs-devel@m.gmane.org; Sat, 12 May 2012 00:47:06 +0200 Original-Received: from localhost ([::1]:54310 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SSyc5-0000LL-Ov for ged-emacs-devel@m.gmane.org; Fri, 11 May 2012 18:47:05 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54216) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SSyc2-0000L0-41 for emacs-devel@gnu.org; Fri, 11 May 2012 18:47:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SSyc0-0005IW-8p for emacs-devel@gnu.org; Fri, 11 May 2012 18:47:01 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:20508) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SSyc0-0005IP-1z for emacs-devel@gnu.org; Fri, 11 May 2012 18:47:00 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BMkuvn032173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 22:46:57 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4BMku4m025521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 22:46:56 GMT Original-Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4BMkua2008512; Fri, 11 May 2012 17:46:56 -0500 Original-Received: from dradamslap1 (/10.159.217.132) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 May 2012 15:46:55 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac0vx/QGCsU0wCbrTcWkHNS+05g2iQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 148.87.113.117 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:150448 Archived-At: I have some code that, during minibuffer completion, sometimes shows something in the mode line for a `sit-for' period (user-configurable). `sit-for' calls `read-event' and, except for prefix-arg keys, supposedly pushes the input event back onto `unread-command-events'. If the user hits `C-g' during the `sit-for' period, then, instead of the `C-g' binding in effect in the minibuffer being respected, it seems like `sit-for'/`read-event' handles the `C-g' event directly (?). The effect, in any case, seems to be this: (a) `ding' (the bell rings, with the message `Quit') and (b) the `C-g' gets lost/ignored, so the user needs to hit `C-g' again to get the normal minibuffer `C-g' behavior. AFAICT, there is no actual quit effected - no SIGQUIT, but there are its indications: bell, message. Certainly, the `C-g' binding in effect in the minibuffer is ignored. Dunno whether the `C-g' event is ignored/lost, or it is (mis)handled only by dinging and saying `Quit'. It shouldn't be ignored/lost, since the `sit-for' code apparently pushes it to `unread-command-events'. It's not clear to me just what is happening, but I'm sure that something other than my code (directly, at least) is ringing the bell and writing `Quit'. I have only the Emacs 23.3 C code, but it is perhaps the same for Emacs 24 `read-event' etc. That function calls `read_filtered_event', and I don't see anything in that function that handles `C-g' specially. Except that `read_filtered_event' calls `read_char', which does seem to do something wrt the quit char (C-g), at least in some cases. It's not clear to me just what it does, but if I had to guess it would be that this might be where the `C-g' is ringing the bell and getting swallowed up. I'm no expert when it comes to C code, clearly. Perhaps someone can clue me in. What am I missing? What is handling this C-g during `sit-for'? And should it be? Should `sit-for' handle `C-g' its own way, ignoring any `C-g' binding? (I understand that `read-event' should do so, but I wonder about `sit-for'.) Anyway, besides helping me understand what's happening, what's the best way to get the `C-g' here handled normally (i.e., as a `C-g' in the minibuffer keymaps)? I guess I could call a substitute for `sit-for' that tests the char/event read and explicitly DTRT for `C-g'. Is that what you would recommend, or should `sit-for' itself perhaps do something different/better? (`sit-for' already handles prefix-arg keys specially.) If I had to guess, after reading this over, it would be that you'll say that `sit-for', like `read-event', should not itself handle `C-g' in the normal way (i.e., pass it along, respecting its current key binding), and that it should, like `read-event', treat `C-g' in a hard-coded way. I'd still like to hear about this (explanation, reasons, etc.), so I can understand better. Thx.