3 ms·

The biggest problem with LSP is that it's a lowest common denominator solution. If I try to edit OCaml using an LSP solution, I don't get features like "query t

The biggest problem with LSP is that it's a lowest common denominator solution. If I try to edit OCaml using an LSP solution, I don't get features like "query type of symbol", presumably because JavaScript doesn't need it.

pxc 3y ago
Wait, does that feature mean what is sounds like? That sounds too basic to be fundamentally beyond LSP.
- _flux 3y ago
  Yeah, it sounds like it should support it. Traditionally though OCaml editor integrations have also supported not only asking just the type of a symbol, but of an expression. I wonder if LSP can do that, because that function needs some interactive scoping of the query, not just a single point, or I suppose it can work if hovering over parenthesis but if precedency needs to be accounted for, it would be difficult to understand what the user wants to see. I've _really_ enjoyed the expression type queries in the past, but I haven't coded OCaml for a while :/.
  - skitter 3y ago
    That's doable in LSP - the server knows about the selection, not just the cursor position. E.g. if I use rust-analyzer (in Helix, so there aren't any protocol extension in play), select an expression and request hover info, rust-analyzer shows the expression's type.
teaearlgraycold 3y ago
[flagged]
runeks 3y ago
Hovering over the name of a variable in Haskell shows the type. It sounds like your OCaml LSP server just hasn't implemented this yet.
kmarc 3y ago
It's not a problem, in contrary it is good that implementors are pointed to possible code intelligence features that they current IDE's don't provide either. I read some factual inaccuracies here. LSP (the protocol)'s main driving force was for a long time TypeScript rather than JS. FYI TypesSript has a stronger type system than Java at this point, and it's LSP server is the most comprehensive and supported way to write TS with. Another example of an LSP success story is Rust's rust-analyzer. Not to mention that C++'s clangd also became an LSP server many years ago. All these are strongly typed and bring extra semantics (templates, lifetimes) way beyond other languages. "query type of symbol" functionality is provided as an example by the textdocument/hover call [1] But even if this wasn't implemented, the protocol lets any implementor extend the interface with additional / non-standard methods (and clangd did exactly that[2]) It might be that the not-widely-popular ocaml's LSP support is not there yet. Probably it's an open source project, so you can help with the implementation, or at least vote for missing features to be implemented. [1]: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_hover https://microsoft.github.io/language-server-protocol/specifi... [2]: https://clangd.llvm.org/extensions https://clangd.llvm.org/extensions
- matklad 3y ago
  Agree this is not a problem. rust-analyzer also includes a boatload of custom extensions. Here's how "query type of the selected expression" works, for example: https://github.com/rust-lang/rust-analyzer/blob/master/docs/dev/lsp-extensions.md#hover-range https://github.com/rust-lang/rust-analyzer/blob/master/docs/...
tjoff 3y ago
You don't get those features because the OCaml LSP doesn't implement it. Works fine in other LSPs.
kps 3y ago
LSP is still (last I checked) missing one nice feature that cscope had 30 years ago: distinguishing between read and write references to a variable. Unfortunately it (as mlcscope) didn't keep up with C++ and ultimately vanished.
- rw-access 3y ago
  That's part of the protocol with a Document highlight request. Basically if you click on a symbol in the client, it'll send the server side request where it can find all references and mark which ones are read and which are write. The client will then highlight those references with one color for read, one for write, and one for other textual occurrences. https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_documentHighlight https://microsoft.github.io/language-server-protocol/specifi...

pxc 3y ago

Wait, does that feature mean what is sounds like? That sounds too basic to be fundamentally beyond LSP.

_flux 3y ago
Yeah, it sounds like it should support it. Traditionally though OCaml editor integrations have also supported not only asking just the type of a symbol, but of an expression. I wonder if LSP can do that, because that function needs some interactive scoping of the query, not just a single point, or I suppose it can work if hovering over parenthesis but if precedency needs to be accounted for, it would be difficult to understand what the user wants to see. I've _really_ enjoyed the expression type queries in the past, but I haven't coded OCaml for a while :/.
- skitter 3y ago
  That's doable in LSP - the server knows about the selection, not just the cursor position. E.g. if I use rust-analyzer (in Helix, so there aren't any protocol extension in play), select an expression and request hover info, rust-analyzer shows the expression's type.

teaearlgraycold 3y ago

[flagged]

runeks 3y ago

Hovering over the name of a variable in Haskell shows the type. It sounds like your OCaml LSP server just hasn't implemented this yet.

kmarc 3y ago

It's not a problem, in contrary it is good that implementors are pointed to possible code intelligence features that they current IDE's don't provide either. I read some factual inaccuracies here. LSP (the protocol)'s main driving force was for a long time TypeScript rather than JS. FYI TypesSript has a stronger type system than Java at this point, and it's LSP server is the most comprehensive and supported way to write TS with. Another example of an LSP success story is Rust's rust-analyzer. Not to mention that C++'s clangd also became an LSP server many years ago. All these are strongly typed and bring extra semantics (templates, lifetimes) way beyond other languages. "query type of symbol" functionality is provided as an example by the textdocument/hover call [1] But even if this wasn't implemented, the protocol lets any implementor extend the interface with additional / non-standard methods (and clangd did exactly that[2]) It might be that the not-widely-popular ocaml's LSP support is not there yet. Probably it's an open source project, so you can help with the implementation, or at least vote for missing features to be implemented. [1]: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_hover https://microsoft.github.io/language-server-protocol/specifi... [2]: https://clangd.llvm.org/extensions https://clangd.llvm.org/extensions

matklad 3y ago
Agree this is not a problem. rust-analyzer also includes a boatload of custom extensions. Here's how "query type of the selected expression" works, for example: https://github.com/rust-lang/rust-analyzer/blob/master/docs/dev/lsp-extensions.md#hover-range https://github.com/rust-lang/rust-analyzer/blob/master/docs/...

tjoff 3y ago

You don't get those features because the OCaml LSP doesn't implement it. Works fine in other LSPs.

kps 3y ago

LSP is still (last I checked) missing one nice feature that cscope had 30 years ago: distinguishing between read and write references to a variable. Unfortunately it (as mlcscope) didn't keep up with C++ and ultimately vanished.

rw-access 3y ago
That's part of the protocol with a Document highlight request. Basically if you click on a symbol in the client, it'll send the server side request where it can find all references and mark which ones are read and which are write. The client will then highlight those references with one color for read, one for write, and one for other textual occurrences. https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_documentHighlight https://microsoft.github.io/language-server-protocol/specifi...