The tl;dr is that the default implementation for lsp-clients-extract-signature-on-hover is quite insufficient in a lot of contexts:
(cl-defmethod lsp-clients-extract-signature-on-hover (contents _server-id)
"Extract a representative line from CONTENTS, to show in the echo area."
(car (s-lines (s-trim (lsp--render-element contents)))))
It just indiscriminately takes the first line of the first markdown block. However, language servers are not required (and, indeed, don't) to serve something actually useful on only the first line. Take the following Haskell expression, for example:
By default, then, only iAmTooLong :: String is shown in the minibuffer.
Likewise, from https://github.com/emacs-lsp/lsp-mode/pull/1740 we know that rust-analyzes sends vastly more informative information (i.e., the actual type signature of the thing at point) as only the second GFM block, but perhaps that is a more specialised issue.
I propose that lsp-clients-extract-signature-on-hover should at least try to grab the first GFM block as a whole, instead of just the first line. The following code (heavily based on https://github.com/emacs-lsp/lsp-mode/pull/1740) is something that I've been using for a while.
It goes into this direction, but does a little more: it grabs the first GFM block /that mentions the thing at point/, which seems like a sensible thing to do. However, this is just a suggestions, and I'm open for other opinions.
(defun lsp-get-type-signature (lang str)
"Get LANGs type signature in STR.
Original implementation from https://github.com/emacs-lsp/lsp-mode/pull/1740."
(let* ((start (concat "```" lang))
(groups (--filter (s-equals? start (car it))
(-partition-by #'s-blank? (s-lines (s-trim str)))))
(name-at-point (symbol-name (symbol-at-point)))
(type-sig-group (car
(--filter (s-contains? name-at-point (cadr it))
groups))))
(->> (or type-sig-group (car groups))
(-drop 1) ; ``` LANG
(-drop-last 1) ; ```
(-map #'s-trim)
(--filter (not (s-prefix? comment-start it))) ; e.g. rust-analyzer puts size hints here
(s-join " "))))
;; Example usage, the first argument to `lsp-get-type-signature'
;; should probably be made more robust to account for varying mode names.
(cl-defmethod lsp-clients-extract-signature-on-hover (contents _server-id)
"Extract a representative line from CONTENTS, to show in the echo area."
(lsp--render-string
(lsp-get-type-signature
(car (s-split "-" (symbol-name major-mode)))
(plist-get contents :value))
major-mode))
Steps to reproduce
see above
Expected behavior
see above
Which Language Server did you use?
Tested with haskell-language-server and rust-analyzer
Thank you for the bug report
lsp-mode
related packages.M-x lsp-start-plain
Bug description
This is mostly the same issue as https://github.com/emacs-lsp/lsp-haskell/issues/151, with https://github.com/emacs-lsp/lsp-mode/pull/1740 also being closely related (especially code-wise).
The tl;dr is that the default implementation for
lsp-clients-extract-signature-on-hover
is quite insufficient in a lot of contexts:It just indiscriminately takes the first line of the first markdown block. However, language servers are not required (and, indeed, don't) to serve something actually useful on only the first line. Take the following Haskell expression, for example:
Hovering over this will generate the following response
By default, then, only
iAmTooLong :: String
is shown in the minibuffer.Likewise, from https://github.com/emacs-lsp/lsp-mode/pull/1740 we know that rust-analyzes sends vastly more informative information (i.e., the actual type signature of the thing at point) as only the second GFM block, but perhaps that is a more specialised issue.
I propose that
lsp-clients-extract-signature-on-hover
should at least try to grab the first GFM block as a whole, instead of just the first line. The following code (heavily based on https://github.com/emacs-lsp/lsp-mode/pull/1740) is something that I've been using for a while. It goes into this direction, but does a little more: it grabs the first GFM block /that mentions the thing at point/, which seems like a sensible thing to do. However, this is just a suggestions, and I'm open for other opinions.Steps to reproduce
see above
Expected behavior
see above
Which Language Server did you use?
Tested with
haskell-language-server
andrust-analyzer
OS
Linux
Error callstack
No response
Anything else?
No response