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

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

bug#67514: 30.0.50; completion preview symbol length calculation should


From: Eshel Yaron
Subject: bug#67514: 30.0.50; completion preview symbol length calculation should use point
Date: Wed, 29 Nov 2023 22:26:07 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

tags 67514 notabug
close 67514
thanks

Géza Herman <geza.herman@gmail.com> writes:

> Eshel Yaron <me@eshelyaron.com> writes:
>
>> Géza Herman <geza.herman@gmail.com> writes:
>>
>>> ...I tried this feature with lsp-mode (using the clangd language
>>> server), and it doesn't play this nicely...
>>
>> I see that.  I think this is a bug in `lsp-mode`, FWIW.  You get the
>> same erroneous completion with `completion-at-point` in that case.
>> Eglot seems to do the right thing though.
>
> Yes, probably it's a bug.  Thanks for checking eglot, this means that
> the behavior comes from lsp-mode, not from clangd.
>
>>> My suggestion doesn't fix this, it just postpones this problem
>>> until I write "lon", and then the same thing will happen.
>>
>> Indeed.  What follows is a tangent, I'm happy to continue the
>> discussion but we can already close this as "notabug", unless you
>> think otherwise.
>
> Sure, feel free to close it.  It was just a suggestion in the first
> place, but in the light of the new information (modes usually use the
> whole symbol for completion), the current behavior is exactly what we
> wanted.

Great.  So this message should close the bug, unless there're some
permissions required to do that, in which case we'll ask someone else to
help with it.

>>> The reason that I suggested this is that I use evil-mode, and I put
>>> evil-insert to completion-preview-commands.
>>
>> Note that `completion-preview-commands` is a "list of commands that
>> should trigger completion preview", as the docstring says.  You seem
>> to indicate below that you often want `evil-insert` not to trigger
>> completion preview, so why add it to this list in the first place?
>
> In general, I want evil-insert to trigger the preview.  Suppose that
> you started to type something, you got the preview, but then you
> realize that you forgot something, so (without finishing the word) you
> move to some other part of the code, and do some modification there.
> Then you move back to your original position, and go to insert mode to
> continue typeing.  It makes sense that preview is triggered right at
> the moment when insert mode is activated.

I see, that makes sense.  I'm not sure that this is the most common
preference, but I think it's definitely a valid use case.  It relates to
a broader question, of whether we should provide more flexibility for
specifying the conditions in which the preview should appear.  In this
case, ISTM that current implementation should get you covered (barring
such misbehaving capfs).  If you find other cases in which more nuanced
control over when the preview appears would be helpful, I'd be
interested to hear about it.

> (Note: I added other evil commands to completion-preview-commands as
> well. For example, when I type "cw" in a middle of word, I want to
> trigger preview, just like if the end of a word deleted by usual emacs
> commands.  I know that kill-word is not on the list currently, but
> maybe it should be?)

Maybe, it's kind of hard to be exhaustive with this list, so we went
with only the minimum needed to provide a useful experience by default.
`kill-word` and `backward-kill-word` are good candidates, but OTOH it's
easy enough for users to add them if they want to.

>> AFAICT `lsp-mode` is giving you inappropriate completion suggestions,
>> and I don't think that it's up to Completion Preview mode to fix
>> that.  Is this problem common among other completion backends?  If so
>> we may consider adding some measure to circumvent it.  But it'd be
>> better to improve these backends instead, IMO.
>
> I tried scad-mode (this also uses capf), and it works correctly,
> similarly how emacs-lisp-mode works.  So it indeed seems that lsp-mode
> causes the problem.
>
> Thanks for your time!

Thank you!





reply via email to

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