1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
|
[[!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 – 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
- Q1: so tree-edit is orthogonal to the LSP features?
- A: only uses tree-sitter yeah
- Q2:any chance you tried this with Clojure as well?
- A: haven\'t tried it yet, i don\'t think tree-sitter-langs has a
clojure grammar AFAIK
- Q3: Would we be able to do things like extract statement to a
variable? For example, extract a a math operation happening in a
fucntion call argument into a separate variable an then replace the
funtion call arg with the variable name.
- Q4: How do tree-edit and combobulate compare?
- A: a lot of similarities, tree-edit replaces traditional text
editing style combobulate still implements
- Q5: Are similar packages for structural editing common to other
editors or they are just popular in Emacs cause of the paredit
tradition?
- A: emacs seems to be a trend-setter
- Q6: Great talk! How difficult do you imagine adding more languages
to Tree-edit will be?
- A: Trying to add python, not super simple, C-like should be drop
in replacements
- Q7: \@ethan 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?
- Q8: Any plans for an Evil mode integration? evil-textobj-tree-sitter
seems like it has a long way to go if it\'s to catch up to
tree-edit.
- 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).
Links and other notes:
- Github repo : <https://github.com/ethan-leba/tree-edit>
- editing operations that map directly to the structure of the
language
- inspired by paredit and lispy
- Another similar project is <https://github.com/mickeynp/combobulate>
by Mickey Petersen, the writer of Mastering Emacs.
- It\'s an open source project so contributers are welcome
- Future implication for this kind of work could be voice controlled
code writing/editing
# 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"]]
|
