Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's write a treesitter major mode for Emacs

masteringemacs.org

Post reply on HN
Print view View original

11–20 of 86 posts

Re: Let's write a treesitter major mode for Emacs

#11

Post by pawelmurias »

craftkiller wrote: post #8
thih9 wrote: post #3

Earlier 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…

You would only get the top half of your code highlighted because a compiler doesnt usually continue when encountering syntax errors due to partial code

Re: Let's write a treesitter major mode for Emacs

#12

Post by tgv »

petepete wrote: post #9
raincole wrote: post #2

I'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.

Note that not that long ago, computers were simply not powerful enough to run that in acceptable time. Dedicated parsers can be much faster.

Re: Let's write a treesitter major mode for Emacs

#13

Post by mickeyp »

raincole wrote: post #2

I'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.

I clarified exactly why it is the way it is here:

https://www.masteringemacs.org/article/tree-sitter-complicat...

And also why using LSP to furnish your editor with highlight markers is an inelegant solution for many languages.

Re: Let's write a treesitter major mode for Emacs

#14

Post by craftkiller »

pawelmurias wrote: post #11
craftkiller wrote: post #8

Earlier quoted context omitted.

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…

You would only get the top half of your code highlighted because a compiler doesnt usually continue when encountering syntax errors due to partial code

That's sort-of already the case whenever we start a string in any language that supports multi-line strings. You type the first " and then the rest of your file gets re-interpreted as a string. It is annoying but I still think its a worthy trade-off, because I spend a lot more time reading code than being mid-edit with invalid syntax.

Re: Let's write a treesitter major mode for Emacs

#15

Post by wiz21c »

I've been using it a bit but it still not on par with, well, vscode. It tends to be a bit slow on big files (say 10000+ lines) when you open type an fstring in python such as 'print(f"p={' once the open accolade is typed in, it can get noticeably slow.

But well, I still love emacs :-)

Re: Let's write a treesitter major mode for Emacs

#16

Post by jdblair »

wiz21c wrote: post #15

I've been using it a bit but it still not on par with, well, vscode. It tends to be a bit slow on big files (say 10000+ lines) when you open type an fstring in python such as 'print(f"p={' once the open accolade is typed in, it can get noticeably slow. But well, I still love emacs :-)

It's so hard to give up your custom environment and keyboard muscle memory! (25 year emacs user here)

Re: Let's write a treesitter major mode for Emacs

#17

Post by G3rn0ti »

BTW:

While Emacs 29.1 comes with "treesitter" built-in, you still need to manually build and install any treesitter language plugin implementing the actual language specific parser. This can be fiddly and frustrating doing it yourself.

I had a quick success with using this convenience script: https://github.com/casouri/tree-sitter-module/. It provides fully-automated builds for the most popular languages (including typescript, c and c++).

This is how it works for "typescript":

1. Clone the repository: https://github.com/casouri/tree-sitter-module/

2. Install "build-essentials" (providing a c/c++ compiler if you're on Linux).

3. run "./build typescript" from within the repo

4. Copy the resulting shared library from "dist/libtree-sitter-typescript.so" into your "~/.emacs.d/tree-sitter/".

5. Open a random typescript file and try "M-x typescript-ts-mode" which should not give you any error but instead nice syntax highlighting.

You might find there is a treesitter plugin for your language available and it is even supported by "tree-sitter-module" but there is still no major mode, yet. Happened to me for Perl 5.

Re: Let's write a treesitter major mode for Emacs

#18

Post by _flux »

pawelmurias wrote: post #11
craftkiller wrote: post #8

Earlier quoted context omitted.

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…

You would only get the top half of your code highlighted because a compiler doesnt usually continue when encountering syntax errors due to partial code

If the code was valid at some point (e.g. when opening it) it could remember the old colorings of the rest of the code.

Though handling opening and closing a string and still ending up in an illegal state would need some more logic.. Maybe not worth it.

Re: Let's write a treesitter major mode for Emacs

#19

Post by troupo »

craftkiller wrote: post #14
pawelmurias wrote: post #11

Earlier quoted context omitted.

You would only get the top half of your code highlighted because a compiler doesnt usually continue when encountering syntax errors due to partial code

That's sort-of already the case whenever we start a string in any language that supports multi-line strings. You type the first " and then the rest of your file gets re-interpreted as a string. It is annoying but I still think its a worthy trade-off, because I spend a lot more time reading code than being mid-edit with invalid syntax.

Syntax errors are not limited to just typing a quote

Re: Let's write a treesitter major mode for Emacs

#20

Post by morelisp »

_flux wrote: post #18
pawelmurias wrote: post #11

Earlier quoted context omitted.

You would only get the top half of your code highlighted because a compiler doesnt usually continue when encountering syntax errors due to partial code

If the code was valid at some point (e.g. when opening it) it could remember the old colorings of the rest of the code. Though handling opening and closing a string and still ending up in an illegal state would need some more logic.. Maybe not worth it.

> If the code was valid at some point (e.g. when opening it) it could remember the old colorings of the rest of the code.

If you continue down this line of thinking a few more steps, eventually you produce tree-sitter.

Post reply on HN