Nick Gravgaard

This was once my understanding, and the accessibility argument still speaks to me, but I wish Elastic Tab-stops saw more discussion and support.

https://nick-gravgaard.com/elastic-tabstops/

I'll try to do my part.

I've been writing (and reading) a lot of Lisp lately, and have seen some projects adopt indentation idioms which offset blocks from the regular tab-stop intervals. A standard tab-stop might be +4, but then arguments might be lined up with each-other at +6 (+1.5 stops):

(list 'a 'b 'c) Any of those arguments could be forms, which might return to the standard tap-stop of +4 but off by 2 (let's call that `+4(+2)`):

(list 'a (with-foo quz (bar quz)) 'c) Lists written with the `quote` syntax might do the same thing, but produce an offset of only 1:

'(a (b (c))) The end result is that changing a code's indentation level (like when raising an anonymous function into a top-level definition) means adjusting the spaces (which were supposed to only be for alignment) if any preceding forms had introduced an offset. The alignment doesn't change, but it's relation to regular tab-stops does. Sometimes, this is an adjustment of zero, but you still need to think about it. In an all-spaces environment you could use vim's visual mode to select the block as a rectangle and paste it into the top level, but with "indent/align" semantics this same situation regularly requires maintenance (by inserting…

I do wish we were more adventurous in how we present our code in editors. As the article says, we seem to be stuck in a rut. Typography in the main editing area is almost always based on a classic monospaced text file. Colours are almost always based on “syntax highlighting”, which in turn often involves distinguishing elements of the language we’re looking at whose differences aren’t very important.

Given the potential of modern graphical environments and typography, I’d like to see languages and editors adopt simple spacing improvements like elastic tab stops¹. I don’t want to chose between an aesthetically pleasing layout that draws attention to patterns and anomalies in my code and a layout with completely uniform spacing because anything more carefully aligned is a pain to maintain in later edits and adds noise to diffs. We could shrink blank lines to half-height as well, which would keep the useful visual separation but waste less space.

I’d like to use a (somewhat) wider range of basic symbols than whatever we had in ASCII last century. Even allowing comparison operators like ≤, <, ≠ and = that align consistently would be a useful start.

I’d like simpler syntax highlighting, concentrating on distinguishing major language elements like literals, variables and types, and emphasising problems I probably care about like unclosed strings and misspelt keywords. I’d also like to see colour used more effectively for matching related code like opening/closing pairs or the…

AST level would have to automatically figure out what parts should be aligned, an alternative is to keep saving it in text but tweak the meaning of the "tab" character, so the developer still has control over what gets aligned: https://nick-gravgaard.com/elastic-tabstops/

Not great since viewing it in something that doesn't understand elastic tabstops would just be a mess, but it solves one of the issues the other response brings up, and I think some sort of user control like that is going to remain necessary either way.

Those points really depend on context:

- if it’s code, you should be using an automatic code formatter and that’s it. - if you write prose, sure, soft wrap.

If you grep, \s doesn’t care about space vs tabs.

Sadly, elastic tabs never caught as the default [0].

Maybe we would need something like a "semantic alignment" marker instead of using spaces for aligning things. Like beginning of function name, beginning of function argument, etc.

[0]: https://nick-gravgaard.com/elastic-tabstops/