Re: pre-command-hook with input methods

[Phillip Lord]

Stefan Monnier <address@hidden> writes:

>> 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 know, I have been reading the mailing list. But I managed to get
several different results from slightly different copies of the source
-- one that build, on that failed to compile the lisp, and one core
dumped.

> 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'd like some "build absolutely from start" clean. Emacs doesn't take
that long to build these days, and I'd value being able to start from a
clean state after switching branch.

More or less by definition, I don't have a clean bug to report. Although
I have a different one, wrt to the build, so I'll send that one in!



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

Yes, exactly. And trying to use pabbrev in these circumstances is next
to impossible, since you have two "completions" on show at once. It even
affects normal typing since the cursor effectively jumps.

>> 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".

Yes, which is what I wanted.


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

I think with the way that I have coded it, actually, the wrong
completion would happen. So, after typing

b

we get offered

b[uffer] (ie pabbrev is offering "uffer" as a completion).

Now we type "u", so quail offers

bu_

but the "uffer" completion is still active (since we've had no
post-c-h), so that's clearly a bug.

The key point is that completion is offering in the gap between
post-command-hook and pre-command-hook which is normally idle. But when
a quail completion is offered typing "f" causes pre-command (on the u),
post-command (on the u), pre-command (on the f) and post-command (on the
f again) without any gaps.



>> 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.

Okay, so it might just be possible to offer the right completion -- so
after typing

"bu" we offer completions on "bu", after "bu`" we offer "bu`".

I am not sure I would go this route with pabbrev, though, simply because
pabbrev would be offering an in-buffer completion, while quail is
offering a different one in the minibuffer.


>> 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/...

Yes. Although (like most completion frameworks) pabbrev is word-centric,
so after "b`" (i.e. b followed by ` because that's what I want, not
because I am next going to type u and get an accent) there are no
completions anyway, since there is no word before point.

I am sure that there is some mode in existance where ` is word syntax,
but life is too short to worry.


> 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".

This makes sense, but I'd really need to think about it carefully. It
sounds like a straight swap (i.e. pre/post command for
befor/after-input), but I wonder whether accepting the completion would
work as currently. If it works, though, it would potentially be cleaner,
since I've got duplicated logic on pre-command and input-event-functions
at the moment.

Is it easy to try? I guess you just add another run_hooks_with_args call
somewhere in read_char, but being honest, I am slightly intimidated by a
function like read_char, I would not want to guess where it should be
added.



>> 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.

Nah, don't know anyone who speaks French anyway.

A` biento^t!

Phil