Bug 447172

Summary:	LSP Client matching on Highlighting mode makes using LSPs for alien languages non-trivial
Product:	[Applications] kate	Reporter:	Jonathan Rubenstein <jrubcop>
Component:	general	Assignee:	KWrite Developers <kwrite-bugs-null>
Status:	CLOSED INTENTIONAL
Severity:	wishlist	CC:	jrubcop, waqar.17a
Priority:	NOR
Version:	21.12.0
Target Milestone:	---
Platform:	Neon
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	Screenshot of Mode option

Description Jonathan Rubenstein 2021-12-18 14:59:02 UTC

SUMMARY
***
NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols.
See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***


STEPS TO REPRODUCE
1. Enable semantic highlighting in LSP Client settings
2. Install clangd
3. Open kate/kate/kateapp.cpp
4. Change Highlighting mode to None

OBSERVED RESULT
LSP Client stops completely, no semantic highlighting is used, and of course Kate's syntax highlighting stops as well

EXPECTED RESULT
Kate's syntax highlighting stops, LSP Client continues working, clangd semantic highlighting is used

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: KDE neon 5.23 user edition
KDE Plasma Version: 5.23.4
KDE Frameworks Version: 5.89.0
Qt Version: 5.15.3

ADDITIONAL INFORMATION
This is intentional behavior, but I believe there should be more options to match for LSP Client than just the syntax highlighting mode.

The normal "Mode" is still "C", and I would like to be able to match against that mode, or even better, file extensions directly.

I feel this Highlighting mode requirement makes it hard to drop in an LSP for any language without some specific non/trivial Kate/KDE metadata setup for KSyntaxHightlight, which I feel defeats some of the utility of LSP as a plug and play language service for any arbitrary language.

Comment 1 Jonathan Rubenstein 2021-12-18 15:12:51 UTC

Created attachment 144644 [details]
Screenshot of Mode option

Comment 2 Waqar Ahmed 2021-12-18 15:13:22 UTC

File mode change stops the LSP itself.

If you want to run a different LSP on say C++ files, use the config.

Comment 3 Jonathan Rubenstein 2021-12-18 15:36:37 UTC

My initial comment was a bit of a mess, so here is one with further clarity:

Because Kate's LSP Plugin maps LSP servers to syntax highlighting mode only, new languages without KSyntaxHighlighting definitions require a lot of Kate specific metadata in order to use. Some niche languages may not be worth the effort to author and maintain the editor-specific metadata for. Kate's LSP support is crippled by this dependency on KSyntaxHighlighting definitions.

One of the LSP's significant benefits is plugging in a platform-independent server, which contains all of the metadata about how the language works, and can provide many editing services without any baked-in knowledge of the editor utilizing it. Minimizing the amount of Kate-only metadata required to get an LSP server running is important to its utility and convenience.

I think matching on file Mode (not Highlighting)—which has file extension matching—is a good option. It's easy to create new Modes in Settings -> Open/Save -> Modes & Filetypes, you don't even have to leave Kate. Matching on file extensions defined in the LSP configuration directly would be the easiest method, but Modes themselves are just fine.


Maybe this deserves a new bug because this one is already a mess. I used clang and C because it's an easy demonstration of the issue, namely the LSP server being intrinsically tied to Highlighting, instead of something better.

Comment 4 Waqar Ahmed 2021-12-18 16:35:56 UTC

1. You can't use for e.g "clangd" on some xyz language. A language server is made for a specific language(s)
2. A lot (probably a majority) of the LSPs don't support semantic tokens yet

I tried doing this with Dart i.e., using a different mode to make things work just. But it was really bad so I ended up adding Dart support to KSyntaxHighlighting instead.

So, this is just how we do things. If a new language server is out there whose programming language we don't support, then  support for it should be added in KSH so that things work out of the box rather than providing some niche solution that 99.999% of the people will never figure out or care about.