Re: pre-command-hook with input methods

[phillip.lord@newcastle.ac.uk (Phillip Lord)]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> All fine, but it's breaking my completion framework which removes
>> previously offered completions on the pre-command-hook.
>
> Indeed, I wouldn't be surprised if several other uses of
> pre-command-hook could suffer from unexpected behaviors in
> such situations.

At a quick test, the auto-complete package also behaves badly wrt input
methods. The on-screen output is bizarre, although what you end up with
in the buffer looks correct, so I guess it is the same problem.

>
>> I need it to run as soon as the "a" key has been pressed.
>
> Of course, you can do that using one of the input-method hooks (maybe
> input-method-after-insert-chunk-hook), or you could rely on
> before-change-functions.

Gave that a quick go. As far as I can see, after-insert-chunk-hook
runs after the input is complete. Likewise, b-c-f which only runs when
the buffer has changed.


>> Is there a better hook?
>
> I don't think so, sadly.
>
> Maybe we could introduce a new hook like `after-idle-hook'.  Part of the
> question is what should happen if a timer or a process filter runs
> (these can run while Emacs is "idle")?  How 'bout when that
> timer/process-filter inserts text near/at point?

I do buffer analytics in the idle cycle -- I would guess that the same
thing is true for most completion packages. So I'd need to be able to
distinguish between this and the user doing something.

What about after-user-interaction-hook? Or
after-something-has-happened-that-changes-the-display-on-screen-of-a-buffer.
Although the latter might be affected by things that change the mode
line in the idle cycle (like a word count mode).

Phil