Update helix instructions

[kabouzeid]

rev = main doesn't work as I expected. It will never move to a new commit. For now we just have to update rev to newer commit hashes every now and then :/

Also clarified the instructions for linking highlights.scm

[bezhermoso]

Looked at Helix documentation and it notes that how Helix applies highlight groups differs from Neovim in that it only uses the first query that match whereas Neovim will use the last one.

Curious, how do things look like in Helix? Since Helix also have a wider selection of groups I think it might be worth designating a separate one for it.

[kabouzeid]

this is how your test config is highlighted

[bezhermoso]

Thanks for sharing that screenshot. I'll play around with Helix and see what we can improve. At the very least, it can probably leverage more groups.

[kabouzeid]

Just a heads up, many themes will assign similar colors to ghostty's current highlight groups, that's why I picked the bogster theme here. Also, you can use the :tree-sitter-scopes and :tree-sitter-highlight-name commands to debug the symbol under the cursor in helix. lmk if you have questions :)

[gerblesh]

The boolean and number literals are not properly highlighted. Additionally, the precedence for helix is reversed in comparison to neovim. When upstreaming to helix, we'll likely need to modify the highlight queries to fix highlighting, and also change the order of the queries to fix precedence

[bezhermoso]

Ideally we can define the queries to be more targeted, designed to match once. I'm somewhat doubtful it's possible to share the same highlights.scm for both Neovim and Helix and satisfy both e.g. (property) @variable ... (config-file-directive (property)) @keyword.import) works for Neovim but I assume doesn't for Helix, but I don't want to enumerate all (*-directive (property))s either.

Given that Helix offers a wider selection of possible highlight groups, I'm more inclined to have separate highlights.scm files instead. Also given that Helix doesn't try to auto-discover queries based on plugin paths and require instructing the user to symlink a file anyway, this doesn't seem to be any worse for Helix (correct me if I'm wrong here, just basing this on the documentation, I don't use it)

[kabouzeid]

Helix bundles the highlights.scm files for each language it supports. We should make a PR over there once this repo is somewhat stable.

[bezhermoso]

@kabouzeid Does Helix support semver for the revision field?

[kabouzeid]

not sure. the default config they ship in their releases always specifies an exact commit. https://github.com/helix-editor/helix/blob/e440e54e7910673d5c5de4773da9796a6dbe2c87/languages.toml#L299

[kabouzeid]

Just tested it, doesn't work. Somehow this line is interpreting the refspec as a file path when given a tag.

https://github.com/helix-editor/helix/blob/e440e54e7910673d5c5de4773da9796a6dbe2c87/helix-loader/src/grammar.rs#L289

Notice how 1.1 fetches but can't checkout, and 1.2 (correctly) won't even fetch.

➜ hx --grammar fetch ghostty
Fetching 1 grammars
Failure 1/1: ghostty Git command failed.
Stdout:
Stderr: error: pathspec 'refs/tags/1.1' did not match any file(s) known to git

Error: 1 grammars failed to fetch

➜ hx --grammar fetch ghostty
Fetching 1 grammars
Failure 1/1: ghostty Git command failed.
Stdout:
Stderr: fatal: couldn't find remote ref refs/tags/1.2

Error: 1 grammars failed to fetch