Live data from Hacker News

Let's write a treesitter major mode for Emacs

masteringemacs.org

81–86 of 86 posts

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

#81
post #40

Earlier quoted context omitted.

I wonder why there aren't more tools to allow structural editing like Lisp has. This way the file can never be in an unparsable state.

because in most languages there's a level of abstraction between the syntax of the language and the actual data structure of the program. To use the much maligned term, most languages aren't homoiconic, the internal structure of the program is hidden away from the programmer. Lisps essentially have no syntax, that's why it is trivial to manipulate a lisp program structurally.

You can do this with most other language too, but I think the challenge is that a lot of us have habits that we'd need to change. E.g. with structural editing I couldn't easily decide I want to add exception handling around a block in Ruby by writing "begin", then moving down, and writing "rescue ..." and "end" - I'd likely need to mark the block first. That may well end up being faster, but it's a fairly big change.

I wonder, though, if a "semi-structural" editor with a keypress to "complete what is otherwise an error" would work well. E.g. I write "begin" and so imbalances an expression, and the editor looked at what I typed that changed the parse from successful to an error and puts up options to insert "rescue ... end" or just "end". Maybe coupled with a warning on save if the file does not parse.

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

#82
post #17

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…

I found this snippet in one of Mickey's earlier tree-sitter posts that works great. It does require searching through the tree-sitter repo to make sure your paths are correct: (setq treesit-language-source-alist '((typescript "https://github.com/tree-sitter/tree-sitter-typescript" "master" "typescript/src") (tsx "https://github.com/tree-sitter/tree-sitter-typescript" "master" "tsx/src"))) (mapc #'treesit-install-lang…

For the record, it's in Mickey's How to Get Started with Tree-Sitter post:

https://www.masteringemacs.org/article/how-to-get-started-tr...

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

#83
post #52

Earlier quoted context omitted.

A treesitter-mode would make sense for organizational reasons and user-experience. But under the hood it would be just a proxy-mode which figures out the language and load the appropriate treesitter-sub-modes. And maybe in a more advanced version it could also mix modes for different languages.

But you're describing Emacs. Emacs figures out the language and loads the appropriate sub-modes. It even calls them modes. Modes are mixable. We're in a transition period while everything is rewritten to use tree-sitter. In a few years all the default major modes in Emacs are probably going to be tree-sitter based - unless the maintainers believe them to be better than tree-sitter.

> Emacs figures out the language and loads the appropriate sub-modes.

Not really. You setup hooks, usually based by fileextension, and emacs execute the hooks. Emacs itself has no understanding of languages. And this will not work well when there is no hook executed.

> Modes are mixable.

You can load multiple minor-modes, but there is always just one major-mode per buffer, and languages are usually major-modes. But ok, treesitter can be handled as a minor. But it still needs explicit support. You cannot give treesitter control over a range of text, let if figure out the language automatically and let it make it's thing. This needs explicit support.

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

#84
post #51

Earlier quoted context omitted.

> GNU Emacs is starting to implement syntax highlighting properly for its system text editor What do you mean?

It is a classic joke. Emacs is often a little behind competing text editors (Vim has better keybindings IMO, things like Visual studio have better IDE support, Atom text editor turns out to have better syntax highlighting, etc, etc). So, the line of the joke goes, it must not really be a text editor because it is not very good at it and has a wild array of other capabilities. Like "M-x dunnet". Must be an OS. Of cour…

> Of course the reality is that Emacs just copies good ideas from other people. A pretty normal Emacs setup uses Vim keybindings, LSP and now tree-sitter to get a good experience programming.

Too bad other people don't copy good ideas from Emacs. Why other text editors/processors have no equivalent of view-lossage is a mystery to me. Also, where-is, describe-key, insert-char, transpose-chars and lots of other very useful stuff...

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

#85

This is from the author of the excellent book Mastering Emacs. I am very far from being knowledgeable about programming on the Emacs platform, but I am trying to learn. I grabbed the name M-x-AI.com a while back with the goal of integrating other people’s Emacs packages with some of my own hacks into a better AI dev work environment and writing a short book on it. I have been using Emacs since, I think, 1982. There a…

Out of interest, do you use Emacs as an alternative to Jupyter for interactive work (examining plots etc.)? If so, which modes and packages do you use?

Jupyter can be used with Org Babel (interactive output, ansi escape codes, plots. I haven't tried widgets (shiny apps mostly cover this use-case for me https://shiny.posit.co/)).

https://github.com/emacs-jupyter/jupyter#org-mode-source-blo...

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

#86
post #79

Earlier quoted context omitted.

tree-sitter definitely can be used as a incremental parser for an LSP. But the original purpose was and still is to provide a standard format for an editor-agnostic way to parse languages. As somebody who wrote a tree-sitter grammar recently I can confirm that the library definitely has its share of... Interesting choices. But there's nothing else like it as most parser generators are non-incremental, don't do genera…

> has its share of… Interesting choices Curious to hear more.

Well, nothing truly horrible but here are things I find inconvenient (but working nevertheless) when using the sdk.

1. NodeJS-based utilities. The tooling around js doesn't lean itself well to integration with with the dev's environment.

2. The sdk itself is a mix of Rust, javascript and C. I'd say that this is at least one language too many - makes it harder to contribute. Ideally such fundamental projects should be as simple and homogeneous as possible.

3. I keep wondering if generating languages other than C should be supported.

The core idea of the library is brilliant either way so it sort of compensates all of the above.

Post reply on HN