I see it every time, normally with the 2nd opened file. I have not found a means of not reproducing, other than downgrading to kak-tree-sitter 1.0.1, and dealing with needing to occasionally rmhl window/cpp.

My suspicion is that whenever I need to manually :rmhl window/cpp on kts 1.0.1 (not often), kts 1.1.1 would work as intended. Whenever I don't need to :rmhl window/cpp on 1.0.1 (vast majority of the time), kts 1.1.1 would yield

error running hook WinSetOption(tree_sitter_lang=cpp)/tree-sitter: 2:18: 'remove-highlighter': no such id: 'cpp'

and there would be neither default nor kts highlighting of the window.

I have this suspicion because on kts 1.0.1, I normally only need to rmhl the first opened file. On kts 1.1.1, I see it remove the default highlighting after a short lag on the first file, which is normally the only file that works. Additionally, the error message is about a failure to remove the default cpp highlighter. It seems like removing the default highlighter isn't typically needed except for the first opened file, and that the error when trying to do so unsuccessfully prevents the kts highlighters from getting applied.

Additionally, when I start the server from the command line:

$ kak-tree-sitter -vvvv -s --with-highlighting --with-text-objects

I see nothing being printed for any of the cpp files that fail to display anything. I suspect the kak script errors out before passing any messages to the server.

If I open multiple files, either from one kakoune session, or from new kakoune clients connected to the same server, kts eventually stops applying to any newly opened files. It normally only takes 1-3 files beyond the first. Additionally, the default highlighting isn't applied either.

The first opened file always works as intended. It initially appears with both kts + default highlighting (or maybe default only?), but after a brief delay, the default highlighting is automatically removed and the file is highlighted by tree-sitter.

I get this in my *debug* buffer for each (cpp) file that shows up without any highlighting:

error running hook WinSetOption(tree_sitter_lang=cpp)/tree-sitter: 2:18: 'remove-highlighter': no such id: 'cpp'

Perhaps whatever code that is meant to strip the default highlighter is throwing an error, and then kts doesn't apply either?

As an aside, the documentation here is out of date: https://git.sr.ht/~hadronized/kak-tree-sitter/tree/HEAD/item/docs/man/commands.md

I'm on

$ kak-tree-sitter --version                                                                                                   (base) 
kak-tree-sitter 1.1.0-1bbd49b

which includes "Properly remove default highlighter." However, the highlighter still sometimes fails to be removed: https://i.imgur.com/LTC20T7.png I could fix it by manually running :rmhl window/cpp.

In this case, the one with the default highlighter still applied was the first kak client I connected to a cpp file. So far, further ones haven't had this issue.

This explains why updating to the latest Julia queries + tree-sitter-julia hardly highlights anything. They were from the reverse-query-precedence-ordering branch of helix.

I suspect those updated queries are now matching most code as variable, due to assuming the opposite precedence.

On Sat, Jun 15, 2024 at 10:32 AM ~hadronized outgoing@sr.ht wrote:

In terms of code in KTS, everything is finished (see this).

For the rest, we need to have the queries precedence updated. For short, tree-sitter-0.21 switched from first to last; the first capture group used to have higher precedence, like with a list of regex ("foo." has higher precedence over "o." if placed before in a list we iterate on). Starting from 0.21 (and up to 0.22, that we are going to use), it’s as if the list was iterated on in reverse, so ["foo.", "o."] would match "fooyeah" with the second pattern (yikes).

I’m not sure why they all say it looks more natural (not to me), but it turns out every ecosystem is moving to this new last first (Neovim were the first one; Zed; Helix; etc.).

See this Helix link for further information.

-- Dimitri

-- View on the web: https://todo.sr.ht/~hadronized/kak-tree-sitter-features/7#event-373615

I think kak-tree-sitter --request is enough to send request from the CLI. If you want to start in standalone, I usually just do:

My issue was connecting kakoune to a standalone server. Currently, I have a standalone server starting with my WM when I login.

Then, I have my kakoune sessions connect to it using the full -dks. This lets it connect to the already up and running server, which wasn't happening otherwise.

seems like I need a more complete init, when I decided to just try

eval %sh{ kak-tree-sitter -ks --init "$kak_session" --with-highlighting --with-text-objects }

it did connect to the server that was launched from my command line. I figure it is safer to add the full -dks.

How should I connect to a kak-tree-sitter server started from the command line/some other script?

I am trying

> kak-tree-sitter --version
kak-tree-sitter 0.6.0-dev-f1754dc

and this in my kakrc:

eval %sh{ kak-tree-sitter --init "$kak_session" }

with this command to start the server:

kak-tree-sitter -s -vvvv --with-highlighting --with-text-objects

The last messages are

2024-06-08T23:37:46.747Z DEBUG [kak_tree_sitter::server] creating response queue
2024-06-08T23:37:46.747Z INFO  [kak_tree_sitter::server] starting server
2024-06-08T23:37:46.747Z DEBUG [kak_tree_sitter::server] starting event loop

It doesn't indicate any messages from a kts client.

Have you tried

eval %sh{ kak-tree-sitter -dks --with-highlighting --with-text-objects --session $kak_session }

This works for me with the latest release, but not the latest master.

Given that his config has

eval %sh{ kak-tree-sitter -dks --init "$kak_session" --with-highlighting --with-text-objects -vvvvv }

it is likely that what is needed has changed. https://git.sr.ht/~hadronized/config/commit/1b5a0d4b70781223220cab27ee4c6d5d5ecb5277

E.g., the latest release does not have an --init option.

> kak-tree-sitter --version                                                                                                                                                                                                              (base) 
kak-tree-sitter 0.6.0-

This should still be the latest tag available on Cargo.

The master branch should have many fixes, but there’re still some issues, especially when opening a file from the CLI; e.g. kak .

I briefly tried installing master, but it didn't seem to work with kak <something> as you said. None of the usual :kak-tree-sitter methods were available; it didn't seem to load at all. This could also have been user error. I used cargo install --git https://git.sr.ht/~hadronized/kak-tree-sitter --rev acec95aa to install.

This is currently expected — read as: there are a couple of bugs. I have the fixes on the go. I should merge to master very soon and cut a release in the upcoming days.

Okay. FWIW, I've since noticed that this often works as intended on the latest release, but sometimes it instead shows the behavior I described here, often accompanied with errors in *debug* about failing to remove markdown on WinSetOption filetype=. It's working at the moment, so I can't double check the exact message, but it seemed like it was still aware it had to remove markdown on buffer changes, but markdown wasn't actually being applied.