From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Perry E. Metzger" Newsgroups: gmane.emacs.devel Subject: Re: not quite understanding input methods Date: Mon, 30 Aug 2021 13:45:05 -0400 Message-ID: <7343dfd2-05d5-0752-8e43-cd44d6394963@piermont.com> References: <231adc63-77f0-037a-365c-28db98f684cf@piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10304"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:92.0) Gecko/20100101 Thunderbird/92.0 Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 30 19:46:17 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mKlMO-0002Vy-Tm for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Aug 2021 19:46:16 +0200 Original-Received: from localhost ([::1]:60726 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mKlMM-00082b-PH for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Aug 2021 13:46:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34398) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mKlLI-0007EZ-4z for emacs-devel@gnu.org; Mon, 30 Aug 2021 13:45:08 -0400 Original-Received: from hacklheber.piermont.com ([166.84.7.14]:48816) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mKlLG-0005fy-A2 for emacs-devel@gnu.org; Mon, 30 Aug 2021 13:45:07 -0400 Original-Received: from snark.cb.piermont.com (localhost [127.0.0.1]) by hacklheber.piermont.com (Postfix) with ESMTP id A189A19E; Mon, 30 Aug 2021 13:45:05 -0400 (EDT) Original-Received: from [10.160.2.107] (jabberwock.cb.piermont.com [10.160.2.107]) by snark.cb.piermont.com (Postfix) with ESMTP id 6BF872DEC65; Mon, 30 Aug 2021 13:45:05 -0400 (EDT) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=166.84.7.14; envelope-from=perry@piermont.com; helo=hacklheber.piermont.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.932, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:273519 Archived-At: On 8/30/21 13:37, Stefan Monnier wrote: >> My guess is that something in the belly of Quail is reading events and not >> the characters in the buffer, but as there's no documentation I'm not really >> clear on what is going on. > This is a hard-coded limit in the C code side of input-methods, as seen > in src/keyboard.c (line 3117): Seems to be at 3065 in master. > > /* Pass this to the input method, if appropriate. */ > if (FIXNUMP (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) > && ' ' <= XFIXNUM (c) && XFIXNUM (c) < 256 && XFIXNUM (c) != 127) > { > > It's already been requested to lift this restriction in the (fairly > distant) past. > > IIRC there's no technical reason behind this limit, it reflects an > assumption that non-ASCII chars have presumably already gone through > some (other) form of input method. > > I think it would be good to lift this restriction, tho we probably want > to do it progressively, e.g. by first introducing a var that controls it > (so you could lift the restriction without potentially impact everyone > else). > This sounds like a reasonable idea. If such a variable gets added to the master branch I will happily test it out. The one issue here is that I'm unsure that we would successfully learn about problems with the change if only a very few people were using it. Perry