Syntax highlighting in file picker for unopened files

[heliostatic]

I assume that because the syntax highlighting happens via tree-sitter, files that have never been opened don't have syntax data/an ast to highlight in the file picker? In any case, it's sort of weird in practice--although I couldn't find any issues, open or closed, about it, so perhaps I have something configured wrong?

https://user-images.githubusercontent.com/70898/129821133-a6e70c23-860c-4667-a3a3-c0900fffd1c8.mp4

[kirawi]

The file picker preview is a new addition, and for now it doesn't do highlighting on other files for performance reasons, I believe.

[heliostatic]

The file picker preview is a new addition, and for now it doesn't do highlighting on other files for performance reasons, I believe.

Thanks, read the linked PR, makes sense. I'll keep an eye on any PRs in that code area.

[pickfire]

Since we don't have an issue for this I think we can keep this open.

The performance issue is due to syntax highlighting is currently synchronous which will be slow when we are using the file picker. The implementation that we think would be better is first show the version without syntax highlighting and at the same time getting syntax highlighting for the file asynchronously. I think it requires some changes to make the picker run async stuff which is non-trivial so the original PR removed the syntax highlighting feature.

[heliostatic]

Gitui has a nice approach to async syntax highlighting: https://github.com/extrawurst/gitui/blob/master/src/ui/syntax_text.rs

[lykahb]

Would tree-sitter performance be a problem if helix passes it a constant-size chunk of file, comparable to the size of a preview?

A few experiments with the tree-sitter playground show that it returns a tree rich enough to show highlighting. It seems to work better on the chunks from the beginning of the file - the use case for file picker. But it is usually good enough when parsing a chunk from the middle - the use case for global search.

A few differences from the regular output of tree-sitter:

• some sub-trees may be under the ERROR nodes
• for expressions where either opening or closing element is missing, it may be classified in a wrong way (e.g, array as sequence_expression or function_declaration as expression_statement with function).

So far I haven't seen the tree output that may make highlighting misleading - usually the wrong named node would be similar in meaning, or a chunk of text would have no named node (and so no highlighting) at all.

[the-mikedavis]

Passing part of the file would reduce the time taken to parse the syntax tree but query analysis can also take quite some time for languages like Elixir or Swift (it's a sub-secord but noticeable hang).

I'm very skeptical that passing only a constant-size chunk works acceptably well across languages though. I would find incorrect highlights more distracting than no highlights

[archseer]

https://github.com/helix-editor/helix/commit/a85e3862988933953d1c0e7435969604d3722959

[pickfire]

I noticed it just highlight the previews once then forgets, should be cache the result so that we don't have to highlight again?

[gabydd]

should this be closed(trying to clean out some old issues)?