misc

[git-bruh]

Hey, I've been maintaining a fork of vis-lspc to adapt it to my needs, just dropping this PR here so you can cherry pick any commits you might find useful. Most commits are atomic, some changes:

• Fetch the line's content from the file (either by re-using the existing vis buffer or opening it via the general lua APIs)
• Convert paths to relative paths so more content is visible when being piped to a program like fzy
• Hover messages are requested in markdown
• Different styling for each type of diagnostic message
• vis:pipe refactors to use vis:pipe_buffer, as I noticed the printf command construction breaking in large codebases

If you'd be interested in having some of this upstream I can create individual PRs

Thanks a lot for creating this project!

[fischerling]

Thank very much for your contribution!
I will look at your changes when I have time and reach out to you if necessary.

[fischerling]

Applyied so far: (sorry for making this harder to rebase)

• 1c3cbec as fe4249d
• 126b882 as 8303e07
• 4d88cfc as ac7bdc1
• ee3c172 as 435559d
• 840d273 as a2dc6b9
• lspc_show_message:
  • f2ab5c9 as 85ace3c
  • 6902efd as efaf185

TODO

• relative paths
• show messages in new windows using syntax highlghting
• show line content
• detect and propagate project roots

[fischerling]

This does not seem correct to me. What is the reason for this?

List of language IDs

• JavaScript uses javascript not jsx
• TypeScript uses typescript not tsx

[git-bruh]

Yeah it's a workaround for jsx/tsx files which are a superset of javascript/typescript allowing for xml-like syntax for creating elements (used in react mostly). So rather than launching separate language servers for a ts and tsx file we just use one.

See also kakoune-lsp/kakoune-lsp#211

[fischerling]

My problem with this change is that. Someone configuring their setup may not know about the enforced mapping and tries to configure a language server for the correct syntax/languageID javascript, which will not be picked up due to our mapping.

Maybe we can come up with a more generic solution for this.

Our solution should support setups that want to map all JS/TS files to JSX/TSX, ones that allow to separate both and ones that only want to configure servers for JS/TSX.

[git-bruh]

Hm, not sure of a clean solution as vis's filetype plugin only exposes *.tsx files as typescript files

And as I said it's a superset and I don't think there's any other js/ts language server in active development that doesn't support jsx/tsx

[fischerling]

Thanks for your contribution and the insights!

Applied as a2dc6b9.

My initial concern is invalid since we use the mapping only to determine the languageId passed to the server not to select a language server configuration.

We can still think about a more generic/complex solution if someone encounters an issue with this mapping.

[fischerling]

What is the reason for the _show_message change?

I think it has worse UX than using vis:message.
The new split window has to be forcefully closed using :q! because it has unsaved changes.

[git-bruh]

What is the reason for the _show_message change?

I think it has worse UX than using vis:message. The new split window has to be forcefully closed using :q! because it has unsaved changes.

Yeah it's just a personal thing. I felt vis:message output was harder to follow as there was no highlighting and the previous output was clubbed together. :q! is indeed annoying, i use the ZQ binding instead

[fischerling]

@git-bruh let me know what you think about https://gitlab.com/muhq/vis-lspc/-/merge_requests/49.

I tried to make the way messages are presented configurable.
You should achieve your desired behavior by setting lspc.show_message = 'open' in your configuration.