From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: [michael.cadilhac-@t-lrde.epita.fr: sit-for (detect_input_pending ?) and postfix input methods.] Date: Wed, 05 Oct 2005 16:26:35 +0900 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: sea.gmane.org 1128497264 5280 80.91.229.2 (5 Oct 2005 07:27:44 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 Oct 2005 07:27:44 +0000 (UTC) Cc: michael.cadilhac-@t-lrde.epita.fr, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 05 09:27:41 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EN3g0-0002sd-Dq for ged-emacs-devel@m.gmane.org; Wed, 05 Oct 2005 09:26:56 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EN3fz-0001fE-TU for ged-emacs-devel@m.gmane.org; Wed, 05 Oct 2005 03:26:55 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EN3fp-0001f8-VW for emacs-devel@gnu.org; Wed, 05 Oct 2005 03:26:46 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EN3fo-0001ev-CQ for emacs-devel@gnu.org; Wed, 05 Oct 2005 03:26:45 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EN3fo-0001es-AK for emacs-devel@gnu.org; Wed, 05 Oct 2005 03:26:44 -0400 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EN3fm-0000Sy-Nn; Wed, 05 Oct 2005 03:26:43 -0400 Original-Received: from nfs.m17n.org (nfs.m17n.org [192.47.44.7]) by tsukuba.m17n.org (8.13.4/8.13.4/Debian-3) with ESMTP id j957QbjK017568; Wed, 5 Oct 2005 16:26:37 +0900 Original-Received: from etlken (etlken.m17n.org [192.47.44.125]) by nfs.m17n.org (8.13.4/8.13.4/Debian-3) with ESMTP id j957QbCv010334; Wed, 5 Oct 2005 16:26:37 +0900 Original-Received: from handa by etlken with local (Exim 3.36 #1 (Debian)) id 1EN3ff-0002eS-00; Wed, 05 Oct 2005 16:26:35 +0900 Original-To: rms@gnu.org In-reply-to: (rms@gnu.org) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/22.0.50 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) 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:43562 Archived-At: In article , "Richard M. Stallman" writes: > Would you please look at this, and ack? (We have no maintainer for > flyspell now.) > ------- Start of forwarded message ------- > To: emacs-pretest-bug@gnu.org > From: Michael Cadilhac > Subject: sit-for (detect_input_pending ?) and postfix input methods. [...] > For a test-case : > (defun test-case-after-change (a b c) > (if (sit-for 3) > (message "sit-for: t") > (message "sit-for: nil"))) > (defun test-case () > (interactive) > (set (make-local-variable 'after-change-functions) > '(test-case-after-change))) > With a buffer `foo', M-x test-case RET and then with no input method > specified, just hit repeatedly (but don't stay on the touch), let's > say, `u'. > You'll have something like > sit-for: nil [14 times] > sit-for: t > in your *Messages* buffer. This result is expected : sit-for is > interrupted and return nil, then the last `u' produce a successful > sit-for. > Now, clear `foo', and M-x set-input-method RET latin-1-postfix RET > Now do the same (with `u', as it has suffix options), and it'll result > in: > sit-for: t [14 times] > Outch ! `sit-for' exits with `t', what a mess ! > I think this is a bug of the C function `detect_input_pending' or the > way input-method are managed, can you reproduce it ? This is because sit-for instantly returns t if unread-command-events is not nil, and the currrent input method mechanism uses unread-command-events in the following way: To make the explanation clear, I'll right the first `u' event as `u1' and the second `u' event as `u2'. When you turn on latin-1-postfix, type `u1', `u1' is given to the function quail-input-method (and the callees). This binds inhibit-modification-hooks to t and insert "u" with underline, then wait for another key sequence. This insertion doesn't activate test-case-after-change. When `u2' is typed, quail-input-method at first delete the underlined "u", and returns that character `u' as an event to be processed later. But, before returning, it set `u2' in unread-command-events so that it is processed again by the input method. Then, the returned event `u' is handled in the normal command loop and self-insert-command is called, and test-case-after-change is called. At this time, as unread-command-events is not nil, sit-for returns t. Then, why does sit-for return t if unread-command-events is not nil? sit_for does something like this: ... wait_reading_process_output () return detect_input_pending () ? Qnil : Qt; } wait_reading_process_output () returns instantly when unread-command-events, but detect_input_pending () returns 0 because no input event is pending. I don't know which is bad, but I found this suspicious comment for requeued_events_pending_p which is called by wait_reading_process_output. /* Return nonzero if there are pending requeued events. This isn't used yet. The hope is to make wait_reading_process_output call it, and return if it runs Lisp code that unreads something. The problem is, kbd_buffer_get_event needs to be fixed to know what to do in that case. It isn't trivial. */ At least that comment should be fixed because it's actually used now. This is the first time I read these codes, and I don't know how those functions are used in the other places. So I'd like to ask someone else to fix this problem if you think this is the problem to be fixed. As for the original problem of flyspell, how about this workaround? *** flyspell.el 23 Sep 2005 10:59:25 +0900 1.75 --- flyspell.el 05 Oct 2005 16:19:56 +0900 *************** *** 770,776 **** ((get this-command 'flyspell-delayed) ;; the current command is not delayed, that ;; is that we must check the word now ! (sit-for flyspell-delay)) (t t))) (t t))) --- 770,777 ---- ((get this-command 'flyspell-delayed) ;; the current command is not delayed, that ;; is that we must check the word now ! (and (not unread-command-events) ! (sit-for flyspell-delay))) (t t))) (t t))) --- Kenichi Handa handa@m17n.org