From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: Emacs 23 Mac port Date: Wed, 13 Jan 2010 08:35:59 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <2282B3B4-D844-4E26-BB94-9F79EEA2E847@gmail.com> <4B4C2FD7.8070406@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1263339391 11346 80.91.229.12 (12 Jan 2010 23:36:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 Jan 2010 23:36:31 +0000 (UTC) Cc: Jan =?ISO-8859-1?Q?Dj=E4rv?= , Leo , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 13 00:36:18 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NUqHW-0007Ee-SS for ged-emacs-devel@m.gmane.org; Wed, 13 Jan 2010 00:36:15 +0100 Original-Received: from localhost ([127.0.0.1]:53762 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NUqHX-0001g6-7n for ged-emacs-devel@m.gmane.org; Tue, 12 Jan 2010 18:36:15 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NUqHQ-0001dC-Vn for emacs-devel@gnu.org; Tue, 12 Jan 2010 18:36:09 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NUqHM-0001SP-9k for emacs-devel@gnu.org; Tue, 12 Jan 2010 18:36:08 -0500 Original-Received: from [199.232.76.173] (port=40368 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NUqHL-0001S8-UU for emacs-devel@gnu.org; Tue, 12 Jan 2010 18:36:03 -0500 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:51474) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NUqHL-000135-AE for emacs-devel@gnu.org; Tue, 12 Jan 2010 18:36:03 -0500 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 9C849C0557; Wed, 13 Jan 2010 08:35:59 +0900 (JST) In-Reply-To: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-operating-system: by monty-python.gnu.org: NetBSD 3.0 (DF) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:119885 Archived-At: >>>>> On Tue, 12 Jan 2010 09:15:11 -0500, Stefan Monnier said: >> Thanks. But then a special event such as SIGUSR1 cancels an >> incomplete key sequence being typed. How about doing this only >> when the current buffer is changed by the special event? > IIRC the general approach to these kinds of problems in > read-key-sequence is to only recompute the initial state if the > current key-sequence is still empty. I.e. rather than check whether > the special event has changed current buffer, we would instead check > whether the keybuf is still empty. Well, at least, it seems to be much cleaner for read_char just to return a special code (instead of -2) indicating a command is executed via special event map, and let the caller determine what to do for that case. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp