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: Sun, 03 Feb 2019 22:06:40 +0000 Message-ID: <875zu0edcf.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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="24093"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.91 (gnu/linux) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 03 23:07:43 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 1gqPvS-0006AG-Sb for ged-emacs-devel@m.gmane.org; Sun, 03 Feb 2019 23:07:43 +0100 Original-Received: from localhost ([127.0.0.1]:60945 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gqPvR-000200-IT for ged-emacs-devel@m.gmane.org; Sun, 03 Feb 2019 17:07:41 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:45013) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gqPvK-0001zd-Ga for emacs-devel@gnu.org; Sun, 03 Feb 2019 17:07:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gqPvG-0006gy-8s for emacs-devel@gnu.org; Sun, 03 Feb 2019 17:07:33 -0500 Original-Received: from cloud103.planethippo.com ([78.129.138.110]:35428) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gqPvC-00064k-NX for emacs-devel@gnu.org; Sun, 03 Feb 2019 17:07:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=russet.org.uk; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From:Sender :Reply-To: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=MsaR2GKibdB2GHI4quPhhM+exD7GEOuYAbOhQ94CN00=; b=y2l+m5bHsnTmJlIoc+8giZtPm6 fSHle/lDDgDJ5wjRrU2JXvWkLmCZZY05DEI2W4cWQ0+WP3bJGZRpdSQCHOwk2I5ZE6Gj9b8XAR+qZ OepxiVHhNq/HvCZJBKDEt0uTpOVadcAbBUhpUBgqP+jn2mzH2LwioaEORp1jWyrK1hR0YD9CjMuea 4xNsZr1lnAqIshCj/8xjk1o33sb4nth0RoEoEzFccVC3fjAAoCopKt/Z3JFN0/DrCqkKevSM2rwGW epjfZokISS1q6GuUnL2ID1/VlXLB0F2uWo7e1d3KWUKlp0DaHsfG+XEmUURtK+7E0gpUI13/w7vNF oz+bObiQ==; Original-Received: from cpc142652-benw12-2-0-cust953.16-2.cable.virginm.net ([82.21.43.186]:53894 helo=russet.org.uk) by cloud103.planethippo.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gqPuT-000168-PM; Sun, 03 Feb 2019 22:06:41 +0000 In-Reply-To: (Stefan Monnier's message of "Sat, 02 Feb 2019 11:13:14 -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:232946 Archived-At: Stefan Monnier writes: >>> Hmm... this is a bummer (in some input methods, many/most chars are >>> prefixes of something else). IIUC this is not a new problem introduced >>> by the use of input-event-functions, tho, right? >> My experience is that completion doesn't work when an input method is >> half way through, although I only use simple input methods. > > Right: so this is not a new problem. Based on the limited evidence of me poking the one input method I use with a stick, no. >> Anyway, I checked (should have done this before I sent the last email, >> sorry). The buffer is not changed by an input method half way through >> (or at least "before-change-function" is not called, which I am assuming >> is the same thing). So, when the buffer appears to say "pizza_[`]", if >> it does offer a completion at all, it's going to offer one based on >> "pizz" because they "a" is not in the buffer. > > Actually, quail.el does insert the "a", but it does so only temporarily, > within a with-silent-modification, and it removes it as soon as we know > what will actually be the next result of the input method (to the user, > that's basically when the underscore is (re)moved). > > IOW, the underlined text behaves more or less like it's not in the > buffer (technically it is, but it's transient and the *-change-functions > aren't notified). > > For latin-based input methods (especially postfix-style ones) where it's > extremely frequent for the first char passed to an input method to end up > passed through unmodified, it would make sense to try and change the > behavior of quail so it really inserts the first char right away, even > if it may later modify it because of some subsequent user input. > > E.g. currently, in latin-postfix methods, when I type > > Time0 Time1 > ----- ----- > e n > > the input looks (to the rest of Emacs) as if I had typed > > Time0 Time1 > ----- ----- > e n > > this is so that when I type > > Time0 Time1 > ----- ----- > e ' > > Emacs only sees > > Time0 Time1 > ----- ----- > =C3=A9 > > but we it would make sense to try and make it behave such that an input l= ike: > > Time0 Time1 Time2 Time3 > ----- ----- ----- ----- > e n e ' > > results in the following (decoded) input events: > > Time0 Time1 Time2 Time3 > ----- ----- ----- ----- > e n e DEL =C3=A9 > > [ More or less: the DEL there can't be right since the user can bind it > to anything else, so we'd have to delete the previous char "manually" > rather than by emitting a DEL event. ] > > This would be a pretty significant change in quail.el (which is likely > to require experimentation before we can find something that works > well), and is likely to only make sense in some input methods. > > I think it'd be nice for someone to play with such a quail variant > (it's probably easiest to do it be adding a config var to quail.el to > control that new behavior) to see if it can fly. I think that this would work more cleanly. In this case, at Time 2 we would be offering a completion for prefix "ene" rather than "ene'" which should then be functional with a [tab] (or whatever) at Time 3. And, 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. 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). Having said all this, I am currently struggling to get the input-event-functions to function properly for my use case -- I have got it stopping the strange visualisation, but alas, at the cost of breaking completion which is a baby-and-bathwater thing. The reason for this is that I use `this-command' to work out whether to remove the completion or not and `input-event-functions' runs before this is set. 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? Phil