[[!meta title="Tree-edit: Structural editing for Java, Python, C, and beyond"]]
[[!meta copyright="Copyright © 2021 Ethan Leba"]]
[[!inline pages="internal(2021/info/structural-nav)" raw="yes"]]

<!-- You can manually edit this file to update the abstract, add links, etc. --->


# Tree-edit: Structural editing for Java, Python, C, and beyond! 
Ethan Leba



[[!inline pages="internal(2021/info/structural-schedule)" raw="yes"]]

[[!table header="no" class="speaker-details" data="""
Name pronunciation | E-than LEE-ba 
Pronouns | he/him
Homepage | <https://ethan-leba.github.io/>
Preferred contact info | <ethanleba5@gmail.com>
"""]]

In this talk, I'll discuss a vision for how writing code could be, where the
editing operations map directly to the primitives of the language itself -- and
my humble attempt of implementing this vision. _tree-edit_ seeks to provides a
structural editing plugin supporting conceivably any language with a tree-sitter
parser.

**Structural editing does not have to be relegated to lisps or niche DSLs.**

I liken the state of code editing today to writing assembly. The reason why
people like Python more than assembly is that for most purposes, the building
blocks of the language are mismatched with our thought process. We don't think
in terms of registers and addresses, we think in terms of variables, functions,
etc. So when we write and edit code, why do we edit in terms of deleting,
inserting, replacing characters &#x2013; not wrapping, inserting, raising,
deleting expressions and statements?

I'll also discuss the implementation of tree-edit, which uses a novel
combination of the fantastic
[tree-sitter](https://github.com/emacs-tree-sitter/elisp-tree-sitter) parser
with an embedded logic programming DSL ([miniKanren](http://minikanren.org/),
using elisp port [reazon](https://github.com/nickdrozd/reazon)) to power it's
syntax tree generation.

Check out the GitHub repo [here](https://github.com/ethan-leba/tree-edit)!

# Discussion

IRC nick: ethan

- any chance you tried this with Clojure as well?
  - ethan: haven't tried it yet, i don't think tree-sitter-langs has a clojure grammar AFAIK
    - yeah I use sogaiu's (https://github.com/sogaiu/tree-sitter-clojure) but it does not have if else and the rest, only the main data types
- so tree-edit is orthogonal to the LSP features?
- did not know that miniKanren had an elisp port
- Seems like a really cool use of logic programming. All the examples I've heard of are much simpler than this.
- Wow, voice control is a good point
- Could tree-edit be made to work with Org (orgdown!) itself, or maybe rather what would be needed to get such a unified tree-editing framework to work also for complex Org trees?
- Awesome talk. I'm definetly going to try out tree-edit later :)
- Amazing talk!! Such a cool project
- `andrea: absolutely! Also for Orgdown - which is a good start since it is much easier.
- Andrew Blinn's talk on Fructure and Ethan Leba's talk on Tree-edit are really insightful.
- Agreed about the lack of formal grammar (only a proliferation of parsers) being a limiting factor. Maybe we could bridge directly to the available commands without going through a grammar though. A unified tree-editing framework across languages but definitely including Org would be awesome (ala lispy/etc).


# Outline

-   Discuss motivation                          (Why should I care?)
-   Demonstrate tree-edit                       (Live-coding with tree-edit)
-   Demonstrate tree-edit syntax tree generator (Elevator pitch on miniKanren)

<!--
-   20 minutes: (brief description/outline)
    -   discuss motivation
    -   discuss prior art (paredit, lispy)
    -   demonstrate tree-edit
    -   demonstrate and discuss tree-edit syntax tree generation engine

-   40 minutes: (brief description/outline)

same as 20 minutes, with more detailed discussion of the implementation.

-->
[[!inline pages="internal(2021/captions/structural)" raw="yes"]]

[[!inline pages="internal(2021/info/structural-nav)" raw="yes"]]