GNU bug report logs - #17139
Race condition in complete-in-region: should we be using pre-command-hook, not post-command-hook?

Previous Next

Package: emacs;

Reported by: Daniel Colascione <dancol <at> dancol.org>

Date: Sat, 29 Mar 2014 02:19:02 UTC

Severity: normal

Done: Noam Postavsky <npostavs <at> users.sourceforge.net>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 17139 <at> debbugs.gnu.org
Subject: bug#17139: Race condition in complete-in-region: should we be using pre-command-hook, not post-command-hook?
Date: Mon, 31 Mar 2014 08:40:04 -0400
> 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.


        Stefan




This bug report was last modified 8 years and 348 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.