* bug#67514: 30.0.50; completion preview symbol length calculation should use point @ 2023-11-28 20:39 Herman, Géza 2023-11-28 21:46 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 6+ messages in thread From: Herman, Géza @ 2023-11-28 20:39 UTC (permalink / raw) To: 67514 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))))) ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#67514: 30.0.50; completion preview symbol length calculation should use point 2023-11-28 20:39 bug#67514: 30.0.50; completion preview symbol length calculation should use point Herman, Géza @ 2023-11-28 21:46 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-11-28 23:17 ` Herman, Géza 0 siblings, 1 reply; 6+ messages in thread From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-28 21:46 UTC (permalink / raw) To: Géza Herman; +Cc: 67514 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#67514: 30.0.50; completion preview symbol length calculation should use point 2023-11-28 21:46 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-28 23:17 ` Herman, Géza 2023-11-29 8:55 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 6+ messages in thread From: Herman, Géza @ 2023-11-28 23:17 UTC (permalink / raw) To: Eshel Yaron; +Cc: 67514, Géza Herman 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)? ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#67514: 30.0.50; completion preview symbol length calculation should use point 2023-11-28 23:17 ` Herman, Géza @ 2023-11-29 8:55 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-11-29 9:06 ` Herman, Géza 0 siblings, 1 reply; 6+ messages in thread From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-29 8:55 UTC (permalink / raw) To: Géza Herman; +Cc: 67514 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#67514: 30.0.50; completion preview symbol length calculation should use point 2023-11-29 8:55 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-29 9:06 ` Herman, Géza 2023-11-29 21:26 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 6+ messages in thread From: Herman, Géza @ 2023-11-29 9:06 UTC (permalink / raw) To: Eshel Yaron; +Cc: 67514, Géza Herman 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! ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#67514: 30.0.50; completion preview symbol length calculation should use point 2023-11-29 9:06 ` Herman, Géza @ 2023-11-29 21:26 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 0 replies; 6+ messages in thread From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-29 21:26 UTC (permalink / raw) To: Herman, Géza; +Cc: 67514 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! ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-11-29 21:26 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-11-28 20:39 bug#67514: 30.0.50; completion preview symbol length calculation should use point Herman, Géza 2023-11-28 21:46 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-11-28 23:17 ` Herman, Géza 2023-11-29 8:55 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-11-29 9:06 ` Herman, Géza 2023-11-29 21:26 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.