GNU bug report logs -
#65578
Eglot with mouse
Previous Next
Reported by: Juri Linkov <juri <at> linkov.net>
Date: Mon, 28 Aug 2023 07:35:01 UTC
Severity: normal
Fixed in version 30.1
Done: Dmitry Gutov <dmitry <at> gutov.dev>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Thu, 31 Aug 2023 03:27:29 +0300
with message-id <6752a462-ac85-65b5-e960-023215a3ca6a <at> gutov.dev>
and subject line Re: bug#65578: Eglot with mouse
has caused the debbugs.gnu.org bug report #65578,
regarding Eglot with mouse
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
65578: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65578
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
X-Debbugs-CC: João Távora <joaotavora <at> gmail.com>
0. emacs -Q
1. enable context-menu-mode
2. enable eglot in a suitable buffer
3. move point to one identifier
4. click the right mouse button on another identifier
5. in the context menu click "Find Definition"
The problem is that a wrong identifier is visited.
Whereas 'xref-find-definitions-at-mouse' takes care
about getting the right identifier at the clicked position,
Eglot returns a fictitious identifier "LSP identifier at point"
that can't be used to find the identifier at the mouse click.
xref-find-definitions-at-mouse uses save-excursion with
mouse-set-point before calling xref-backend-identifier-at-point.
But the same save-excursion with mouse-set-point can't be added
around xref-find-definitions because save-excursion will restore
the original position after visiting the found identifier.
Also tried to add xref-find-definitions-at-mouse to the list
xref-prompt-for-identifier, no effect.
Then tried to remove '(xref--prompt-p this-command)'
from 'xref-backend-identifier-at-point ((_backend (eql eglot)))'.
This fixed xref-find-definitions-at-mouse, but still
doesn't work for xref-find-references-at-mouse.
Also removing '(xref--prompt-p this-command)' has such a strange effect
that it started to find approximate fuzzy matches that sound like
the original identifier.
[Message part 3 (message/rfc822, inline)]
Version: 30.1
On 30/08/2023 19:35, Juri Linkov wrote:
>>>> @@ -1637,7 +1637,9 @@ xref-find-definitions-at-mouse
>>>> - (xref-find-definitions identifier)
>>>> + (progn
>>>> + (mouse-set-point event)
>>>> + (xref-find-definitions identifier))
>>>> (user-error "No identifier here"))))
>>> The problem with this solution is that when it doesn't find
>>> the identifier then it leaves point at the wrong place.
>> I'm not sure is a big problem, but we could save the original position and
>> restore it in case of error too:
> Thanks. I tend to agree with João that your initial version would be
> sufficient to leave point at the position of right-clicking.
>
> Then the same change is also needed in xref-find-references-at-mouse
> with mouse-set-point before xref-find-references.
Very good, if you don't mind the side-effect too, I've pushed the fix
for both functions to master. And closing.
BTW, this context-menu-mode is looking pretty nifty. It'd be nice to
turn it on by default someday.
This bug report was last modified 1 year and 323 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.