From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John J Foerch Newsgroups: gmane.emacs.devel Subject: processes, read-char, and quail problem Date: Tue, 19 Feb 2008 11:17:21 -0500 Message-ID: <87k5l0dipa.fsf@earthlink.net> References: <87k5oks7pa.fsf@earthlink.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1203437284 21109 80.91.229.12 (19 Feb 2008 16:08:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Feb 2008 16:08:04 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 19 17:08:28 2008 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 1JRV0u-0000bX-0P for ged-emacs-devel@m.gmane.org; Tue, 19 Feb 2008 17:08:12 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRV0P-0001w6-7S for ged-emacs-devel@m.gmane.org; Tue, 19 Feb 2008 11:07:41 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JRV0K-0001vs-Fz for emacs-devel@gnu.org; Tue, 19 Feb 2008 11:07:36 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JRV0I-0001uy-2x for emacs-devel@gnu.org; Tue, 19 Feb 2008 11:07:35 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRV0H-0001uv-RK for emacs-devel@gnu.org; Tue, 19 Feb 2008 11:07:33 -0500 Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JRV0H-0001FM-5J for emacs-devel@gnu.org; Tue, 19 Feb 2008 11:07:33 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JRV0A-0000PU-BT for emacs-devel@gnu.org; Tue, 19 Feb 2008 16:07:26 +0000 Original-Received: from dialup-4.158.210.93.dial1.chicago1.level3.net ([4.158.210.93]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Feb 2008 16:07:26 +0000 Original-Received: from jjfoerch by dialup-4.158.210.93.dial1.chicago1.level3.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Feb 2008 16:07:26 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 50 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: dialup-4.158.210.93.dial1.chicago1.level3.net User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.50 (gnu/linux) Cancel-Lock: sha1:MJ++lgZOhmf+h7RxoxoGaBzmpP8= X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:89577 Archived-At: Hello, Bojohan investigated a bug I originally reported as a quail+erc bug. He found that the problem is not particular to erc, but can be reproduced with any process, and that the bug seems to be in emacs `read_char'. I will quote what he told me. The conversation was on irc so I have changed the formatting. ### quote To reproduce, try: * emacs -Q * M-x server-start RET * C-\ chinese-py RET * x * emacsclient --eval 0 * x `read_char' contains this condition: /* Pass this to the input method, if appropriate. */ if (INTEGERP (c) && ! NILP (Vinput_method_function) /* Don't run the input method within a key sequence, after the first event of the key sequence. */ && NILP (prev_event) [...] The input method does it's own event reading in a loop. accepting process input interrupts it. `read_key_sequence' reenters `read_char', but this time prev_event isn't nil. It's `backspace'. Processing input calls `record_asynch_buffer_change': /* Put a BUFFER_SWITCH_EVENT in the buffer so that read_key_sequence will notice the new current buffer. */ When `read_key_sequence' continues reading chars it is in the middle of a sequence and the input method is skipped. So basically, normally "x x ..." happens within the one and same invocation of read_char. when a process intervenes, read_key_sequence resumes in the middle of the sequence. ### end quote I hope this information can be of use. Thank you, John Foerch