bug#18643: 25.0.50; elisp--expect-function-p

[Dmitry Gutov <dgutov@yandex.ru>]

On 10/10/2014 03:43 AM, Leo Liu wrote:

> Is it possible to use weight or priority i.e. the context decided
> doesn't cut completion space to a subset but instead prioritise those
> fit into the context by putting them at the front. Or find a way to
> allow other completions to show up when the input matches none of the
> subset.

It wouldn't be the worst approach, but we should be able to do better.

> Also could we not force users to insert ` before any completion in
> strings or comments.

Please don't ignore the available information about why things work as 
they do currently. Have you looked at the revision that introduced that 
change? Do you have anything to add to the discussion in the related bug?

> BTW, this is what happens when false negative hits:
>
> 1. If I remember the completion and it is short I type it output but
>     often I double check with C-h f or C-h v to make sure it is correct.
>
> 2. When it is long or I don't remember I have to use C-h f or C-h v and
>     copy it over from the *Help* buffer.
>
> The cost is high and painful.

Personally, I use `hippie-expand' as an escape hatch, in the rare cases 
I have this problem. It might be painful sometimes, but I don't think 
it's frequent.

Here's what happens because of false positives:

1. Write some function call, need to pass in a dynamic variable, invoke 
completion. Yeah, this one looks kinda right. `eval-defun', run... Nope! 
This one was just a poorly named function.

2. The reverse, for a symbol in funcall position.

3. Type a short prefix, invoke completion. Get a myriad things to sort 
through.

So, with code completion working this way you also have to use C-h f and 
C-h v more often than you might have had to otherwise, if only to verify 
that your code makes sense.