* Re: master 7b31de4: Add hook for all events [not found] ` <20190122214639.B2E13203DD@vcs0.savannah.gnu.org> @ 2019-01-22 23:17 ` Michael Albinus 2019-01-23 22:56 ` Phillip Lord 2019-01-23 1:30 ` [Emacs-diffs] " Daniel Colascione 1 sibling, 1 reply; 22+ messages in thread From: Michael Albinus @ 2019-01-22 23:17 UTC (permalink / raw) To: emacs-devel; +Cc: Phillip Lord phillip.lord@russet.org.uk (Phillip Lord) writes: Hi Philipp, > diff --git a/etc/NEWS b/etc/NEWS > index 2118747..b0bbaeb 100644 > --- a/etc/NEWS > +++ b/etc/NEWS > @@ -1189,11 +1189,13 @@ removed. > \f > * Lisp Changes in Emacs 27.1 > > -+++ > + > ** 'self-insert-command' takes the char to insert as (optional) argument. Is there a reason you have removed the three pluses? > +** New hook `input-event-functions` run whenever a user-input is read. > + In etc/NEWS, pls quote Lisp objects 'like-this'. I guess you shall preceed this entry by three minuses, because it lacks the documentation in the manual. Best regards, Michael. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: master 7b31de4: Add hook for all events 2019-01-22 23:17 ` master 7b31de4: Add hook for all events Michael Albinus @ 2019-01-23 22:56 ` Phillip Lord 2019-01-24 3:36 ` Eli Zaretskii 0 siblings, 1 reply; 22+ messages in thread From: Phillip Lord @ 2019-01-23 22:56 UTC (permalink / raw) To: Michael Albinus; +Cc: emacs-devel Michael Albinus <michael.albinus@gmx.de> writes: > phillip.lord@russet.org.uk (Phillip Lord) writes: > > Hi Philipp, "Phillip" -- I should change my email line to "Phil". There are too many versions of the spelling. >> diff --git a/etc/NEWS b/etc/NEWS >> index 2118747..b0bbaeb 100644 >> --- a/etc/NEWS >> +++ b/etc/NEWS >> @@ -1189,11 +1189,13 @@ removed. >> \f >> * Lisp Changes in Emacs 27.1 >> >> -+++ >> + >> ** 'self-insert-command' takes the char to insert as (optional) argument. > > Is there a reason you have removed the three pluses? Yep. Screw up with my rebase. Slightly unfortunate that the "+++/---" markup is similar to the markup that diff uses but guess that's a poor excuse. > >> +** New hook `input-event-functions` run whenever a user-input is read. >> + > > In etc/NEWS, pls quote Lisp objects 'like-this'. I guess you shall > preceed this entry by three minuses, because it lacks the documentation > in the manual. I thought the semantics of "---" was "definately needs not change" and I am not sure whether this is true. Sitting on the fence. I can update the documentation also. Phil ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: master 7b31de4: Add hook for all events 2019-01-23 22:56 ` Phillip Lord @ 2019-01-24 3:36 ` Eli Zaretskii 0 siblings, 0 replies; 22+ messages in thread From: Eli Zaretskii @ 2019-01-24 3:36 UTC (permalink / raw) To: Phillip Lord; +Cc: michael.albinus, emacs-devel > From: phillip.lord@russet.org.uk (Phillip Lord) > Date: Wed, 23 Jan 2019 22:56:19 +0000 > Cc: emacs-devel@gnu.org > > I can update the documentation also. Please do (and then mark with +++). Massive updates of the docs before a release are a pain. Thanks. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master 7b31de4: Add hook for all events [not found] ` <20190122214639.B2E13203DD@vcs0.savannah.gnu.org> 2019-01-22 23:17 ` master 7b31de4: Add hook for all events Michael Albinus @ 2019-01-23 1:30 ` Daniel Colascione 2019-01-23 23:10 ` Phillip Lord 1 sibling, 1 reply; 22+ messages in thread From: Daniel Colascione @ 2019-01-23 1:30 UTC (permalink / raw) To: emacs-devel, Phillip Lord On 1/22/19 1:46 PM, Phillip Lord wrote: > branch: master > commit 7b31de4d107302ed91ce7519cd778b340a9880ee > Author: Phillip Lord <phillip.lord@russet.org.uk> > Commit: Phillip Lord <phillip.lord@russet.org.uk> > > Add hook for all events Why? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master 7b31de4: Add hook for all events 2019-01-23 1:30 ` [Emacs-diffs] " Daniel Colascione @ 2019-01-23 23:10 ` Phillip Lord 2019-01-24 2:06 ` Stefan Monnier 0 siblings, 1 reply; 22+ messages in thread From: Phillip Lord @ 2019-01-23 23:10 UTC (permalink / raw) To: Daniel Colascione; +Cc: emacs-devel Daniel Colascione <dancol@dancol.org> writes: > On 1/22/19 1:46 PM, Phillip Lord wrote: >> branch: master >> commit 7b31de4d107302ed91ce7519cd778b340a9880ee >> Author: Phillip Lord <phillip.lord@russet.org.uk> >> Commit: Phillip Lord <phillip.lord@russet.org.uk> >> >> Add hook for all events > > Why? Finally got around to doing this 4 years after I first hit the problem. https://lists.gnu.org/archive/html/emacs-devel/2015-05/msg00742.html Short answer: input methods break completion provided by both company and my own pabbrev. For example, try copying the company-mode documentation into *scratch*, M-x text-mode, M-x company-mode, M-x set-input-method "italian-postfix". Now type "Comple". You should see something like: Compl Complements Complete Completing Completion Complex e_[] where e_ is e underscore and [] is the cursor and the lines in the middle are offered completions. The problem is that company uses pre-command-hook to remove old offered completions. But self-insert hasn't run yet, because the user hasn't decided whether to type "e" or "e'". With this hook, I can pick up the intermediate keypresses. Does it cause any problems you can foresee (other than signally a lot). Phil ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master 7b31de4: Add hook for all events 2019-01-23 23:10 ` Phillip Lord @ 2019-01-24 2:06 ` Stefan Monnier 2019-01-24 10:41 ` Phillip Lord 0 siblings, 1 reply; 22+ messages in thread From: Stefan Monnier @ 2019-01-24 2:06 UTC (permalink / raw) To: emacs-devel > Short answer: input methods break completion provided by both company > and my own pabbrev. For example, try copying the company-mode > documentation into *scratch*, M-x text-mode, M-x company-mode, M-x > set-input-method "italian-postfix". Now type "Comple". You should see > something like: > > Compl > Complements > Complete > Completing > Completion > Complex > e_[] > > where e_ is e underscore and [] is the cursor and the lines in the > middle are offered completions. > > The problem is that company uses pre-command-hook to remove old offered > completions. But self-insert hasn't run yet, because the user hasn't > decided whether to type "e" or "e'". With this hook, I can pick up the > intermediate keypresses. So, IIUC the issue is to detect when to pop down the completions offered by the likes of company/pabbrev/... And the idea is that those packages can stop using pre-command-hook and use input-event-functions. So, IIUC now company will pop down its menu as soon as you hit a prefix key like C-x or C-c, right? Is that a desirable or undesirable side-effect? I guess the previously available alternative was to use sit-for to wait for the next event, right (and indeed, I think input-event-functions is a better option than sit-for)? Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master 7b31de4: Add hook for all events 2019-01-24 2:06 ` Stefan Monnier @ 2019-01-24 10:41 ` Phillip Lord 2019-01-25 13:56 ` Stefan Monnier 2019-01-26 0:50 ` Stefan Monnier 0 siblings, 2 replies; 22+ messages in thread From: Phillip Lord @ 2019-01-24 10:41 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> The problem is that company uses pre-command-hook to remove old offered >> completions. But self-insert hasn't run yet, because the user hasn't >> decided whether to type "e" or "e'". With this hook, I can pick up the >> intermediate keypresses. > > So, IIUC the issue is to detect when to pop down the completions offered > by the likes of company/pabbrev/... > And the idea is that those packages can stop using pre-command-hook and > use input-event-functions. I'm currently using both pre-command and input-event but yes, you are probably correct I wouldn't need pre-command any more. Currently, I am doing this: (defun pabbrev-input-event-functions (event) "Remove offering expansion from buffer on events. This function is normally run off `input-event-functions'. It main purpose is to remove completions during multi-keystroke keyboard events associated with many input methods. These do not signal a pre-command-hook because the command only completes when they are unambiguously complete." (cond ((mouse-movement-p event) nil) (t (pabbrev-pre-command-hook)))) > So, IIUC now company will pop down its menu as soon as you hit a prefix > key like C-x or C-c, right? Is that a desirable or undesirable > side-effect? Yes, I think it would do that. I don't know if this is desirable or not. I will have to try it. I expect it is a difference most people wouldn't see. It also has a practical impact; it is not possible to complete when an input method is in the middle of the multi key press. So, for example, with italian-postfix you can no longer complete on a prefix ending in an "e" or and "i"; pressing "e" removes completion suggestions, but does not trigger adding them because "e" could be "e`". > I guess the previously available alternative was to use sit-for to wait > for the next event, right (and indeed, I think input-event-functions is > a better option than sit-for)? Well, you should find it better; this hook is your code (I stole it from a patch you sent in 2015). Sit-for, yes, would be a possibility, that I hadn't thought off; you'd still need to filter the event using `last-input-event' I guess. That would be a way of fixing company and pabbrev in current Emacs. I will investigate. Phil ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master 7b31de4: Add hook for all events 2019-01-24 10:41 ` Phillip Lord @ 2019-01-25 13:56 ` Stefan Monnier 2019-01-28 9:42 ` Phillip Lord 2019-01-26 0:50 ` Stefan Monnier 1 sibling, 1 reply; 22+ messages in thread From: Stefan Monnier @ 2019-01-25 13:56 UTC (permalink / raw) To: Phillip Lord; +Cc: emacs-devel > Well, you should find it better; this hook is your code (I stole it from > a patch you sent in 2015). Sit-for, yes, would be a possibility, that I > hadn't thought off; you'd still need to filter the event using > `last-input-event' I guess. That would be a way of fixing company and > pabbrev in current Emacs. I will investigate. Another way might be to use a before/after-change-function (i.e. don't detect an input event but rather detect that the input method inserted something into the buffer). Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master 7b31de4: Add hook for all events 2019-01-25 13:56 ` Stefan Monnier @ 2019-01-28 9:42 ` Phillip Lord 0 siblings, 0 replies; 22+ messages in thread From: Phillip Lord @ 2019-01-28 9:42 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> writes: >> Well, you should find it better; this hook is your code (I stole it from >> a patch you sent in 2015). Sit-for, yes, would be a possibility, that I >> hadn't thought off; you'd still need to filter the event using >> `last-input-event' I guess. That would be a way of fixing company and >> pabbrev in current Emacs. I will investigate. > > Another way might be to use a before/after-change-function (i.e. don't > detect an input event but rather detect that the input method inserted > something into the buffer). I haven't checked, but I always assumed that input methods do not insert anything in the buffer until a key sequence completes; rather than everything was visual. Perhaps not; pabbrev used to insert suggestions into the buffer, until you fixed it. Phil ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master 7b31de4: Add hook for all events 2019-01-24 10:41 ` Phillip Lord 2019-01-25 13:56 ` Stefan Monnier @ 2019-01-26 0:50 ` Stefan Monnier 2019-01-28 9:54 ` Phillip Lord 1 sibling, 1 reply; 22+ messages in thread From: Stefan Monnier @ 2019-01-26 0:50 UTC (permalink / raw) To: emacs-devel > It also has a practical impact; it is not possible to complete when an > input method is in the middle of the multi key press. So, for example, > with italian-postfix you can no longer complete on a prefix ending in > an "e" or and "i"; pressing "e" removes completion suggestions, but does > not trigger adding them because "e" could be "e`". 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? Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master 7b31de4: Add hook for all events 2019-01-26 0:50 ` Stefan Monnier @ 2019-01-28 9:54 ` Phillip Lord 2019-02-02 16:13 ` Timing of input-method output (was: [Emacs-diffs] master 7b31de4: Add hook for all events) Stefan Monnier 0 siblings, 1 reply; 22+ messages in thread From: Phillip Lord @ 2019-01-28 9:54 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> It also has a practical impact; it is not possible to complete when an >> input method is in the middle of the multi key press. So, for example, >> with italian-postfix you can no longer complete on a prefix ending in >> an "e" or and "i"; pressing "e" removes completion suggestions, but does >> not trigger adding them because "e" could be "e`". > > 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. 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. The ideal behaviour here would be to offer completions based on either "pizza" or "pizza`". Completion would then do the work of the input method also. I am guessing that this is would be non trivial to add. For sure, pabbrev and I guess company would have to work on what the user sees, not what is in the buffer; and this is likely to be wrong nearly as often as it is right. Phil ^ permalink raw reply [flat|nested] 22+ messages in thread
* Timing of input-method output (was: [Emacs-diffs] master 7b31de4: Add hook for all events) 2019-01-28 9:54 ` Phillip Lord @ 2019-02-02 16:13 ` Stefan Monnier 2019-02-03 22:06 ` Timing of input-method output Phillip Lord 0 siblings, 1 reply; 22+ messages in thread From: Stefan Monnier @ 2019-02-02 16:13 UTC (permalink / raw) To: Phillip Lord; +Cc: emacs-devel >> 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. > 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 ----- ----- é but we it would make sense to try and make it behave such that an input like: Time0 Time1 Time2 Time3 ----- ----- ----- ----- e n e ' results in the following (decoded) input events: Time0 Time1 Time2 Time3 ----- ----- ----- ----- e n e DEL é [ 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. Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timing of input-method output 2019-02-02 16:13 ` Timing of input-method output (was: [Emacs-diffs] master 7b31de4: Add hook for all events) Stefan Monnier @ 2019-02-03 22:06 ` Phillip Lord 2019-02-05 14:49 ` Stefan Monnier 0 siblings, 1 reply; 22+ messages in thread From: Phillip Lord @ 2019-02-03 22:06 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> 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 > ----- ----- > é > > but we it would make sense to try and make it behave such that an input like: > > Time0 Time1 Time2 Time3 > ----- ----- ----- ----- > e n e ' > > results in the following (decoded) input events: > > Time0 Time1 Time2 Time3 > ----- ----- ----- ----- > e n e DEL é > > [ 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timing of input-method output 2019-02-03 22:06 ` Timing of input-method output Phillip Lord @ 2019-02-05 14:49 ` Stefan Monnier 2019-02-06 22:18 ` Phillip Lord 0 siblings, 1 reply; 22+ messages in thread From: Stefan Monnier @ 2019-02-05 14:49 UTC (permalink / raw) To: emacs-devel > 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timing of input-method output 2019-02-05 14:49 ` Stefan Monnier @ 2019-02-06 22:18 ` Phillip Lord 2019-02-06 22:55 ` Stefan Monnier 0 siblings, 1 reply; 22+ messages in thread From: Phillip Lord @ 2019-02-06 22:18 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timing of input-method output 2019-02-06 22:18 ` Phillip Lord @ 2019-02-06 22:55 ` Stefan Monnier 2019-02-11 22:10 ` Phillip Lord 0 siblings, 1 reply; 22+ messages in thread From: Stefan Monnier @ 2019-02-06 22:55 UTC (permalink / raw) To: Phillip Lord; +Cc: emacs-devel > 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. Oh, here's another random idea: in input-event-functions, start a timer to run "right away" (i.e. at the next occasion, which will be when we finish processing the current key and start waiting for the next). -- Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timing of input-method output 2019-02-06 22:55 ` Stefan Monnier @ 2019-02-11 22:10 ` Phillip Lord 2019-02-11 22:20 ` Stefan Monnier 0 siblings, 1 reply; 22+ messages in thread From: Phillip Lord @ 2019-02-11 22:10 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> writes: >> 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. > > Oh, here's another random idea: > > in input-event-functions, start a timer to run "right away" (i.e. at > the next occasion, which will be when we finish processing the > current key and start waiting for the next). Oh dear, that really does seem nasty to me. I wonder if I am going about this in the wrong way. Given that this only happens when quail is active, is it not quail that needs hooking? "pre-quail-command-hook" or something. Quail knows that it's about to do something weird that is not going to signal pre-command-hook because we are still awaiting more information before the command happens. If it works, it would mean that input-event-functions is not really fit for the purpose I intended and should, perhaps, be removed. Thoughts? Phil ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timing of input-method output 2019-02-11 22:10 ` Phillip Lord @ 2019-02-11 22:20 ` Stefan Monnier 2019-02-12 12:21 ` Phillip Lord 0 siblings, 1 reply; 22+ messages in thread From: Stefan Monnier @ 2019-02-11 22:20 UTC (permalink / raw) To: emacs-devel > Oh dear, that really does seem nasty to me. ;-) > I wonder if I am going about this in the wrong way. Given that this only > happens when quail is active, is it not quail that needs hooking? > "pre-quail-command-hook" or something. Quail knows that it's about to do > something weird that is not going to signal pre-command-hook because we > are still awaiting more information before the command happens. Yeah, it's probably better to try and hack Quail to better cooperate. > If it works, it would mean that input-event-functions is not really fit > for the purpose I intended and should, perhaps, be removed. When you added it, I thought you had already confirmed that it satisfies your needs. But if it doesn't, then maybe it's not a good hook. Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timing of input-method output 2019-02-11 22:20 ` Stefan Monnier @ 2019-02-12 12:21 ` Phillip Lord 2019-03-25 21:48 ` Phillip Lord 0 siblings, 1 reply; 22+ messages in thread From: Phillip Lord @ 2019-02-12 12:21 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Oh dear, that really does seem nasty to me. > > ;-) > >> I wonder if I am going about this in the wrong way. Given that this only >> happens when quail is active, is it not quail that needs hooking? >> "pre-quail-command-hook" or something. Quail knows that it's about to do >> something weird that is not going to signal pre-command-hook because we >> are still awaiting more information before the command happens. > > Yeah, it's probably better to try and hack Quail to better cooperate. > >> If it works, it would mean that input-event-functions is not really fit >> for the purpose I intended and should, perhaps, be removed. > > When you added it, I thought you had already confirmed that it satisfies > your needs. But if it doesn't, then maybe it's not a good hook. Well, I had checked that it did do what I wanted, in terms of stopping the buggy completion display. I hadn't checked that it didn't break the completion in the first place. Oh dear. I'll remove this and see if I can fix up quail instead with a hook there. As you say, perhaps the ultimate fix is to change quail to enter information in a different way, but one step at a time. Phil ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timing of input-method output 2019-02-12 12:21 ` Phillip Lord @ 2019-03-25 21:48 ` Phillip Lord 2019-03-26 15:12 ` Stefan Monnier 0 siblings, 1 reply; 22+ messages in thread From: Phillip Lord @ 2019-03-25 21:48 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan I've done a bit more work on this and come up with a much simpler solution which is specificially plumbed into quail. It looks like this: modified lisp/international/quail.el @@ -59,6 +59,10 @@ quail "Quail: multilingual input method." :group 'leim) + +(defvar quail-pre-translation-hook nil + "Normal hook run before quail starts or updates a translation.") + ;; Buffer local variables (defvar quail-current-package nil @@ -1548,6 +1552,7 @@ quail-update-translation `quail-current-key'. If CONTROL-FLAG is nil, proceed the translation with more keys." (let ((func (quail-update-translation-function))) + (run-hooks 'quail-pre-translation-hook) (if func (setq control-flag (funcall func control-flag)) (cond ((numberp control-flag) pabbrev.el uses this very simply like so: (add-hook 'quail-pre-translation-hook 'pabbrev-pre-command-hook nil t) (add-hook 'pre-command-hook 'pabbrev-pre-command-hook nil t) (add-hook 'post-command-hook 'pabbrev-post-command-hook nil t) pabbrev-pre-command-hook was always badly named (since it's the function to go on a hook, not a variable defining a hook), and is now worse. Basically, we just run the "remove the abbreviation expansion which is being offered in readiness for a command to run". So, a couple of questions: pre-command-hook is current run by "safe_run_hooks". Does `quail-pre-translation-hook' need to be as well (in which case, it would need uncovering in lisp)? I guess the counter here is that it's possible to get out so long as you don't type certain characters, or you change buffer. But, it leaves emacs fairly unusuable none the less. And, where do you think I should document it? Perhaps "Invoking the Input Method"; but "Command Loop Overview" is the place where the people who might want to use it might actually see it? Phil ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timing of input-method output 2019-03-25 21:48 ` Phillip Lord @ 2019-03-26 15:12 ` Stefan Monnier 2019-03-28 13:54 ` Phillip Lord 0 siblings, 1 reply; 22+ messages in thread From: Stefan Monnier @ 2019-03-26 15:12 UTC (permalink / raw) To: Phillip Lord; +Cc: emacs-devel > I've done a bit more work on this and come up with a much simpler > solution which is specificially plumbed into quail. It looks like this: > > modified lisp/international/quail.el > @@ -59,6 +59,10 @@ quail > "Quail: multilingual input method." > :group 'leim) > > + > +(defvar quail-pre-translation-hook nil > + "Normal hook run before quail starts or updates a translation.") > + > ;; Buffer local variables > > (defvar quail-current-package nil > @@ -1548,6 +1552,7 @@ quail-update-translation > `quail-current-key'. If CONTROL-FLAG is nil, proceed the translation > with more keys." > (let ((func (quail-update-translation-function))) > + (run-hooks 'quail-pre-translation-hook) > (if func > (setq control-flag (funcall func control-flag)) > (cond ((numberp control-flag) This looks pretty good, but I'd like to better understand why this works well. I.e. how did you end up putting it there rather than elsewhere? > pre-command-hook is current run by "safe_run_hooks". Does > `quail-pre-translation-hook' need to be as well (in which case, it would > need uncovering in lisp)? I guess the counter here is that it's possible > to get out so long as you don't type certain characters, or you change > buffer. But, it leaves emacs fairly unusuable none the less. IIUC C-\ should get you out, so I don't think it's necessary to take any extra caution here. > And, where do you think I should document it? Perhaps "Invoking the > Input Method"; That's probably the best place. Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timing of input-method output 2019-03-26 15:12 ` Stefan Monnier @ 2019-03-28 13:54 ` Phillip Lord 0 siblings, 0 replies; 22+ messages in thread From: Phillip Lord @ 2019-03-28 13:54 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> I've done a bit more work on this and come up with a much simpler >> solution which is specificially plumbed into quail. It looks like this: >> >> modified lisp/international/quail.el >> @@ -59,6 +59,10 @@ quail >> "Quail: multilingual input method." >> :group 'leim) >> >> + >> +(defvar quail-pre-translation-hook nil >> + "Normal hook run before quail starts or updates a translation.") >> + >> ;; Buffer local variables >> >> (defvar quail-current-package nil >> @@ -1548,6 +1552,7 @@ quail-update-translation >> `quail-current-key'. If CONTROL-FLAG is nil, proceed the translation >> with more keys." >> (let ((func (quail-update-translation-function))) >> + (run-hooks 'quail-pre-translation-hook) >> (if func >> (setq control-flag (funcall func control-flag)) >> (cond ((numberp control-flag) > > This looks pretty good, but I'd like to better understand why this > works well. I.e. how did you end up putting it there rather than elsewhere? I do not have a terribly principled answer to this; quail is complicated and has lots of edge cases that I do not understand. If I understand it correctly, I could equally have put this into quail-self-insert-command; but here it is right before the bit that the translation actually happens. >> pre-command-hook is current run by "safe_run_hooks". Does >> `quail-pre-translation-hook' need to be as well (in which case, it would >> need uncovering in lisp)? I guess the counter here is that it's possible >> to get out so long as you don't type certain characters, or you change >> buffer. But, it leaves emacs fairly unusuable none the less. > > IIUC C-\ should get you out, so I don't think it's necessary to take any > extra caution here. Yes, if you know what is causing the problem. But you are correct, it is escapable. > >> And, where do you think I should document it? Perhaps "Invoking the >> Input Method"; > > That's probably the best place. Will extend. Phil ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2019-03-28 13:54 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <20190122214637.25164.20429@vcs0.savannah.gnu.org> [not found] ` <20190122214639.B2E13203DD@vcs0.savannah.gnu.org> 2019-01-22 23:17 ` master 7b31de4: Add hook for all events Michael Albinus 2019-01-23 22:56 ` Phillip Lord 2019-01-24 3:36 ` Eli Zaretskii 2019-01-23 1:30 ` [Emacs-diffs] " Daniel Colascione 2019-01-23 23:10 ` Phillip Lord 2019-01-24 2:06 ` Stefan Monnier 2019-01-24 10:41 ` Phillip Lord 2019-01-25 13:56 ` Stefan Monnier 2019-01-28 9:42 ` Phillip Lord 2019-01-26 0:50 ` Stefan Monnier 2019-01-28 9:54 ` Phillip Lord 2019-02-02 16:13 ` Timing of input-method output (was: [Emacs-diffs] master 7b31de4: Add hook for all events) Stefan Monnier 2019-02-03 22:06 ` Timing of input-method output Phillip Lord 2019-02-05 14:49 ` Stefan Monnier 2019-02-06 22:18 ` Phillip Lord 2019-02-06 22:55 ` Stefan Monnier 2019-02-11 22:10 ` Phillip Lord 2019-02-11 22:20 ` Stefan Monnier 2019-02-12 12:21 ` Phillip Lord 2019-03-25 21:48 ` Phillip Lord 2019-03-26 15:12 ` Stefan Monnier 2019-03-28 13:54 ` Phillip Lord
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).