22 December 2021

Treefrog: a Tool for Writing Code

This is the intro post I wrote for Edita (which was called Treefrog then) for the first alpha launch.

I started researching and prototyping AST editors in 2017 after becoming frustrated with my editor’s lack of understanding of code and the consequent need for me to perform repetitive text updates to carry out conceptually simple code changes. The idea of having an editor that fundamentally understood the structure of code – specifically its AST representation – seemed like a promising avenue to begin creating a better editor.

As you might guess though, AST editors haven’t taken off, and there’s a good reason: it’s hard to design a user-friendly interface around them. There are cases where AST manipulations happen to overlap nicely with conceptual edits and thereby provide a much more rational and ergonomic interface than traditional editors—but there are many more cases where they don’t. It turns out that having to think in terms of AST manipulations all the time can be just as much of a chore as editing text.

I realised this fairly early on and in recognition of it my first prototype supported two modes, normal mode and AST mode. You could switch between them seamlessly and the visual representation remained pretty much the same – so you got the benefits of both without too much cost in switching. But after coming back to the problem recently I’ve come to believe that text and AST editors actually make the same fundamental mistake at some level, and that is designing around a data structure in the first place.

It seems logical to use the basic data structure as a starting point for the design of the commands that will ultimately edit the data structure. The problem is that this approach inevitably makes itself apparent in the structure of the interface. Text editors feel very much like tools for navigating and manipulating rows and columns of text, and AST editors feel very much like tools for navigating and manipulating syntax trees.

Treefrog, my latest project, is based on the realisation that what we need is a tool for writing code. This sounds too obvious to be worth stating at first, but it’s taken me a while to fully appreciate it and integrate it into the design process. When you edit code you’re changing the function and organisation of a program. The thought processes are about solving a problem and expressing the solution in terms of the features and vocabulary of the language, and a well-designed editor should make it as easy as possible to express these thought processes as changes to the code.

Designing for Thought Processes, not Data Structures

What is the fundamental purpose of a code editor? I think it’s something like: mapping the thought processes involved in programming and then creating an intuitive and ergonomic interface for expressing them. Using this as a guiding principle, Treefrog’s interactions are explicitly designed around the following types of thought process:

Tree Mode

To enable concise and ergonomic expression of these thought processes, Treefrog has a new mode, called Tree mode, that works on the structure and meaning of the code and carries out the corresponding text edits automatically. Some of the main concepts and features implemented so far are:

These are just the first few concepts and features I’ve come up with while pursuing this “thought-processes-first” approach, and I’m excited to keep prototyping and iterating to see what a modern code editing interface can look like.