Costs to many lines on screen, nice font though.
That'd fix the lowercase r problem, I would think.
Also, for some reason I find the dot in the number "0" to be more distracting than using a slash to distinguish it from an uppercase "O".
hash[:foo] = 5
hash[:sdfkd] = "x"
hash[:x] = "y"
What issues? Needing to realign the values? If so, does your text editor not include alignment commands like these:
See eg: https://stackoverflow.com/questions/7310033/how-to-make-git-...
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.
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
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.
Doesn't everyone use latex for note taking?
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#).
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'...
Then I found Fira Mono. I use it everywhere. It looks great; it's very clear and easy to read, it has a nice style. Fonts are a very personal thing so thanks to Mozilla for finally letting me have one that was "mine".