I'm not against that at all, but it doesn't really work when you're on a shared codebase with people who use spaces to align things based on the assumption of fixed-width fonts. Things like:
hash[:foo] = 5
hash[:sdfkd] = "x"
hash[:x] = "y"
Of course, I'm against doing this anyway, because it causes issues when you want to add an even longer key to the hash.
If you are using a decent text editor it's easy to keep things aligned. Emacs for example m-x align-regexp = will do the trick. I would assume vim, etc have similar options.
Realigning the values causes all of the lines to change in a line-by-line diff (e.g. as displayed by git diff). It also makes "git blame" less helpful, since every realigned line appears to originate from the alignment commit.
I agree -- but I'd think the work-around would be to do whitespace-insensitvie diffs? Which would probably be a good idea if the codebase uses indentation like this?
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.
This algorithm sounds like it has a dreadful worst-case complexity. It can have to parse the whole file to give the intended result (eg. in the case of a dense table, when deleting a character at the end of the longest cell of a column).
It also has terrible partial results. For instance, removing the tab after `cell-missing` in the example triggers a weird alignment.
That is too bad, since the idea is bright.
PS. This is off-topic, but I cannot create a new thread on it, since it was submitted to HN six years ago and that old thread is locked: https://news.ycombinator.com/item?id=333626
FWIW, it's not that particular implementation that I'm in favour of. As you say, it has some issues.
Also, while the page I linked to was the first time I saw anyone offer a convenient name and write-up to cite, I should acknowledge that there had been discussions about using tab widths that varied by context long before that page was written. Many editors have provided related functionality where hitting tab once would automatically align your code blocks, function parameters, etc.
I suspect that for anything closer to the specific elastic tabstops idea I cited to become established, we'd need a distinct character rather than reusing ASCII spaces and tabs. This could work rather like the way various typesetting systems and DTP packages have "align to here" markers that don't necessarily introduce any extra horizontal space themselves but do indicate that consistency should be enforced across related lines.
I personally think that a standardised character like that and support for it in tools like editors and diff displays could bring several modest benefits: aside from the immediate convenience of aligning code more neatly if that's helpful, it could actually clean up a lot of whitespace-based diffs that tend to confuse tools today without necessarily having to ignore all whitespace, and of course it would improve the usefulness of proportional fonts when reading code, which I think is where we came in.
Do you create a new spreadsheet using a spreadsheet app every time your notes include tabular data? I ask because a proportional font would be incompatible with the table/spreadsheet syntax of every lightweight markup language I've used. I would hate to have to create a new spreadsheet using Excel every time I have new tabular data for my Org-mode-powered personal wiki rather than simply use Org mode's spreadsheet syntax.
I use proportional fonts for my latex editor, and have always been able to align my tables well enough in .tex files. Of course, latex output has no problem aligning table columns without using a fixed width font.
I tend to agree, I use monospaced fonts -- however -- what's wrong with tabs? Surely if you're using variable width fonts, you could pair them with tabs?
Let me know how that works for you if you ever write Lisp, Haskell, or have to deal with someone who thought they could make their $ALGOL_INSPIRED_LANGUAGE look cute by aligning everything into tables.
Mono space is a type writer anachronism. Lisp was designed in hype 60s and not many people write code in it; Haskell could benefit from better mathematical typesetting.
I've heard that going proportional would be bad, but I made the switch and have noticed yet any badly formatted third party code (I mostly use C#).
Haskell, despite how people talk about it, isn't necessarily that heavy symbol-wise. Table-based aligning makes haskell code look very good (esp. when dealing with a lot of pattern matching)
Haskell just looks horrible when set in ASCII at all; where did they come up with \ for lambda? It would definitely benefit aesthetically from at least more Greek use.
I know, but it's too subtle and makes the code look bizarre. Well, if there were lambdas everywhere, I'm not sure it would look much better...code would begin to feel more like a boring POPL paper.
Are you using a serif font? Because sans-serif is very bad when it comes to representing source code:
the characters 1lI and 0O all look alike.
For example Pidgin's choice of a sans-serif font always caused me troubles, had to either switch the font, or the system-wide sans-serif font to something where I can tell the difference.
Segoe UI. Honestly, I knew this would be a problem but I haven't had this problem yet. The most annoying thing is that subtraction (-) is too short in relation to addition (+).
In my ideal world, code would be typeset in proportional fonts, with mathematically appropriate glyphs chosen from a font with a comprehensive Unicode character set, including a proper minus instead of hyphen-minus.
The usual problems with this are arranging indentations/alignments neatly where you really do want them and avoiding an explosion of funny characters once you've got a large part of the Unicode character set to play with. Tools are pretty good at the first these days, but pity the poor Haskell developers if we don't fix the second. People will be writing logging libraries that use different levels of emoticon to save writing 'debug' and 'error'...