bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#16604: 24.3.50; False negatives in lisp-completion-at-point


From: Stefan Monnier
Subject: bug#16604: 24.3.50; False negatives in lisp-completion-at-point
Date: Tue, 04 Feb 2014 12:54:34 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]