The power of text-based editing in coding is that no time is wasted communicating semantics to the editor. Editing is a simple stream of character additions, deletions, and replacements; semantics are not required. This makes efficiency one-to-one with keystrokes. The work of any operation is simply the sum of its keystrokes.

Structured editing offers a different economy. The price of communicating semantics is paid up front, and then a (typically small) number of keystrokes communicates enough to make the semantics manifest.

Expressions involving few characters but complicated semantics typically make these economics unappealing. Consider x+1 , an expression with very few characters requiring very few keystrokes in a text-based environment. But the semantics aren’t as simple:

call the + function on the local reference x and the constant value 1

Expressions of this sort do not make a compelling case for structured editing. The cost of communicating semantics seems inordinate compared with the minimal characters necessary to form the expression. In fact, this situation feels viscerally frustrating: “This is the simplest statement I’ll ever code and it feels so cumbersome!”

But it would be incorrect to assume that the economics of structured editing scale proportionally from these sorts of simple expressions. In fact, they move in the opposite direction: as editing moves to more complicated refactoring commands the complexity of the semantics stays constant while the keystrokes and boilerplate become much more tedious.

Imagine you’ve written a simple expression that you later realized should be abstracted into its own function. Perhaps you anticipate this logic being broadly applicable, so your ideal refactoring is to build a new function around the expression and then immediately call it.

For example, you might want to transform something like this:

g(x) ? 0 : h(x, y)

into something like this:

def f(x, y) = { g(x) ? 0 : h(x, y) }

f(x, y)

Despite the numerous keystrokes and tedious boilerplate of this refactoring, the semantics are quite straight-forward:

Make this expression a function called f then refactor expression as call f

It’s commands like these where the upfront cost of communicating intent begins to outweigh the subsequent cost of keystrokes. This is a trade-off commonly leveraged by various editing paradigms.

Autocomplete features can be seen as a step along this economic spectrum. By engaging the autocomplete dialog, you communicate the semantics of your intent (i.e., “I want to reference a defined entity”), and in exchange for this up front cost you spend fewer characters to achieve your edit.

Similarly, modal editing (such as in VIM) offers this same trade-off: use a keystroke to communicate a semantic context and your next keystrokes become more valuable.