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

[Leo Liu]

On 2014-10-09 06:50 +0400, Dmitry Gutov wrote:
> IME, context-sensitive completion is useful, and people like it.

I agree.

> Narrowing down the list of possible completions is often quite useful,
> especially when it can turn 2-3 completions into just one, which can be
> inserted with one key. I think we can sacrifice completion in certain
> rare cases to retain this advantage in general.

It is the false negatives that kill its usefulness in the case of elisp.
For example, (ert-deftest |) and (defun |) no longer have the
completions I need.

>> For example, one might need to create a variable name based on a
>> function name.
>
> I'm pretty sure writing a new variable definition is a much less
> frequent operation than referring to a variable in a function, or
> writing a function call. And code completion is most useful when one is
> referring to existing variables and functions.

I won't jump to such conclusions so soon. You are guessing users'
editing habits too much.

> If you care to enumerate the main problem cases, and how they fail, it
> shouldn't be too hard to add support for them. But of course, we'll
> continue to have false negatives in some cases, like third-party macros.

What is hard is having a good algorithm to determine completion types
correctly. Unfortunately what we have has too many false negatives. I'd
much prefer offering multiple candidates instead of showing no
completions and with completion-cycling I can get to most completions in
under a second.

>> I have experienced annoyances here and there and I think the fundamental
>> solution is not to second guess but complete liberally as we did before.
>
> That suggestions sounds like giving up to me.
>
> For what you're describing, you might like dabbrev-style completion, or
> a simple function that looks up symbols in obarray. If you're not using
> company-mode, maybe try porting company-dabbrev-code to
> completion-at-point-functions, and use that.
>
> I haven't spent a lot of time using the current trunk, but the recent
> changes replicate the logic from company-elisp, and I quite liked it
> (before it was deprecated in favor of company-capf). I haven't seen many
> complaints about function-variable separation there.
>
> That backend does have a `company-elisp-detect-function-context' user
> option (so that's another solution for the issue discussed here), but it
> doesn't seem to be used much (if at all), judging by the publicly
> available configurations.

My bug report is not based on anything other than completion-at-point,
the plain/standard emacs completion UI, which is what I use for elisp
for a long while and I am quite content with it. It can be less optimal
for other languages. but for elisp it has worked well in the past.

HTH,
Leo