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

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

[Herman, Géza]

I checked out completion-preview, and so far I like it.  There is a
thing which maybe can be improved (so this is not a bug report, just a
suggestion): it's how completion-preview-require-minimum-symbol-length
calculates the length.  Currently it just returns the length of the
symbol under the cursor.  I think it would be better to use the length
of the part that actually will be used for completion, because if the
point is inside a word, then it should only consider the part between
the symbol start end the point.

I mean, completion-preview-require-minimum-symbol-length should look
something like this:

(let ((bounds (bounds-of-thing-at-point 'symbol)))
      (and bounds (<= completion-preview-minimum-symbol-length
                      (- (point) (car bounds)))))

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

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

> I checked out completion-preview, and so far I like it.

Great.

> There is a thing which maybe can be improved (so this is not a bug
> report, just a suggestion): it's how
> completion-preview-require-minimum-symbol-length calculates the
> length.  Currently it just returns the length of the symbol under the
> cursor.  I think it would be better to use the length of the part that
> actually will be used for completion, because if the point is inside a
> word, then it should only consider the part between the symbol start
> end the point.

Could you please explain why you consider that preferable?  The current
behavior is intentional and, unless I'm missing something, correct.
`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:

--8<---------------cut here---------------start------------->8---
(minor
--8<---------------cut here---------------end--------------->8---

With point between the opening parenthesis and the letter "m", type
"define-".  The completion preview displays "-mode" just after "minor",
suggesting that you complete to "define-minor-mode".  That's because the
text after point ("minor", in this case) plays a role too.


Best,

Eshel

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

[Herman, Géza]

Eshel Yaron <me@eshelyaron.com> writes:

> Géza Herman <geza.herman@gmail.com> writes:
>
>> There is a thing which maybe can be improved (so this is not a 
>> bug
>> report, just a suggestion): it's how
>> completion-preview-require-minimum-symbol-length calculates the
>> length.  Currently it just returns the length of the symbol 
>> under the
>> cursor.  I think it would be better to use the length of the 
>> part that
>> actually will be used for completion, because if the point is 
>> inside a
>> word, then it should only consider the part between the symbol 
>> start
>> end the point.
>
> Could you please explain why you consider that preferable?  The 
> current
> behavior is intentional and, unless I'm missing something, 
> correct.
> `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:
>
> --8<---------------cut 
> here---------------start------------->8---
> (minor
> --8<---------------cut 
> here---------------end--------------->8---
>
> With point between the opening parenthesis and the letter "m", 
> type
> "define-".  The completion preview displays "-mode" just after 
> "minor",
> suggesting that you complete to "define-minor-mode".  That's 
> because the
> text after point ("minor", in this case) plays a role too.

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:

--8<---------------cut here---------------start------------->8---
int main() {
    int longVariableName = 0;

    VariableName = 1;
}
--8<---------------cut here---------------end--------------->8---

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

My suggestion doesn't fix this, it just postpones this problem 
until I write "lon", and then the same thing will happen. The 
reason that I suggested this is that I use evil-mode, and I put 
evil-insert to completion-preview-commands.  So whenever I enter 
insert mode, preview could happen.  And a lot of cases, I enter 
insert mode while the point is at the beginning of some word.  So 
with my suggestion, preview won't be happening, if the point is at 
the beginning of the word.  But currently when I enter insert 
mode, a random preview will be presented, because completion uses 
an empty string.  Perhaps this is what makes the difference? While 
emacs-lisp-mode uses the whole word for completion (so my 
suggestion doesn't make sense in this case), but lsp-mode/clangd 
uses just part of the word until the point (my suggestion makes 
some sense in this case)?

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

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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.

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

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

I'm curious, because perhaps your use case can be solved more directly.

> So whenever I enter insert mode, preview could happen.  And a lot of
> cases, I enter insert mode while the point is at the beginning of some
> word.  So with my suggestion, preview won't be happening, if the point
> is at the beginning of the word.  But currently when I enter insert
> mode, a random preview will be presented, because completion uses an
> empty string.

See above.

> Perhaps this is what makes the difference? While emacs-lisp-mode uses
> the whole word for completion (so my suggestion doesn't make sense in
> this case), but lsp-mode/clangd uses just part of the word until the
> point (my suggestion makes some sense in this case)?

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.


Eshel

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

[Herman, Géza]

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!

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

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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!