[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#18643: 25.0.50; elisp--expect-function-p
From: |
Leo Liu |
Subject: |
bug#18643: 25.0.50; elisp--expect-function-p |
Date: |
Thu, 09 Oct 2014 11:31:13 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (CentOS 6.5) |
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
- bug#18643: 25.0.50; elisp--expect-function-p, Leo Liu, 2014/10/06
- bug#18643: 25.0.50; elisp--expect-function-p, Dmitry Gutov, 2014/10/08
- bug#18643: 25.0.50; elisp--expect-function-p,
Leo Liu <=
- bug#18643: 25.0.50; elisp--expect-function-p, Dmitry Gutov, 2014/10/09
- bug#18643: 25.0.50; elisp--expect-function-p, Stefan Monnier, 2014/10/09
- bug#18643: 25.0.50; elisp--expect-function-p, Leo Liu, 2014/10/09
- bug#18643: 25.0.50; elisp--expect-function-p, Stefan Monnier, 2014/10/09
- bug#18643: 25.0.50; elisp--expect-function-p, Leo Liu, 2014/10/10
- bug#18643: 25.0.50; elisp--expect-function-p, Stefan Monnier, 2014/10/10
- bug#18643: 25.0.50; elisp--expect-function-p, Dmitry Gutov, 2014/10/10
- bug#18643: 25.0.50; elisp--expect-function-p, Leo Liu, 2014/10/10
- bug#18643: 25.0.50; elisp--expect-function-p, Stefan Monnier, 2014/10/11
- bug#18643: 25.0.50; elisp--expect-function-p, Leo Liu, 2014/10/11