Re: pre-command-hook with input methods

[Stefan Monnier]

> Ah, sorry.  The advice is actually on the variable, and no on the
> symbol stored in the variable? So it runs even if the value changes?

Ah, you're right that other packages won't use add-function, so they'll
stomp on our advice!

>> Maybe what you're after is just an input-event-hook?
> I think for consistency, the hook should run immediately before or after
> Emacs responds to C-u (or C-x) depending on whether it is pre- or post-.
> Effectively, the C-x of a C-xC-f is, I think equivalent to the first "a"
> of a "a`" post-fix input key sequence.  The only reason that the former
> works fine for me, and the latter is problematic is the latter changes the
> display of the buffer while the former changes just the mini-buffer.

So it sounds like you'd indeed be happy with an input-event-hook.

> The other possibility is not to have an interaction hook but to have a
> "the buffer has just changed in some way that is liable to cause a
> redisplay"-hook. I don't know that this would be better.  I throw it out
> as a possibility, depending on which is easier.

Then maybe the (new in 24.4) pre-redisplay-function could be used
for that.  Something like

    (add-function :before pre-redisplay-function
                  (lambda (wins)
                    (if (or (eq t wins)
                            (memq <mybuffer> (mapcar #'window-buffer wins)))
                        <take-foo-down>)))

Of course, this will require some care, since a redisplay happens
probably right after you've set things up (i.e. before you start
waiting for user input), and you don't want *that* redisplay to trigger
the <take-foo-down>.


        Stefan