Re: pre-command-hook with input methods

[Stefan Monnier]

> Had a bit of a nightmare building from trunk. I still do not understand
> why this happens so inconsistently for me; my "main" clone failed to
> build even after make bookstrap, but a clone of the clone worked fine.

The "original clone" was probably not completely clean, and the recent
change that removed lisp.mk required rebuilding the Makefile in a way
that's not handled by "make bootstrap".  Our makefiles have a lot of
circular dependencies (e.g. they're built from autoconf/automake files, so
the makefiles themselves need to be re-made).  I suggest you file a bug
report about it: we really should split the "bootstrap" target into two:
one that handles the Elisp-bootstrapping (where we first need to build
a "bootstrap-emacs" with ldefs-boot.el and uncompiled files and then build
the real loaddefs.el and compile the .el files to then build the real
"emacs"), and another that handles the "build machinery's own bootstrap"
(which would remove a few more files than the current "bootstrap" but
wouldn't need to remove the .elc and loaddefs.el files).

> I really must be doing something wrong thing.

No, it's not just you.  Many people have bumped into this.  I bumped
into it as well, it's just that my experience allowed me to handle it
without too much trouble.

> This appears to work.

Thanks for confirming.

> Using italian-postfix, with -off set to t in
> scratch I get, after typing "bu" I get

> b[u]u_

IIUC that's because you had "b[u]" before you typed the "u" which
then inserted "u_" without running pre-command-hook (since we don't know
yet exactly what command we're going to run).

> With it -off set to nil, I get

> bu_

> (i.e. a u waiting for the dead-key).

And here the "[u]" is gone because we ran pabbrev-input-event-functions
right after reading the "u".

> At the moment, this also means that it's never possible to complete
> after a "u" (or a "u`") or any character with a dead key.

Not sure what you mean here.  It prevents pabbrev from *displaying* the
completion, but it doesn't prevent the user from causing the completion
(assuming she guessed what the completion would be, despite not seeing
it displayed), right?

> That would require quite a lot more thought; I guess that the "u" you
> can see on screen is not really in the buffer until the command (and
> key sequence) has completed anyway.

IIRC the way quail works, the "u_" is very much inserted in the buffer
(it's not just a display-only artifact such as an overlay with an
after-string, tho it could also use such a thing), but not via a command
(e.g. self-insert-command) but via quail's internal code and that "u_"
will be erased before we (later) run pre-command-hook and then
self-insert-command.

> Still if someone really cared about this, they could switch to
> a pre-fix method.

That should suffer from the same problem, tho affecting the "accent"
chars rather then u/e/...

To solve this problem in general, I guess we could/should generalize
input-event-functions into a before-input-event-functions (aka
after-read-event-functions) and an after-input-event-functions (aka
before-read-event-functions).

So you could use after-input-event-functions instead of post-command-hook
to insert pabbrev's completion "box".

> I tried french-prefix and that works nicely,
> although, even using Emacs, I still can't actually speak French.

Hmm... sounds like a bug in the "french-prefix" method.  Oh wait, no
indeed it only lets you write French, but not speak it.  You could still
open a feature request for it, tho.

> So, the practical upshot is, yes, it seems to work nicely!

> Phil



> Stefan Monnier <address@hidden> writes:

>>> I think so yes -- so long as input-event means "user input-event" or I
>>> have some way of telling. Something coming in from a process, or
>>> file-watch notifications need to be ignored.
>> 
>> Could you try the patch below to see if it provides the feature
>> you need?
>> 
>> 
>> Stefan
>> 
>> 
>> diff --git a/etc/NEWS b/etc/NEWS
>> index 1cccc31..f1b7119 100644
>> --- a/etc/NEWS
>> +++ b/etc/NEWS
>> @@ -811,6 +811,8 @@ behavior, set `diff-switches' to `-c'.
>> 
>> * Lisp Changes in Emacs 25.1
>> 
>> +** New hook `input-event-functions' run whenever a user-input event is read.
>> +
>> ** The default value of `load-read-function' is now `read'.
>> 
>> ** New hook `pre-redisplay-functions', a bit easier to use than 
>> pre-redisplay-function.
>> diff --git a/lisp/subr.el b/lisp/subr.el
>> index b9a847d..df0ed42 100644
>> --- a/lisp/subr.el
>> +++ b/lisp/subr.el
>> @@ -1110,6 +1110,12 @@ See `event-start' for a description of the value 
>> returned."
>> "Return the multi-click count of EVENT, a click or drag event.
>> The return value is a positive integer."
>> (if (and (consp event) (integerp (nth 2 event))) (nth 2 event) 1))
>> +
>> +(defvar input-event-functions nil
>> +  ;; BEWARE: If it looks like this is not run anywhere, it's normal:
>> +  ;; this is run in keyboard.c.
>> +  "Special hook run each time a user-input event is read.
>> +Each function is called with one argument: the event.")
>> 
>> ;;;; Extracting fields of the positions in an event.
>> 
>> diff --git a/src/keyboard.c b/src/keyboard.c
>> index eb66c44..5c64199 100644
>> --- a/src/keyboard.c
>> +++ b/src/keyboard.c
>> @@ -2454,7 +2454,7 @@ read_char (int commandflag, Lisp_Object map,
>> /* Also check was_disabled so last-nonmenu-event won't return
>> a bad value when submenus are involved.  (Bug#447)  */
>> && (EQ (c, Qtool_bar) || EQ (c, Qmenu_bar) || was_disabled))
>> -    *used_mouse_menu = 1;
>> +    *used_mouse_menu = true;
>> 
>> goto reread_for_input_method;
>> }
>> @@ -2995,6 +2995,8 @@ read_char (int commandflag, Lisp_Object map,
>> if (! NILP (also_record))
>> record_char (also_record);
>> 
>> +  Frun_hook_with_args (2, ((Lisp_Object []) {Qinput_event_functions, c}));
>> +
>> /* Wipe the echo area.
>> But first, if we are about to use an input method,
>> save the echo area contents for it to refer to.  */
>> @@ -3986,7 +3988,7 @@ kbd_buffer_get_event (KBOARD **kbp,
>> obj = list1 (intern ("ns-unput-working-text"));
>> kbd_fetch_ptr = event + 1;
>> if (used_mouse_menu)
>> -            *used_mouse_menu = 1;
>> +            *used_mouse_menu = true;
>> }
>> #endif
>> 
>> @@ -4181,13 +4183,13 @@ kbd_buffer_get_event (KBOARD **kbp,
>> && !EQ (event->frame_or_window, event->arg)
>> && (event->kind == MENU_BAR_EVENT
>> || event->kind == TOOL_BAR_EVENT))
>> -            *used_mouse_menu = 1;
>> +            *used_mouse_menu = true;
>> #endif
>> #ifdef HAVE_NS
>> /* Certain system events are non-key events.  */
>> if (used_mouse_menu
>> && event->kind == NS_NONKEY_EVENT)
>> -            *used_mouse_menu = 1;
>> +            *used_mouse_menu = true;
>> #endif
>> 
>> /* Wipe out this event, to catch bugs.  */
>> @@ -8445,7 +8447,7 @@ read_char_x_menu_prompt (Lisp_Object map,
>> Lisp_Object prev_event, bool *used_mouse_menu)
>> {
>> if (used_mouse_menu)
>> -    *used_mouse_menu = 0;
>> +    *used_mouse_menu = false;
>> 
>> /* Use local over global Menu maps.  */
>> 
>> @@ -8494,7 +8496,7 @@ read_char_x_menu_prompt (Lisp_Object map,
>> else if (NILP (value))
>> value = Qt;
>> if (used_mouse_menu)
>> -    *used_mouse_menu = 1;
>> +    *used_mouse_menu = true;
>> return value;
>> }
>> return Qnil ;
>> @@ -9067,7 +9069,7 @@ read_key_sequence (Lisp_Object *keybuf, int bufsize, 
>> Lisp_Object prompt,
>> : (/* indec.start < t || fkey.start < t || */ keytran.start < t))
>> {
>> Lisp_Object key;
>> -      bool used_mouse_menu = 0;
>> +      bool used_mouse_menu = false;
>> 
>> /* Where the last real key started.  If we need to throw away a
>> key that has expanded into more than one element of keybuf
>> @@ -11078,6 +11080,7 @@ syms_of_keyboard (void)
>> DEFSYM (Qself_insert_command, "self-insert-command");
>> DEFSYM (Qforward_char, "forward-char");
>> DEFSYM (Qbackward_char, "backward-char");
>> +  DEFSYM (Qinput_event_functions, "input-event-functions");
>> 
>> /* Non-nil disable property on a command means do not execute it;
>> call disabled-command-function's value instead.  */