From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Timing of input-method output Date: Tue, 05 Feb 2019 09:49:19 -0500 Message-ID: References: <20190122214637.25164.20429@vcs0.savannah.gnu.org> <20190122214639.B2E13203DD@vcs0.savannah.gnu.org> <40f2dac5-f342-b9f0-a792-796a6baf9a56@dancol.org> <87fttj55t8.fsf@russet.org.uk> <87k1iu2v8x.fsf@russet.org.uk> <87munlumyn.fsf@russet.org.uk> <875zu0edcf.fsf@russet.org.uk> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="173759"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 05 15:57:35 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gr2AI-000j3F-Q7 for ged-emacs-devel@m.gmane.org; Tue, 05 Feb 2019 15:57:34 +0100 Original-Received: from localhost ([127.0.0.1]:33229 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gr2AH-00086W-M7 for ged-emacs-devel@m.gmane.org; Tue, 05 Feb 2019 09:57:33 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:44718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gr24d-0004T4-9a for emacs-devel@gnu.org; Tue, 05 Feb 2019 09:51:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gr22T-0004Ag-Hs for emacs-devel@gnu.org; Tue, 05 Feb 2019 09:49:31 -0500 Original-Received: from [195.159.176.226] (port=34024 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gr22T-00049V-Ap for emacs-devel@gnu.org; Tue, 05 Feb 2019 09:49:29 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1gr22P-000Yjw-SY for emacs-devel@gnu.org; Tue, 05 Feb 2019 15:49:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:i91IWmrNpe+ZbyS8dBjRYzre8ko= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:232993 Archived-At: > yes, that DEL would also need to be special, also not to appear in the > undo list, since we would want the events to appear to be "ene'" and not > have a DEL in the middle. Hmm... yes, I think we'll need to play with this until we find something good enough. I can foresee potential interactions also with keyboard macros, so I'm sure there'll be yet more interactions to deal with. It's a tricky area. But that doesn't mean it has to be hard: by making it a new package or an option that's disabled by default we can play with it and live with some quirks until it's polished enough to (maybe) become the new default. > One question I would have wrt to completion is whether and how input > methods affect the visualisation of the buffer. For example, the one I > use puts an underline underneath the "e". This clearly needs to happen > at the right time so it doesn't break the visualisation that both > company and pabbrev drop into the buffer (it's the visual artifact that > made me investigate this all in the first place). AFAIK quail just puts an overlay over the text it has transiently inserted and that overlay by default has the underline face. I don't foresee any particular troublesome interaction here. Any reason why you think this will be problematic? > Is there any way of knowing whether quail is currently offering a choice > of input? > `quail-is-waiting-for-another-keystroke-to-work-out-what-to-do-p' > perhaps? You could try something like (defvar within-the-input-method nil) (add-function :around (local 'input-method-function) (lambda (orig-fun &rest args) (let ((within-the-input-method t)) (apply orig-fun args)))) which in recent enough Emacsen can even be shortened to (defvar within-the-input-method nil) (add-function :around (local 'input-method-function) (lambda (&rest args) (let ((within-the-input-method t)) (apply args)))) Tho a quick'n'dirty hack might be to simply check `inhibit-modification-hooks` which should be t when you're within Quail (because of its use of `with-silent-modification`) and should be nil in the normal case where the event is read by `read-key-sequence`. Stefan