[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#17139: Race condition in complete-in-region: should we be using pre-
bug#17139: Race condition in complete-in-region: should we be using pre-command-hook, not post-command-hook?
Mon, 31 Mar 2014 08:40:04 -0400
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)
> Come to think of it, supplying a function instead of a simple list of
> strings as the completion table returned from the completion function
> would probably help too, since then completion-in-region--postch could
> inspect the first element of the returned list (the completion region
> start) without having to actually "force the promise" and resolve the
> whole list after every command.
Exactly: completion-in-region--postch does not need to know the
candidates. If you need a subprocess to get the list of candidates,
then foo-at-point-function is usually not the right place/time to build
this list, you should use completion-table-dynamic,
completion-table-with-cache, or something like that instead.
Some foo-at-point-function get away with building the list directly, but
then caching it so that subsequent calls (e.g. via
completion-in-region--postch) don't need to contact the subprocess again.
Of course, there could be cases where the star&end positions are
themselves computed by a subprocess, in which case
completion-in-region--postch would have to contact the subprocess.