⚠ Tree-edit is very much a work-in-progress. Expect to run into bugs and breaking changes!

Every programming language has a formally defined structure, but most text editors are completely ignorant to it. As a result, editing can oftentimes devolve into a tedious exercise in character manipulation.

Tree-edit provides language-agnostic editing operations that map directly to the structure of the language, abstracting away the process of manually entering syntax. Leveraging the tree-sitter parser, tree-edit always has access to the precise state of the syntax tree – and directly wields the grammars of the languages under edit to power it’s editing capabilities.

Overview

The repository contains two co-existing packages (that will eventually be split).

tree-edit: The core library for structural editing. This library is intended to be used by other elispers who would like to implement their own structural editing or refactoring commands.
evil-tree-edit: An evil state for structural editing with preconfigured bindings and visualization, as seen in the GIF.

To get an overview of tree-edit’s capabilities, check out the EmacsConf talk!

How does it work?

Tree-edit relies heavily on the tree-sitter parser, leveraging the JSON intermediate representation that tree-sitter outputs to have a full understanding of what is valid for a given language with no language specific efforts on tree-edit’s part.

To learn more about how tree-edit works under the hood, see this high-level overview or check out this org doc with executable code examples demonstrating how the syntax generation works.

Supported languages

Status	Language
✅	Python
🔨	C
🔨	Java

✅	Supported
🔶	Requires custom grammar
🔨	Under development

Tree-edit is designed to be as language-agnostic as possible. Currently the list of supported languages is not very impressive, but in theory it should be as simple as running a script to preprocess a grammar and adding a configuration file for the language.

See here to learn the process for adding a new language.

Limitations

A non-comprehensive list of some of the larger limitations that tree-edit currently has:

Impedance mismatch: Most tree-sitter grammars were not designed with tree-edit’s usecase in mind, so some grammars may be structured inconveniently for tree-edit’s purposes.
Tree-sitter-langs: Tree-edit currently depends on tree-sitter-langs to power the tree-sitter parsers, however tree-sitter-langs does not always have the most up-to-date grammars and is missing some languages. If this continues to be an issue a fork may be needed.

Contributing

Contributions are very much welcome! In particular, adding language files would be a great place to help. Otherwise, the issues are a good place to propose features or find ones to implement.

The project is fairly complex and the documentation is still in progress, so feel free to open a discussion if you’re interested in helping out but you’re not sure where to start!

Related projects

combobulate: Structural navigation and limited structural editing
grammatical-edit: Smartparens-like using tree-sitter (?)
evil-textobj-tree-sitter: Evil mode text objects using tree-sitter queries.
lispy: Lisp structural editing package – big inspiration for tree-edit!
smartparens: Multilingual package with structural editing limited to matching delimiters.

zkry / tree-edit