Re: Timing of input-method output

[Phillip Lord]

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