I am often using Typst with small, single-file documents (checklists, itineraries, etc). For making some small changes I prefer to open the *.typ files in native text editor applications like Gedit or Gnome Text, rather than a full-blown IDE with integrated language servers. Unfortunately there is no syntax highlighting available for those two applications based on the GtkSourceView component yet.
I can try to make up some basic language definition using the according Tutorial, but would be interested in:
whether someone on this forum already has some experience in writing language definition files for GtkSourceView
whether there are syntax highlight definitions based on regex-patterns for other editors that could be used as a starting point (BTW: How does syntax highlighting of code blocks in this forum work?)
Thanks @SillyFreak! That Tinymist TextMate grammar file contains some good starting points for matching language elements like numbers, lengths, colors, and similar things.
Wasn’t able to follow the discussion for Typst icons in KDE, though, as it seems to require an account on Discord.
I asked in the Discord, the gist is: there have been some open source contributions but none of them GTK related. The only actual link posted on Discord was the one I quoted, so you didn’t miss anything. Regarding Tinymist I also quoted all the relevant links so you didn’t miss anything there either.
There is someone looking to build GTKSourceView Typst syntax highlighting for a new GTK based Typst Editor - they included some resources in the ticket as a starting point - not sure if its entirely helpful
Some months ago I looked into translation from TextMate grammar to GtkSourceView language definition files. I used typst.tmLanguage.json from Myriad-Dreamin as a basis, which is more complex. Finally I gave up when noticing that it includes some grammar constructs that are difficult/impossible to map to GtkSourceView language (patterns nested within captures).
The Typewriter project seems to use a much simpler typst.tmLanguage.json which (from a quick look) does not seem to have that problem. So maybe I will try again when I find some time to spare.