Kakoune: Better syntax highlighting for rust code

[nikhilmitrax]

PROBLEM:

The syntax highlighting in kakoune for rust seems to be lacking some highlighters.

Attaching screenshot of Kakoune and Vim running the gruvbox theme showing rust code from alacritty.

There seems to be a lot more highlighting on the vim side, especially around module imports and function calls.

The syntax highlighting I'm using for vim : https://github.com/rust-lang/rust.vim/blob/master/syntax/rust.vim

I apologize for just creating this issue instead of going in myself to fix it, but I tried doing that and quickly realised I'd need some amount of help understanding highlighters in kakoune, which may not be worth the time of a contributor here.

EDIT :

I started a fork with at least one improvement that adds highlighting for the syntax methods.
https://github.com/nikhilmitrax/kakoune/commit/86be04ffc7f596bb8a687a9bcd49650f906bb382

[Screwtapello]

The Rust syntax highlighter is less detailed than the Vim one, but different people have different opinions about how much colour is helpful and how much is distracting. I'm sure @mawww would take PRs for any improvements you wanted to submit, but probably nobody is going to add extra things just for feature-parity with Vim.

If you'd like help understanding highlighters, feel free to ask questions on the forum or the IRC channel (both linked under "Community" at the top of the official homepage).

[andreyorst]

I've added custom highlighting in my kakrc. Now it looks like so:

[nikhilmitrax]

@Screwtapello
Thanks! Yes I think I have a better understanding of how syntax highlighters work.

With regards to 'more colors' or 'less colors', it's my personal feeling, but I feel that it should be part of the colorscheme and not the language parser. People who tend to prefer fewer colors could pick the one they like, (or create a colorscheme to their liking), while the language could support colorschemes that want to highlight more. My guess is since the average person would use one colorscheme and multiple languages with the editor, it's more convenient to have a person change one colorscheme instead of n languages to their liking.

There's of course, the performance penalty of running a lot of RegExp searches in the buffer, so I'm not sure what the correct answer is.

@andreyorst Thank you very much! I found your dotfiles and I'm using big chunks of it in my own.

[andreyorst]

With regards to 'more colors', it's my personal feeling, but I feel that it should be part of the colorscheme and not the language parser.

I find this a huge problem in modern editors like VS Code, or Atom. There are decent color schemes, but they contain "less elements", by which I mean that they intentionally color different things with same color. I wish to use it, but I can't because my eyes are lost. I can judge code structure by color alone without reading most of the code, so when there are too few colors I'm lost and more reading is needed. So I rely on colors, and for me such themes are pain in the eyes. So I actually prefer editors which allow me to define highlighting the way I want, which is why I started to use Vim in the first place by the way.

There's of course, the performance penalty of running a lot of RegExp searches in the buffer, so I'm not sure what the correct answer is.

Kakoune design model is "be fast enough to perform everything". I run it on my GPD Pocket and Nexus 5X and with all my plugins it runs fast enough for my needs.

I found your dotfiles and I'm using big chunks of it in my own.

Cool, glad that you find them helpful!

[nikhilmitrax]

With regards to 'more colors', it's my personal feeling, but I feel that it should be part of the colorscheme and not the language parser.

I find this a huge problem in modern editors like VS Code, or Atom. There are decent color schemes, but they contain "less elements", by which I mean that they intentionally color different things with same color. I wish to use it, but I can't because my eyes are lost. I can judge code structure by color alone without reading most of the code, so when there are too few colors I'm lost and more reading is needed. So I rely on colors, and for me such themes are pain in the eyes. So I actually prefer editors which allow me to define highlighting the way I want, which is why I started to use Vim in the first place by the way.

Agreed. I mistyped my statement a little in the previous comment, but I completely agree with you. The language parser _should_ (imo) generate highlight regions for everything it can, and it should be the resposibility of the colorscheme to pick what to highlight.

In that vein, would you want to make your changes from your dotfiles part of the upstream rust syntax?

[andreyorst]

The language parser should (imo) generate highlight regions for everything it can, and it should be the resposibility of the colorscheme to pick what to highlight.

My thoughts are quite the opposite, actually. I want parser to parse as little as it can, and to be easy to extend with some kind of rules or grammar.

In that vein, would you want to make your changes from your dotfiles part of the upstream rust syntax?

I'm not sure if my regexps are good enough. They are pretty complex and may not be optimal.

[andreyorst]

I guess this issue can be closed by #3049 and merged #3027

[pickfire]

I think this is fixed? I ported the new keywords from vim not long ago. Feel free to report anything that is missing.