lsp-clients-extract-signature-on-hover insufficient in a lot of modes

[slotThe]

Thank you for the bug report

• I am using the latest version of lsp-mode related packages.
• I checked FAQ and Troubleshooting sections
• You may also try reproduce the issue using clean environment using the following command: M-x lsp-start-plain

Bug description

This is mostly the same issue as emacs-lsp/lsp-haskell#151, with #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:

(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:

iAmTooLong :: String -> String -> String -> String -> String -> String -> String -> String
iAmTooLong = undefined

Hovering over this will generate the following response

```haskell
iAmTooLong :: String
-> String
-> String
-> String
-> String
-> String
-> String
-> String
```

*Defined at /home/slot/repos/haskell/sandbox/src/Main.hs:4:1*

By default, then, only iAmTooLong :: String is shown in the minibuffer.

Likewise, from #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 #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

OS

Linux

Error callstack

No response

Anything else?

No response