Add simple syntax highlighting

[lhecker]

There are two levels of syntax highlighting this project should implement:

• This issue: Primitive highlighting via ICU's regex support, roughly replicating how TextMate works
• Proper highlighting via tree-sitter or similar

The reason we should want the former is that it would allow us to add syntax highlighting to the core editor without blowing up its binary size. It would good a great trade-off.

The latter will be possible once we've done #17.

[3052]

The reason we should want the former is that it would allow us to add syntax highlighting to the core editor without blowing up its binary size. It would good a great trade-off.

100% - syntax highlighting with tree sitter is cool but it absolutely destroys the distribution size, and when I have raised the issue with other repos (calling you out https://github.com/helix-editor/helix) the response is basically "too bad deal with it". currently the Helix grammars folder is 166 MB extracted - please lets not repeat that

[jrappen]

Since this is a Rust project, you could use:

https://github.com/trishume/syntect

which uses:

https://github.com/sublimehq/Packages/tree/st3

i.e. the syntax definitions for Sublime Text 3. Syntect cannot use the master branch there for current versions of Sublime Text (and Sublime Merge) due to trishume/syntect#271 and trishume/syntect#323.

[lhecker]

syntect unfortunately roughly doubles the binary size as well. I think we should take up the challenge to build our own basic syntax highlighter. In my opinion it doesn't have to be good, nor correct, because tree-sitter, and LSPs in particular, are unarguably superior alternatives (apart from their binary size). So, I feel like using syntect would not provide an ideal trade-off for this project.

[matsmcp]

my 2c

Editplus uses a system with external syntax files (https://www.editplus.com/files.html). I do not know if that would be a good approach but it might make it possible to keep the core small and still allow support for almost any syntax

[Bit0r]

tree-sitter is perfectly capable, and micro also has syntax highlighting. If syntax highlighting and automatic sudo are added, then edit will replace micro as the best terminal editor.

[lhecker]

tree-sitter or something similar can be done as part of #17.

[Bit0r]

tree-sitter or something similar can be done as part of #17.

The primary users of terminal editors are programmers, not regular users.Built-in syntax highlighting is a basic feature, and implementing it via plugins is truly unnecessary. Products should prioritize users and the market, rather than pure technology.

The micro binary is close to 5MB in size, but nobody says it's very large because its users, namely programmers, can completely accept a size of 5MB.

[lhecker]

Noted. But we won't do that, as stated many times in this repository.

[Bit0r]

Noted. But we won't do that, as stated many times in this repository.

Is the requirement to control binary file size coming from your leadership, or is it your own decision?

[lhecker]

We can continue this in the Discussions section of this project. I'll collapse these last 4 comments as off-topic, because I've responded to your initial comment.

Edit: I've removed most of the comment, because it wasn't really nice. I'm sorry about that. This is better fit for the Discussions section though, anyway.

[abulka]

I've taken the liberty of spinning off a discussion https://github.com/microsoft/edit/discussions/425

[gominexus]

Could I perhaps suggest a minimalist approach might be taken here? I find one of the most useful visual cues provided by syntax highlighting is differentiation of comments from code. I suspect a lookup table of comment indicators across an array of languages would only be a few kB, so maybe this would be achievable with limited impact on the binary?

[Consolatis]

I do use nano as my main code editor for C and some Python. It uses simple regex based highlighting and that works surprisingly well. So a pure regex based approach might be fine and is in line with the goals of this editor. For some examples see /usr/share/nano/c.nanorc or /usr/share/nano/python.nanorc.

[NysanderBTF]

I think maybe syntax highlighting/lsp could be achived by using external tools that can be configured in config file? With this approach lsp won't take space (because not included) but it would be optional

[dmknght]

Found a fork that added syntax highlighting. Maybe community can maintain a different version with more features https://github.com/gurneesh9/scriptly