5 ms·
I think this all makes a lot more sense when seen in a practical context rather than the blown-up examples in the feature documentation. Take a look at the cod
by mortenjorck 3y ago
I think this all makes a lot more sense when seen in a practical context rather than the blown-up examples in the feature documentation.
Take a look at the code editor examples on the main site for Github Monaspace: https://monaspace.githubnext.com https://monaspace.githubnext.com Scroll down to the "Five Fonts" section and try unchecking the texture healing toggle.
The fisheye effect you get when looking at the font in 200pt goes away at 16pt, and in the context of a busy code block, has the effect of smoothing out the visual rhythm of the characters with only a minor disruption of the monospace grid. Perhaps it's not for everyone (it is a trade-off), but I think it's a smart compromise.
- tobr 3y agoI think this is a fun innovation and I might try to use it in my terminal, but for coding, the real solution should be obvious: use a proportional font.
- deleted 3y ago[deleted]
- Stratoscope 3y agoThis seems to be an unpopular opinion, but proportional fonts are great. One question people sometimes ask is, "How can you code in a proportional font? How do you line things up in columns?" The answer is you don't. For example, the Black code formatter for Python completely eschews column alignment of this sort: foo.bar(one, two, three) (Imagine that the words were long enough that the whole thing wouldn't fit on one line.) Instead, Black formats it like this: foo.bar( one, two, three ) No column alignment, only indentation. Code formatted like this is equally readable in a proportional or monospaced font. You don't need monospaced fonts! I've read and written all my code in proportional fonts for close to 20 years. My current one is Trebuchet++, a variant of Trebuchet MS that I customized in FontForge. Trebuchet MS is pretty good on its own. For example, all of the "confusable" glyphs are easy to distinguish. And it renders very nicely on a high-DPI display. Its tilde is pretty bad, though. It's tiny and almost looks like a hyphen. So that was the first thing I fixed, putting in a better tilde. Then I experimented with spacing for the _ and . glyphs. I added negative margin on both sides of the _, while keeping its width. And I added positive spacing on both sides of the . glyph. Consider code like this: snake_case_name.another_snaky_name() These spacing changes have the affect of pulling the individual words in each name closer together, while increasing the separation between the two names. It is subtle, but to my eye it helps readability. Next up will be to add some positive margin inside the three pairs of brackety things: (), [], {}. I have always found that it helps readability to add a space inside parens and such, but most contemporary code formatters prohibit this. With a proportional font I can tweak the font to put some visual spacing there.
- deleted 3y ago[deleted]
- adastra22 3y ago"If you stop doing things which derive benefits from monospaced fonts, then you can get away with a proportional font." Thanks, but no. Your foo.bar() example is significantly less readable the way Black formats it.
- Dylan16807 3y agoI don't like the extra lines, but also I almost never care if "one" is exactly lined up with "two". You can use proportional fonts with the first example too.
- kdmccormick 3y ago> can use proportional fonts with the first example too. what, how? Wouldn't the number of spaces you'd need to prefix lines 2 and 3 with vary between fonts?
- Dylan16807 3y agoNot if you don't care about "one" exactly lining up with "two". foo.bar(one two, three) //this is fine, and slight drift on different fonts is also fine I would have demonstrated in a proper proportional way but HN destroys NBSP.
- adastra22 3y agoThat was the whole point.
- Dylan16807 3y agoYou dismissed the idea as "if you stop doing thing which benefit from monospaced fonts", suggesting that monospaced fonts are better in this situation. My argument is that both fonts are just as good in this situation, and monospaced fonts aren't benefiting here. You don't need monospaced fonts to use formatting 1, you can just choose formatting 1 and then use either kind of font. Doesn't that mean I disagree with your post?
- jrmg 3y agoI can’t help but think that the example in that page has used ‘timing’ so much to deliberately show off texture healing - it’s a great example because the ‘m’ can expand in both directions and the ‘i’s end up looking the same. I suspect the state where different width variants of the same letter are close to each other would happen a lot more in the real world.
- Terretta 3y agoRight, and they show it above "time" where the "e" can't "give the space" so you can understand if it actually bothers you (probably not unless you stop and stare): const timing_end_m_ = () => { let timing_end = new Date(); let time_spent = timing_end - timing_start; // in ms
- galaxyLogic 3y agoThat's a good link. I think the text-healing mode with VS Dark Theme is clearly the most readable
- seanhunter 3y agoThis might be an autism thing for me but turning on texture healing on that page is so horrible it actually made me flinch. The fact that the "i" in "terminal dimensions" and the "i" in "width" aren't underneath each other makes it look like my monitor is broken or something. It's like someone has done it on purpose to mess with me.
- deaddodo 3y agoAfter seeing it in a larger context like that, I'm even more in agreement with OP. The weirdly random letter alignment screws with my brain much more than I thought from just the localized examples in the topic link. I'll stick to the consistent design for a slightly less aesthetic experience for that reason alone.