You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is an open issue in lsp protocol to allow to send ranges in hover requests. It's already implemented in some lsp servers, e.g rust-analyzer and metals. However because it's not standardized the implementation is different - metals adds an additional optional field while rust-analyzer accepts range in the position field. For metals it can be implemented in a hacky way like:
(defunlsp--text-document-position-params (&optionalidentifierpositionrange)
"Make TextDocumentPositionParams for the current point in the current document.If IDENTIFIER, POSITION and RANGE are non-nil, they will be used as the documentidentifier and the position respectively."
(list:textDocument (or identifier (lsp--text-document-identifier))
:position (or position (lsp--cur-position))
:range (or range (when (use-region-p) (lsp--region-to-range (region-beginning) (region-end))))))
This is useful to infer type of the selection.
The text was updated successfully, but these errors were encountered:
Metals also sets capabilities.experimental.rangeHoverProvider: true in the initialize response which can be used (while rust one is capabilities.experimental.hoverRange).
There is an open issue in lsp protocol to allow to send ranges in hover requests. It's already implemented in some lsp servers, e.g rust-analyzer and metals. However because it's not standardized the implementation is different - metals adds an additional optional field while rust-analyzer accepts range in the
position
field. For metals it can be implemented in a hacky way like:This is useful to infer type of the selection.
The text was updated successfully, but these errors were encountered: