Kate With Tree-Sitter

Brainstorm
1

Will Kate be getting tree-sitter support? This is the main question, while I veer off in other thoughts to come…

Something I had just noticed when editing a shell script was the Output tab was flashing (which is good), so I took a look and saw mention of the existence of a Bash LSP.

That got me really intrigued since I’m aware of LSPs ever since using C# in vscode.

I looked at LSP packages offered for Arch, which were quite a bit, and that got me to thinking of how I would like to have a global location for extensions, and I saw there’s a parameter for that.

So if I were to install the bash LSP package, maybe I wouldn’t need to even have an extension installed for vscode. That the package would work with kate AND vscode.

(odd aside, I just had a notification that this message was being drafted in another window and I need to refresh. I had no other window open for this discuss forum… Thank goodness this draft was saved.)

Then to add to that, I saw tree-sitter mentioned somewhere while I was looking at info about bash LSP…

My first encounter with tree-sitter stems from building gettext I think, which “recently”(? a year?) had included that as a dependency. I knew nothing of its purpose, and just went along with it.

Now my awareness is that it’s a sort of generic LSP? If so, that sounds like a great idea, like having a common base library to build off of.

So not only would we be served well by having a singular location for global LSPs, we would even have a singular common LSP base for offshoots like bash and c#.

Having shared commons be set by standards is a good thing (XDG?). Like having binaries in a single directory (eg. /usr/bin (for system), /usr/local/bin (for user system builds), ~/.share/bin (? for user-only build)), vs windows basically putting the entire package in a singular location, which is nice from an (un/)installation perspective (though you may still have at least user/registry-related stragglers remain), but I figure unfriendly from a PATH-related perspective. Minimize unnecessary duplication.

Having installed the bash tree-sitter, I see that it’s just a library…

Again, not knowing squat about tree-sitter, my expectation/hope for minimization is that a program like Kate would look at the doc being worked on, call a central TS function to see if a related/relevant TS exists, then call a common/generic TS function to interface with that related TS.

This, as opposed to having separate LSP binaries you may have to run the text on and process the output, all with having non-standard implementations. Dunno, just some brainstorming…

2

I had just noticed the LSP settings in Kate, and saw where it gets it’s list of servers from (Default Server Settings).

It’s quite the list and I was sort of surprised and pleased to see C# was included.

I do find it a little odd that it points to omnisharp ( GitHub - OmniSharp/omnisharp-roslyn: OmniSharp server (HTTP, STDIO) based on Roslyn workspaces ).

Don’t get me wrong, I’ve been a stalwart user of it, but it sounds like (even though the github issue won’t go so far as to say it), it’s going by the wayside (net6 still being used), with the direct roslyn being the go-to now (shame it’s not on open-vsx).

I was in the middle of aiming to custom build it myself before I was sidetracked.

Still, if tree-sitter is what I think it is, I’d rather see that get embraced first.

I was mistaken and do see tree-sitter DOES provide a CLI as a separate package (tree-sitter-cli). Odd that it doesn’t have it’s main tree-sitter package as a dependency.

3

I might be mistaken, but TreeSitter is less of an Global LSP and more of a Syntax Highlighter with some basic abilities that are also present in LSPs. KTextEditor (Kate, KWrite and KDevelop) uses KDE’s KSyntaxHighlighter framework for this instead. It’s good enough that even the official Qt IDE, QtCreator is using it.

Both TreeSitter and KSyntaxHighlighter provides some of the functionalities of LSPs, but they aren’t that accurate - even when it comes to Syntax Hightlighting itself. Using a LSP is always the better option.

Even Code Editors like NeoVIM that use TreeSitter for syntax highlighting still supprts installing LSPs. Infact, most popular NeoVIM configs uses LSPs when available.

4

Ugh, it’s sounding like you’re right.

A little google AI gave a brief synopsis of the differences, and a real limiter to tree-sitter (in my view at least) was the mention of it only working on a single page, so things like include/source(.) references aren’t followed-through, which I’ve found to be very key to what I do.

It seems pretty young (but so is my general awareness of LSPs), so I don’t know if it can/will grow into that role.

I don’t know what’s involved for interfacing with LSPs, but I can only imagine how ugly it must be having to deal with all separate LSPs marching to the beat of their own drum, instead of having a common/standard interface.

Thanks for that insight.

5

I doubt TreeSitter will become an alternative to LSPs, since it isn’t the goal of the project. Especially since methods of parsing syntax and semantics of a language tends to differ wildly from one to another - It’s just easier and better to write separate LSPs.

And LSPs does have a standered interface called LSP - Language Server Protocol. What we were reffering to as LSPs are actually just Language Servers while Language Server Protocol is their common standardized interface. So an editor doesn’t have to support each LSP separately - They just support the Protocol into which all LSPs can plug into.

You can use LSPs for languages Kate/KDevelop doesn’t support by default just by adding an entry in the JSON object in custom servers settings tab.

1 Like
6

TreeSitter builds a syntax tree of languages, which is mostly used for syntax highlighting in my experience.

Now having TreeSitter as the Kate syntax highlighting engine would be really cool. It should be more performant than what we have now.

7

Having it additionally would be nice, but it lacks support for a lot of languages we support, therefore it can be no replacement.

About the speed: no idea :slight_smile: nor about the memory usage.