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

[Herman@debbugs.gnu.org, Géza <geza.herman@gmail.com>]

Eshel Yaron <me@eshelyaron.com> writes:

> Géza Herman <geza.herman@gmail.com> writes:
>
>> Eshel Yaron <me@eshelyaron.com> writes:
>>
>>> ...`completion-at-point-functions` take into account text that
>>> follows point as well as the text that precedes point, and 
>>> Completion
>>> Preview mode works also when you're typing in the middle of a 
>>> symbol.
>>> For example, consider the following text in an Elisp buffer...
>>
>> I didn't know about this behavior, it makes sense how it works 
>> in
>> emacs-lisp-mode.  I tried this feature with lsp-mode (using the
>> clangd language server), and it doesn't play this nicely.
>>
>> Suppose that you have this C code:
>>
>> int main() {
>>     int longVariableName = 0;
>>
>>     VariableName = 1;
>> }
>>
>> And the point is at the first character at VariableName.  Now,
>> pressing "l" will preview longVariableName, but it doesn't do
>> anything with VariableName, so the buffer looks like
>> l(ongVariableName)VariableName (parentheses are not part of the
>> text, I used them to mark the greyed out part).
>
> 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.

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

(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?)

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