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.
Created attachment 144644 [details] Screenshot of Mode option
File mode change stops the LSP itself. If you want to run a different LSP on say C++ files, use the config.
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.
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.