[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Timing of input-method output

From: Phillip Lord
Subject: Re: Timing of input-method output
Date: Wed, 06 Feb 2019 22:18:21 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.90 (gnu/linux)

Stefan Monnier <address@hidden> 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)
   ((mouse-movement-p event) nil)
    (princ (format "event:%s i-h-k: %s i-m-f: %s\n" event 

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

(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

Also tried detecting the overlay

   (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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]