From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: phillip.lord@russet.org.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: Timing of input-method output Date: Wed, 06 Feb 2019 22:18:21 +0000 Message-ID: <878syssgr6.fsf@russet.org.uk> 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="21056"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.90 (gnu/linux) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 06 23:19:40 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 1grVXe-0005IS-4w for ged-emacs-devel@m.gmane.org; Wed, 06 Feb 2019 23:19:38 +0100 Original-Received: from localhost ([127.0.0.1]:59291 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1grVXd-0006tA-5i for ged-emacs-devel@m.gmane.org; Wed, 06 Feb 2019 17:19:37 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39018) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1grVWh-0006rt-34 for emacs-devel@gnu.org; Wed, 06 Feb 2019 17:18:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1grVWc-00044R-Uy for emacs-devel@gnu.org; Wed, 06 Feb 2019 17:18:37 -0500 Original-Received: from cloud103.planethippo.com ([78.129.138.110]:43056) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1grVWb-000440-GR for emacs-devel@gnu.org; Wed, 06 Feb 2019 17:18:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=russet.org.uk; s=default; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tPs6LUOx58zdsA5O0SR7sMBtmk+nwSlo1xhuo2gxd1Y=; b=UgOp9p488/b0y9rUx6QbtOEl+ 8grTKMpOw4dz3F4AkZ7IetJQIUDcGkFYTbTP0YLhlKrd3Bjyr4yetpsCT6pNwLUz78IRY9L4IU14Z xSJ1GKUNyXGMd1rW3xMxELaGsiwcMjxvTCZeRnmWmUyU/jzSuj4PCQ997Mz8PTyc8M8iZN3oNphK0 VWj25fowk33JoOpMhDwyoGG0QXarLz1EMbV6meLrSIgsTOcdFzIlN0jKTrd997kQEGl+f88qky9WC LPCi9G0BDRg5gK4PKbdvvALMrycZTFLF0y3YFIwX5480nERVuypYaAmS+VI7hJDY/9RcNmmwGM7gL NBbE3vXNQ==; Original-Received: from cpc142652-benw12-2-0-cust953.16-2.cable.virginm.net ([82.21.43.186]:59842 helo=russet.org.uk) by cloud103.planethippo.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1grVWX-0004uS-HH; Wed, 06 Feb 2019 22:18:29 +0000 In-Reply-To: (Stefan Monnier's message of "Tue, 05 Feb 2019 09:49:19 -0500") X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud103.planethippo.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - russet.org.uk X-Get-Message-Sender-Via: cloud103.planethippo.com: authenticated_id: phillip.lord@russet.org.uk X-Authenticated-Sender: cloud103.planethippo.com: phillip.lord@russet.org.uk X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 78.129.138.110 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:233066 Archived-At: Stefan Monnier writes: >> 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. Yes, I think that this all makes sense. Working exactly what to do is likely to be far harder than how to actually do it. >> 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? No, it's just one of those things that breaks at the moment. If they modification hooks get called before the overlay is placed there is a potential problem. >> 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)))) Surely that just tells me when the input-method-function is being run, which is on every keypress I think? > 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`. Seemed like a good idea, but I think the timing is wrong. I tried adding this to `input-event-functions' (defun emacs-clean-input-event (event) (cond ((mouse-movement-p event) nil) (t (princ (format "event:%s i-h-k: %s i-m-f: %s\n" event inhibit-modification-hooks input-method-function ) #'external-debugging-output)))) Then typed a->j with italian-postfix. The output is below (with the key press added in brackets). I added quail-input-method because this input-method-function because this gets set to zero when its doing it's thing. (a) event:97 i-h-k: nil i-m-f: quail-input-method (b) event:98 i-h-k: t i-m-f: nil (c) event:99 i-h-k: nil i-m-f: quail-input-method (d) event:100 i-h-k: nil i-m-f: quail-input-method (e) event:101 i-h-k: nil i-m-f: quail-input-method (f) event:102 i-h-k: t i-m-f: nil (g) event:103 i-h-k: nil i-m-f: quail-input-method (h) event:104 i-h-k: nil i-m-f: quail-input-method (i) event:105 i-h-k: nil i-m-f: quail-input-method (j) event:106 i-h-k: t i-m-f: nil As you can see, it's the keypress after which sees the with-silent-modification. Also tried detecting the overlay (and (boundp 'quail-overlay) (overlayp quail-overlay) (overlay-start quail-overlay)) Same problem. I'm guessing this is because of the location of the input-event-function call. It's happening too soon, before quail has done anything to respond to the keypress that will result in complex input happening. Complicated business this, don't you think? Phil