GNU bug report logs - #16604
24.3.50; False negatives in lisp-completion-at-point

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 16604 <at> debbugs.gnu.org
Subject: bug#16604: 24.3.50; False negatives in lisp-completion-at-point
Date: Tue, 04 Feb 2014 12:54:34 -0500

> I'm not sure I understand. Would there be a variable defining a regexp or
> glob for variable and function names that will be ignored unless they are
> the only candidates?

I was thinking of a new property which would define a function which
reduces the set of candidates considered for
completion-try-completions.  File completion could use it to implement
completion-ignored-extensions and we could use it here to prefer
a local varname.

>> Also, we should try and check that the sub-tables all have "trivial"
>> boundaries, and no quoting.

> Do we do that at "runtime" (after the lambda has been returned)? And just
> blow up calls with action `metadata' or `boundaries . ...' with error
> whenever that's not true?

We don't want to do those checks all the time, so it should probably be
done only once when we combine the two tables (if possible) or not at all.

> I figured just documenting problematic cases might be enough (like
> completion-table-in-turn' does, I suppose it has a similar problem with
> quoting).

Right.

> Sounds not very efficient.

Probably lost in the noise.

> See the updated patch, does this look right to you?

Could be, see below.

> I have a hard time testing it, though. lisp-completion-at-point seems to
> suggest any symbols that I've ever typed anyway, so there's no way to check
> that lisp--local-variables-completion-table is even used.

Sounds like a bug in lisp-completion-at-point.

> +      (let ((retvals (mapcar (lambda (table)
> +                               (try-completion string table pred))
> +                             tables))
> +            (prelim (try-completion string retvals pred)))

try-completion's behavior when passed a list mixing strings and symbols
is not really defined.  So this second call to `try-completion' relies
on largely undocumented behavior.  Two solutions: either you add
a comment about what behavior you assume, or you change the code to
avoid this problem.

E.g. change retvals with (delq nil ...) and replace t with `string'.


        Stefan

Previous Next

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