Realizing the benefits of vertical alignment.

valign.txt

To realize the benefits of vertical alignment:

 - code must be *self-formatting*
 - deltas must be *semantic*

Each is within reach today, with moderate effort:

 - edit *virtual* files which continuously adapt
 - store semantic actions in a parallel VCS

The virtual file is the textual realization of an AST. Modifying it
represents an attempt to transform the AST. Successfully transforming
the AST (which is to say: if the modified file parses) leads to the
textual realization being recalculated.

In other words, your code is self-formatting. Not by brute forcing the
text through a lexically oriented pretty-printer, but as a consequence
of defining the means by which ASTs become Strings. You are "editing"
an immutable String value. The editor is the interface through which
you are authoring AST transformations. Writing to the file is how you
submit them.

Whitespace noise in diffs is a product of the primitive way we try to
make sense of changes. If I rename a value, it might touch fifty
files. What is the benefit of page after page of textual differences
showing me it being renamed in various contexts? There is only a tiny
amount of actual information:

  Rename(way-of-identifying-symbol, new-name)

We can continue to use git or a similarly primitive revision control
system, but alongside it we can encode changes according to their
*meaning* rather than in terms of the boilerplate which we call
'code'. Once done, the whole notion of whitespace noise becomes a
category error. We have ceased attempting to understand changes in
terms of how characters are pushed around in a String. Change is the
composition of intention.