all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* eldoc/eglot help: Nothing to follow at point
@ 2025-01-29 12:34 emacs-list-18
  2025-02-04  7:49 ` Chris
  2025-02-05 11:17 ` Joel Reicher
  0 siblings, 2 replies; 6+ messages in thread
From: emacs-list-18 @ 2025-01-29 12:34 UTC (permalink / raw)
  To: help-gnu-emacs

Hi all,

 i have a problem with help buffers generated by eldoc out of an
 rustic/eglot buffer. 

 In the help buffer there is some text that is higlighted, and the
 tooltip shows a url to be followed for further information for that
 symbol, keyword, package... whatever.

 The thing is: when is try to open this link (mouse click), i get the
 message "Nothing to follow at point"

 The text properties of the hilighted symbol are (example):

 (keymap
    (keymap
     (mouse-2 . markdown-follow-thing-at-point)
     (follow-link . mouse-face))
    mouse-face markdown-highlight-face font-lock-multiline t help-echo
 "https://doc.rust-lang.org/stable/std/std/fmt/index.html" face
 markdown-link-face)

 So now: who is the culprit?

 eglot seems to tell eldoc to produce a buffer in help-mode, but eldoc
 uses a markdown function as binding to a mouse event. 

Any ideas?

Chris

 



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: eldoc/eglot help: Nothing to follow at point
  2025-01-29 12:34 eldoc/eglot help: Nothing to follow at point emacs-list-18
@ 2025-02-04  7:49 ` Chris
  2025-02-05 11:17 ` Joel Reicher
  1 sibling, 0 replies; 6+ messages in thread
From: Chris @ 2025-02-04  7:49 UTC (permalink / raw)
  To: Emacs list reply

On Wed, 29 Jan 2025 13:34:26 +0100

For the record, my current solution is:

(defun eldoc-stuff-open-url-help-echo-property(event)
  "Open url at mouse click event location with default browser."
  (interactive "e") ;; get mouse event
  (if-let (;; get event location data
           (my-pos (event-end event))
           ;; window / buffer where the event happend
           (my-buffer (window-buffer (posn-window my-pos)))
           ;; get the property
           (my-property (get-text-property (posn-point my-pos) 'help-echo my-buffer)))
      (progn
        (message "`help-echo' property: %s " my-property)
        (browse-url-default-browser my-property))
    ;; else
    (message "No `help-echo' property at mouse click event location.")))

(map!
 :desc "mouse event "               "<mouse-3>"      #'eldoc-stuff-open-url-help-echo-property)


emacs-list-18@pgxml.net wrote:

> Hi all,
> 
>  i have a problem with help buffers generated by eldoc out of an
>  rustic/eglot buffer. 
> 
>  In the help buffer there is some text that is higlighted, and the
>  tooltip shows a url to be followed for further information for that
>  symbol, keyword, package... whatever.
> 
>  The thing is: when is try to open this link (mouse click), i get the
>  message "Nothing to follow at point"
> 
>  The text properties of the hilighted symbol are (example):
> 
>  (keymap
>     (keymap
>      (mouse-2 . markdown-follow-thing-at-point)
>      (follow-link . mouse-face))
>     mouse-face markdown-highlight-face font-lock-multiline t help-echo
>  "https://doc.rust-lang.org/stable/std/std/fmt/index.html" face
>  markdown-link-face)



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: eldoc/eglot help: Nothing to follow at point
  2025-01-29 12:34 eldoc/eglot help: Nothing to follow at point emacs-list-18
  2025-02-04  7:49 ` Chris
@ 2025-02-05 11:17 ` Joel Reicher
  2025-02-05 14:11   ` Christoph Kliemt
  1 sibling, 1 reply; 6+ messages in thread
From: Joel Reicher @ 2025-02-05 11:17 UTC (permalink / raw)
  To: emacs-list-18; +Cc: help-gnu-emacs

emacs-list-18@pgxml.net writes:

[...]

>  So now: who is the culprit?
>
>  eglot seems to tell eldoc to produce a buffer in help-mode, but 
>  eldoc uses a markdown function as binding to a mouse event.

I see the same. I think eglot is using gfm-view-mode to format the 
text from the LSP, but then putting it in a buffer called 
"*eldoc*" which is not actually that markdown mode at all. If I 
copy the LSP response into a buffer which is actually that mode 
the link following works as expected.

Have you reported this to the eglot devs?

Regards,

        - Joel



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: eldoc/eglot help: Nothing to follow at point
  2025-02-05 11:17 ` Joel Reicher
@ 2025-02-05 14:11   ` Christoph Kliemt
  2025-02-05 22:50     ` Joel Reicher
  0 siblings, 1 reply; 6+ messages in thread
From: Christoph Kliemt @ 2025-02-05 14:11 UTC (permalink / raw)
  To: Joel Reicher; +Cc: help-gnu-emacs@gnu.org

On Wed, 05 Feb 2025 22:17:58 +1100
Joel Reicher <joel.reicher@gmail.com> wrote:

> emacs-list-18@pgxml.net writes:
> 
> [...]
> 
> >  So now: who is the culprit?
> >
> >  eglot seems to tell eldoc to produce a buffer in help-mode, but 
> >  eldoc uses a markdown function as binding to a mouse event.
> 
> I see the same. I think eglot is using gfm-view-mode to format the 
> text from the LSP, but then putting it in a buffer called 
> "*eldoc*" which is not actually that markdown mode at all.

Hmmm... i don't see a "*eldoc*" buffer at all, here i have a
*elgot-help buffer in help mode.

> If I copy the LSP response into a buffer which is actually that mode
> the link following works as expected. 

Could you please describe exactly how you are doing this (copy lsp
response into a markdown buffer)?

> Have you reported this to the eglot devs?

No. Till now i did not fully understand the root cause of the problem.
The help-echo property has a keymap with
"markdown-follow-thing-at-point" bound to mouse-2; the markdown
function *is* called, but it does not recognize the help-echo data as
url which is should.

emacs 29.4 with a recent doom.

Chris




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: eldoc/eglot help: Nothing to follow at point
  2025-02-05 14:11   ` Christoph Kliemt
@ 2025-02-05 22:50     ` Joel Reicher
  2025-02-06 10:12       ` Chris
  0 siblings, 1 reply; 6+ messages in thread
From: Joel Reicher @ 2025-02-05 22:50 UTC (permalink / raw)
  To: Christoph Kliemt; +Cc: help-gnu-emacs@gnu.org

Christoph Kliemt <christoph.kliemt@pgxml.net> writes:

> On Wed, 05 Feb 2025 22:17:58 +1100 Joel Reicher 
> <joel.reicher@gmail.com> wrote:
>
>> emacs-list-18@pgxml.net writes:
>>
>> [...]
>>
>>>  So now: who is the culprit?
>>>
>>>  eglot seems to tell eldoc to produce a buffer in help-mode, 
>>>  but  eldoc uses a markdown function as binding to a mouse 
>>>  event.
>>
>> I see the same. I think eglot is using gfm-view-mode to format 
>> the  text from the LSP, but then putting it in a buffer called 
>> "*eldoc*" which is not actually that markdown mode at all.
>
> Hmmm... i don't see a "*eldoc*" buffer at all, here i have a 
> *elgot-help buffer in help mode.

Are you opening the buffer with `C-h .'? I'm pretty sure what I've 
described is the default behaviour of that.

>> If I copy the LSP response into a buffer which is actually that 
>> mode the link following works as expected.
>
> Could you please describe exactly how you are doing this (copy 
> lsp response into a markdown buffer)?

M-x eglot-events-buffer and copy the string from the json.

>> Have you reported this to the eglot devs?
>
> No. Till now i did not fully understand the root cause of the 
> problem.  The help-echo property has a keymap with 
> "markdown-follow-thing-at-point" bound to mouse-2; the markdown 
> function *is* called, but it does not recognize the help-echo 
> data as url which is should.

What's the mode of the eglot-help buffer, and what version of 
eglot? Do you have any other relevant packages or customisations?

Regards,

        - Joel



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: eldoc/eglot help: Nothing to follow at point
  2025-02-05 22:50     ` Joel Reicher
@ 2025-02-06 10:12       ` Chris
  0 siblings, 0 replies; 6+ messages in thread
From: Chris @ 2025-02-06 10:12 UTC (permalink / raw)
  To: Emacs list

On Thu, 06 Feb 2025 09:50:56 +1100
Joel Reicher <joel.reicher@gmail.com> wrote:

[...]

> > Could you please describe exactly how you are doing this (copy 
> > lsp response into a markdown buffer)?  
> 
> M-x eglot-events-buffer and copy the string from the json.

doom set the eglot-events buffer size to zero, i needed to set
(setq eglot-events-buffer-config '(:size 2000000 :format full)) 

> >> Have you reported this to the eglot devs?  
> >
> > No. Till now i did not fully understand the root cause of the 
> > problem.  The help-echo property has a keymap with 
> > "markdown-follow-thing-at-point" bound to mouse-2; the markdown 
> > function *is* called, but it does not recognize the help-echo 
> > data as url which is should.  
> 
> What's the mode of the eglot-help buffer,

help-mode inheriting special-mode

> and what version of eglot? 

1.17 ... maybe i should test with recent 1.18

> Do you have any other relevant packages or customisations?

This is a doom emacs.
customisations: 
(setq eldoc-documentation-strategy
'eldoc-documentation-compose-eagerly))
(setq eglot-events-buffer-config '(:size 2000000 :format full))

The strange thing is, when i edebug this, it boils down to (backtrace):

>markdown-follow-thing-at-point(nil)
>funcall-interactively(markdown-follow-thing-at-point nil)
>command-execute(markdown-follow-thing-at-point)

I dont understand why the argument to markdown-follow-thing-at-point it
nil...? 

regards Chris




^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2025-02-06 10:12 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-29 12:34 eldoc/eglot help: Nothing to follow at point emacs-list-18
2025-02-04  7:49 ` Chris
2025-02-05 11:17 ` Joel Reicher
2025-02-05 14:11   ` Christoph Kliemt
2025-02-05 22:50     ` Joel Reicher
2025-02-06 10:12       ` Chris

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.