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

[Dmitry Gutov]

Hi Leo,

Leo Liu <sdl.web@gmail.com> writes:
> emacs should only constrain itself to function completion when
> absolutely sure.

How can we make sure? I think macro-expansion could help in some cases,
but implementing that approach is a bit beyond me.

> It is not a big deal if function names creep into variable completion or
> vice versa. Often it is handy to complete to an existing symbol and then
> edit it into something else.

IME, context-sensitive completion is useful, and people like it.

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.

> 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.

> There are a few places where I expect to have a completion based on my
> past experience but fail now. For example, in (pred ...) pattern of
> pcase. Other failures, (let (|)) and (let ((|))) where | is point.

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.

> 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.

-- Dmitry