Nick Gravgaard, a programmer, writes about elastic tabstops for aligning code and about proportional versus monospaced programming fonts.
Commenters repeatedly cite his elastic tabstops as the best way to align text with proportional fonts, though they note weak editor support and formatting problems for non-users.
I don't follow you -- `easier scanning of indentation levels'?
With proportional font, the left-hand whitespace used for indentation of your code looks exactly as with monospaced font. Only the text itself changes somewhat.
The width of tab/positions of tabstops has nothing to do with font itself; it's property (often settable) of the editor (or in rare case of the underlying terminal). May be expressed as `times the space width', but that's it.
Perhaps you mean aligning of function argument and/or parameters one below another, or indentation of parts of expressions one below another? That indeed can't work with proportional font IF the peers in your project use different font (size or shape) or tab-stop setting. Can't work with monospaced font either -- again, IF the peers on your project use different tab-stop settings. Which is prevalent, AFAIK. Some use 12'' netbooks, other use 23'' desktops. I've even known a guy who used a T221 [1]. One size does not fit all.
Nb., you may want to read up on http://nickgravgaard.com/elastictabstops/ if you like to align stuff that way. I don't like that idea though.
----
[1] http://en.wikipedia.org/wiki/T221
Elastic tabstops[1] are one of those things I wish was standard in the programming world, because it seems to have essentially no downside as long as tools support it.
Failing that, many text editors will provide some sort of realign command that will adjust spaces on adjacent lines so the columns line up as intended in these situations, and many diff tools and related functions like 'blame' commands in VCSes will allow you to ignore whitespace-only changes these days.
Personally, I prefer to have non-trivial code neatly lined up, despite the potential irritations when reviewing changes later. I find the advantages of highlighting patterns (and highlighting where a line didn't follow the same pattern as all the others) outweigh any practical issues where a few tools show diffs I would prefer to ignore.
I make an exception for Python, because PEP8 explicitly advises not to do this, and sometimes having a coding style that is consistent with everyone else is worth more than any of the above.
[1] http://nickgravgaard.com/elastictabstops/
Tabs for indentation, spaces for alignment.
You wouldn't need to customize anything, it would look good at all tab widths and people who prefer 2 space sized indents would be able to use that in their editors.
Actually, it could be even better, we could use tabs for aligning to tables too if editors supported elastic tabstops [0]. Unfortunately, the only ones that do don't support other essential features like saving when they lose focus.
Please note that i disagree with how the example aligns function params. The space/tab there looks bad and params should be aligned with spaces using a formatting tool (which every sane language should have).
Or, y'know, scratch that, why don't we commit the AST (enhanced to include comments and other hints like blank lines) to git and let everyone use their formatting.
</rant>
[0]: http://nickgravgaard.com/elastic-tabstops/
I think I've said this to you before, but in case I haven't, I suspect that the best way to handle proportional text in formattable plain text is some variant of Nick Gravgaard's "elastic tabstops" https://nickgravgaard.com/elastic-tabstops/:
> Each cell ends with a tab character. A column block is a run of uninterrupted vertically adjacent cells. A column block is as wide as the widest piece of text in the cells it contains or a minimum width (plus padding). Text outside column blocks is ignored [for layout, though it is displayed].
I think the main deficiency in his proposal is that he enforces a minimum of one space of whitespace padding on the right of his column.
> Still perpetually disappointed every new "neo terminal" is monospace tho.
Have you thought of ways around the path dependence[1] on monospace imposed by existing bodies of textmode UIs (and source code)? It seems unlikely that a new terminal-esque tool would succeed without some kind of legacy support. The best concept I've come up so far with is to build in affordances which handle legacy vs. new-world user interaction and app I/O models.
Related, I continue to hold out (vain) hope that elastic tabstops[2] will someday gain traction.
[1] https://en.wikipedia.org/wiki/Path_dependence
[2] http://nickgravgaard.com/elastictabstops/
I agree with that many present tools expect character grid, but moving away from character grid would be not as much work as it seems IMO.
Code can be aligned with elastic tabstops ( https://nickgravgaard.com/elastic-tabstops/ ) or virtual formatting (that things are aligned according to syntax regardless of whitespace).
Things to align in terminals are mostly tables, and they could be rendered as tables if the terminal supporting that knew that they are tables. Nushell natively supports tabular data structures, so rendering them as proper tables would need just one change – the table renderer.