Let's write a treesitter major mode for Emacs
masteringemacs.org
Let's write a treesitter major mode for Emacs
1–10 of 86 posts
Re: Let's write a treesitter major mode for Emacs
#2I'm not trying to bash Emacs or treesitter or anyone. But I find it mildly amusing that after so many decades, parsing and syntax highlighting aren't a perfectly solved problem, considering programming languages are the most used tools for developers.
Re: Let's write a treesitter major mode for Emacs
#3I'm not trying to bash Emacs or treesitter or anyone. But I find it mildly amusing that after so many decades, parsing and syntax highlighting aren't a perfectly solved problem, considering programming languages are the most used tools for developers.
What would you consider a perfectly solved problem in this case? I.e. how is current development experience bad and how it could be better?
Re: Let's write a treesitter major mode for Emacs
#4I'm not trying to bash Emacs or treesitter or anyone. But I find it mildly amusing that after so many decades, parsing and syntax highlighting aren't a perfectly solved problem, considering programming languages are the most used tools for developers.
The problem is that a good editor-compatible tool for parsing and syntax highlighting is at cross-purposes with what you want from a compiler.
A good overview here: https://matklad.github.io/2022/04/25/why-lsp.html
Re: Let's write a treesitter major mode for Emacs
#5I'm not trying to bash Emacs or treesitter or anyone. But I find it mildly amusing that after so many decades, parsing and syntax highlighting aren't a perfectly solved problem, considering programming languages are the most used tools for developers.
What would you consider a perfectly solved problem in this case? I.e. how is current development experience bad and how it could be better?
In a perfect world of emacs/tree-sitter, I would imagine tree-sitter to be a single minor mode. You don't need 'java-ts-mode' and 'c-ts-mode'. Just a single 'treesitter-mode' toggle and it will call the treesitter binary to do the hard lifting.
I guess the reality just isn't so rosy.
Re: Let's write a treesitter major mode for Emacs
#6I'm not trying to bash Emacs or treesitter or anyone. But I find it mildly amusing that after so many decades, parsing and syntax highlighting aren't a perfectly solved problem, considering programming languages are the most used tools for developers.
The languages extension strategies for CSS pretifiers are usually pretty reasonable.
In editors this always seems extremely esoteric comparatively: I've tried doing it in a few.
I'm sure brilliant people find it easy, but I'm merely average on a good day.
I haven't tried extending any of these modern electron based editors, can anyone speak to that?
Re: Let's write a treesitter major mode for Emacs
#7Earlier quoted context omitted.
What would you consider a perfectly solved problem in this case? I.e. how is current development experience bad and how it could be better?
In a perfect world of emacs/tree-sitter, I would imagine tree-sitter to be a single minor mode. You don't need 'java-ts-mode' and 'c-ts-mode'. Just a single 'treesitter-mode' toggle and it will call the treesitter binary to do the hard lifting. I guess the reality just isn't so rosy.
A `treesitter-mode` is a so-so idea, because the way different languages are interacted with is different. The way lisp sexp handle in an IDE is different from Python's syntax. It doesn't make sense to try and have one mode that handles both - it is better to have many modes that interact with the common data structures that treesitter provides and then starts to provide specific convenience functions.
Even if all it was supposed to do is syntax highlighting, different languages are usually highlighted differently and presumably the person maintianing the bindings would need to be a language expert with strong opinions. The options are they either maintain their own mode or a module in `treesitter-mode` which is basically 2 ways of describing the same situation.
Although to address your other point it is quite funny that after 40 years and 29 versions of experimenting in OS design, GNU Emacs is starting to implement syntax highlighting properly for its system text editor.
Re: Let's write a treesitter major mode for Emacs
#8I'm not trying to bash Emacs or treesitter or anyone. But I find it mildly amusing that after so many decades, parsing and syntax highlighting aren't a perfectly solved problem, considering programming languages are the most used tools for developers.
What would you consider a perfectly solved problem in this case? I.e. how is current development experience bad and how it could be better?
I'm not the GP, but personally I'd consider syntax highlighting perfectly solved if it was handled in the language server. That way we could have highlighting performed by 100% accurate parsers instead of approximations. It wouldn't be as fast as in-editor simple tree-sitter highlighting, but I don't see any issue with my text appearing uncolored at first and gaining color as my editor polls the language server as I type.
Currently language servers support semantic highlighting which is close, but as far as I can tell, it seems meant to be supplemental to in-editor local highlighting rather than a full replacement.
Re: Let's write a treesitter major mode for Emacs
#9I'm not trying to bash Emacs or treesitter or anyone. But I find it mildly amusing that after so many decades, parsing and syntax highlighting aren't a perfectly solved problem, considering programming languages are the most used tools for developers.
Until TreeSitter came along the effort to add support for new languages to your editor would be gargantuan.
Now it's much, much easier providing there's a TreeSitter parser for your language.
I don't know of anything else that bridges the gap like this.
Re: Let's write a treesitter major mode for Emacs
#10Earlier quoted context omitted.
What would you consider a perfectly solved problem in this case? I.e. how is current development experience bad and how it could be better?
I'm not the GP, but personally I'd consider syntax highlighting perfectly solved if it was handled in the language server. That way we could have highlighting performed by 100% accurate parsers instead of approximations. It wouldn't be as fast as in-editor simple tree-sitter highlighting, but I don't see any issue with my text appearing uncolored at first and gaining color as my editor polls the language server as I…
But you want syntax highlighting performed by approximations, because when editing your code is only approximately valid.