[HN Gopher] Almost monospaced: the perfect fonts for writing
___________________________________________________________________
Almost monospaced: the perfect fonts for writing
Author : blakewatson
Score : 369 points
Date : 2022-11-06 23:31 UTC (23 hours ago)
(HTM) web link (blakewatson.com)
(TXT) w3m dump (blakewatson.com)
| c-smile wrote:
| For some reasons, I've found that good, old, Verdana (as used on
| this very HN) is the most editor/writer friendly.
|
| IMHO of course.
| kristiandupont wrote:
| I used to use it as well.
|
| I stopped because the spaces are too small for my liking. It
| worked when I was using 4 spaces for indentation but now the
| more or less agreed-upon standard is 2 (for JS/TS which I
| mostly write). I wish I could create a custom version with a
| larger space.
| quesera wrote:
| > Verdana (as used on this very HN)
|
| Hm. If Verdana is the render font for you here on HN, I believe
| that's that's all about your browser config, and nothing about
| HN.
| vikingerik wrote:
| HN does specify Verdana, so that's what you'll see unless the
| browser is overriding that somehow. See
| https://news.ycombinator.com/news.css
| quesera wrote:
| Oops, you are quite right!
|
| I do override it, for more than ten years. That's what I
| get for posting without sanity checking myself.
| SturgeonsLaw wrote:
| Verdana is the font of the New Millennium and I will not
| entertain competing suggestions
| TranquilMarmot wrote:
| This is the first time I've heard of iA Writer, it looks like
| exactly what I need right now for nanowrimo... focused on writing
| prose with some minimal feedback tools. Going to give it a shot!
| sandyarmstrong wrote:
| My first time seeing it too, it really does look appealing! I
| am using Scrivener's very generous Nano demo this year
| (https://www.literatureandlatte.com/nanowrimo). Free from Oct
| 15 - Dec 7, and at the end of that you get a 50% discount if
| you hit 50k words, which is pretty cool. So anyway, I've got my
| outline and stuff all in Scrivener but maybe I'll try iA next
| year, or for some other markdown writing work. It kind of
| reminds me of what Tomboy notes felt like in GNOME back in the
| day.
| blakewatson wrote:
| Good luck! I'm also doing Nano and was supposed to be working
| on my novel but instead I wrote about the font I was using.
| karmakaze wrote:
| Input is a great programming font. It also lets you customize a
| bunch of options (e.g. slashed-0, loopy-a or g, serifs on i/l,
| etc). Free download for private use[0].
|
| [0] https://input.djr.com/download/
| Gordonjcp wrote:
| In the iA Writer Quattro font sample look at the kerning in the
| word "buckles". You could drive a bus through the gap between the
| 'u' and the 'c'.
| crazygringo wrote:
| As far as I know, "American Typewriter" is basically the original
| "almost monospace" font:
|
| https://en.wikipedia.org/wiki/American_Typewriter
| mbauman wrote:
| It'd be interesting to have an eventually-consistent monospaced
| font that adjusts the widths of characters like `w` and `i` such
| that when they're within a few characters of eachother they
| become more proportional. Obviously adjacent characters can be
| done with ligatures so `wi` is still 2 char-widths wide, but
| aren't modern font-rendering systems smart enough to do more than
| ligatures with alternatives? I wonder what it'd feel like to
| watch these characters adjust width as you type.
| panda88888 wrote:
| This is great. I am going to try it out.
| tapanjk wrote:
| > But there is a reason we don't use monospaced fonts everywhere.
| They are somewhat hard to read because [...]
|
| Well, not sure what is the basis for that assertion, but I find
| it easier to read text rendered in a monospaced font (Courier is
| my favorite). In fact, when I need to read something longer than
| a minute on the browser, I switch to monospace (with help of a
| browser plugin). It's not about text alignment -- it does not
| matter when reading prose, but perhaps about the familiarity of a
| font.
|
| As an aside, I also try to get rid of formatting when reading
| long text. It allows me to focus on the essence of the written
| word. Perhaps, this is why the old school mailing lists and
| message forums are more appealing than the modern crop of social
| media apps. Also plain text email (what a rarity in the corporate
| world today!).
| upofadown wrote:
| Yeah, if everyone was used to reading monospaced fonts then
| proportional fonts would be hard to read. I suspect there might
| be a bit of an advantage for proportional in terms of ultimate
| reading speed in that you might be able to fit in an extra word
| in your scan, but the alignment of a fixed grid might help a
| bit too. The real value of proportional fonts is that you can
| print more stuff on the page and make your book shorter and
| cheaper. In today's world the paper is basically free, so that
| is no longer an issue. It just means that you have less text on
| the screen and will have to page a bit more often.
| ghaff wrote:
| I have to disagree a bit. Even stipulating that there may be
| some economic drivers for more compact text, my observation
| is people largely switched to using proportional fonts
| (outside of some specialty cases like code or tabular data)
| as soon as it was technologically possible to do so. People
| generally preferred proportional fonts when it was practical
| to use them with the equipment reasonable at their disposal.
| syrrim wrote:
| > You might be thinking, "Okay, but now characters won't line up
| neatly." Thats true, but the upside of this sizing means you
| still retain the typewriter aesthetic with a bit more legibility.
| Notice the difference?
|
| Does it? It feels like the "typewriter aesthetic" is pretty much
| gone. The comically wide thin characters (i, r, l, etc), and
| comically small wide chars (m, w) are the clearest difference of
| such a font; without that it looks like a normal proportional
| font (which it basically is).
| devmunchies wrote:
| I use a lowercase "L" and "LST" (in lowercase) for variables
| representing lists in function args.
|
| For me the lower L and the number 1 have to be different. Most
| mono fonts make them almost identical.
|
| Typing "lst" looks like 1st (First). They either need to curve
| the bottom of the lowercase "L" or remove the bottom bar of the
| one.
| every wrote:
| I prefer Source Code Pro for the terminal:
|
| https://adobe-fonts.github.io/source-code-pro/
| shagie wrote:
| Source Code Pro was my go to for a long time (
| https://blog.typekit.com/2012/09/24/source-code-pro/ gets into
| the design of it) - the 1Il|iO0oB8 set is where its most
| interesting to me (and why I liked it).
|
| However, when Jetbrains Mono came out, I switched my code
| editors to it (IntelliJ was trivial) -
| https://www.jetbrains.com/lp/mono/ (and no, I don't like
| ligatures). The slightly larger lowercase high at the same font
| size makes it a bit easier to read without boosting the entire
| editor's font size up, the 'g' debate I lean to the single
| story, open tail form ( https://www.typeroom.eu/the-elusive-
| mystery-of-letter-g-expl... ).
| every wrote:
| I enjoy in Source Code Pro that every character is
| unambiguous...
| systemvoltage wrote:
| I am not convinced. They should just finish the fitting/kerning.
| Seems like a fad more than anything else.
|
| In the screenshot, if you were to see a properly fitted
| proportional version of iA Quattro, you'd ditch iA Quattro. But
| that comparison is not presented, I don't think they've tried
| making a proportional version of it.
| blakewatson wrote:
| That's a good point. Something close to a "properly fitted
| proportional version of iA Quattro" might be Nitti Grotesk.
| https://www.boldmonday.com/typeface/nitti-grotesk/
| systemvoltage wrote:
| It's like this: A) Here is an unbaked cake. B) Here is a
| half-baked cake. But, the argument they are making is B) is
| better than C) Fully baked cake. No fully baked cake is
| presented for evaluation.
|
| You can't use Nitti Grotesk, a cookie batter, to make an
| argument here either for a fair comparison. It's an entirely
| different thing.
|
| In order to do a proper comparison, they should finish the
| kerning job and present their arguments fairly and squarly.
|
| The image I am talking about is:
| https://i0.wp.com/blakewatson.com/wp/wp-
| content/uploads/2022...
|
| It needs a 3rd line "iA Writer Proportional". Looking at the
| word "next" in iA Quattro, the fitting looks really bad which
| is a known trade-off in monospaced typefaces, but not an
| excuse to leave it like that in a proportional typeface.
| joemi wrote:
| Similarly, the image with Input Mono caught my eye:
| https://i0.wp.com/blakewatson.com/wp/wp-
| content/uploads/2022...
|
| The word "chain" looks more like "cha in" which just makes
| the font seem unfinished to me.
| systemvoltage wrote:
| This stuff is like nails on a chalkboard to me. It is
| extremely unpleasant :-) It makes me appreciate good
| typefaces more, my favorites being anything designed by
| Matthew Carter. Legendary:
| https://en.wikipedia.org/wiki/Matthew_Carter
| carabiner wrote:
| Meta: Why is HN obsessed with typography?
| Archelaos wrote:
| HN likes beautiful code.
| dfee wrote:
| HN likes beauty.
| izietto wrote:
| Because many HN readers are developers, and developers deal
| with characters all the time
| neilpanchal wrote:
| Something that converts abstract glyphs to bezier curves and
| projects that to your eyes deserves attention and care.
| Typefaces bring the abstract idea of what a glyph is
| semiologically, to the physical 2D space. Made up of bezier
| curves, the have to abide by conventions but have considerable
| room in expressivity as well as design intent for a specific
| purpose. Typefaces are fascinating and the process of designing
| them is underrated and unappreciated by public at large.
| Billions of people rely on them, they're everywhere and you
| interact with typefaces all day, everyday.
| forgetfulness wrote:
| Programmers work with text all day. We think of that text we
| work with as the subject matter very often and that sparks
| lively debates.
|
| There could also be an element of tradition; prestigious
| institutions and individuals, like Bell Labs, Donald Knuth and
| Apple, have devoted significant resources to typesetting and
| publishing, so an appreciation for typography could be seen as
| a marker of sophistication from that.
|
| And lastly we must often have some working knowledge of the
| design of user interfaces at some point in our careers, and you
| need to have some notions of typography to be effective at
| that.
| kstenerud wrote:
| "You might be thinking, "Okay, but now characters won't line up
| neatly." Thats true, but the upside of this sizing means you
| still retain the typewriter aesthetic with a bit more legibility.
| Notice the difference?"
|
| Umm... no?
|
| "The difference is subtle but notice that the sample on the right
| gives letters like lowercase "m" a little leg room, improving the
| readability of the code."
|
| Uhh... If you say so...
|
| I honestly don't see any of the upsides he's talking about. But
| the downside of things not lining up is definitely real.
| oneeyedpigeon wrote:
| "The difference is subtle"
|
| I noticed the difference immediately -- but not in a good way.
| I just felt a much stronger preference for the version on the
| left, the true monospace. I initially put it down to the indent
| -- that "n" beginning "num" just looks horribly placed wrt to
| line above it -- but, on reflection, I think it's the 'sans'
| properties that make it less pleasant for me -- like the "i"
| and "l" in "while" that are much rounder and, of course,
| without even slab serifs.
| lelanthran wrote:
| Too true. The only reason to use monospace is to line up the
| characters.
|
| If I don't need characters lined up I can use just about any
| font there is.
|
| So this font is not competing with monospace fonts, it's
| competing with _all_ non-monospaced fonts, so there 's really
| no advantage in using it.
| chipotle_coyote wrote:
| I use iA Writer Duo for writing prose and fiction a lot.
|
| If you're willing to pay for typefaces, though, there's a really
| good "almost typewriter" font called Triplicate, which comes in
| _four_ versions -- the original, a slight variation with the same
| metrics as Courier, a "code" version that has a few characters
| changed to be better for coding (this is a great alternative to
| the more expensive Operator Mono, in my experience), and a
| proportional one which fits the "almost monospaced" idea. (It's
| not designed for coding, but I don't think proportional fonts
| work for coding in most editors.)
| chrismorgan wrote:
| Unfortunately applying both Poly _and_ Code gives you an
| imperfect result: the default l glyph has a flat base, Poly
| makes it narrower, and Code makes it a curly tail, but enable
| both (e.g. font-feature-settings: "ss01", "ss02") and you get
| the Poly glyph rather than the Code glyph or a hybrid, both of
| which would be nicer, and MB has said "won't fix" (and I
| haven't gone to the trouble of patching it myself).
|
| A demo of my own of Triplicate with use of both Poly and Code:
| https://chrismorgan.info/blog/rust-fizzbuzz/, code is all Poly
| + Code, compiler errors are just Code (it uses columnar
| alignment, so not Poly). The lowercase l can be seen in all the
| figures in one form or another (e.g. "else" in bold, "result"
| in regular, but not " _println!_ " because italics always uses
| a curly-tailed l).
| chipotle_coyote wrote:
| I'd never actually tried to enable both at once, but I'm not
| surprised it doesn't work. I love writing _prose_ with
| Triplicate Poly, but I code with monospaced fonts, as neither
| most code editors nor most codebases seem to work that well
| with proportional fonts.
| beaker52 wrote:
| A link for those interested:
| https://practicaltypography.com/triplicate.html
| blakewatson wrote:
| I love Matthew Butterick's fonts (eg, Triplicate). The license
| for his fonts is perhaps the most generous I've seen when it
| comes to commercial fonts.
| thih9 wrote:
| Is it possible to use a font like this in a terminal emulator?
| userbinator wrote:
| I think when a font has all the characteristics of being
| monospaced like large serifs etc., but actually isn't, it looks
| subtly "off". I remember distinctly the user manual of a
| motherboard I had near the turn of the century somehow had
| screenshots of the BIOS setup utility rendered in almost-
| monospaced Courier New, and it looked sufficiently weird that it
| was distracting.
| boredtofears wrote:
| Courier New is monospaced.
|
| https://support.microsoft.com/en-us/topic/microsoft-
| supplied....
| userbinator wrote:
| I know it is; but they had somehow managed to change the
| glyphs spacing so that it isn't, yielding the same odd effect
| that I see in the sample in this article.
| efortis wrote:
| Here's proportional font for camelCase programming. It adds a
| padding to the left of the capital letters, and has a much wider
| space character.
|
| https://ericfortis.com/portfolio/design#-verdana-camel
|
| ---
|
| For aligning content, I think IDEs should be able to represent
| some parts of the code as tables. For example, similar to the
| Decision Tables of Jetbrains Projectional Editor:
|
| https://youtu.be/iN2PflvXUqQ?t=357
| s_dev wrote:
| https://www.jetbrains.com/lp/mono/
| vbernat wrote:
| Iosevka, a customizable monospace font, also has quasi-
| proportional (almost monospace) varients: Iosevka Aile and
| Iosevka Etoile.
| makach wrote:
| My use case for monospace is actually to align things perfectly
| when I write code.
|
| /Almost monospace/ is probably great _for writing_, but I find it
| a bit frustrating that the author doesn't address lining up
| things with /almost monospace/...
| svat wrote:
| Meanwhile, at the other extreme, in many proportional fonts the
| widths of letters vary so characteristically that clever readers
| can decode a text mostly just from the widths: see Donald Knuth's
| "N-ciphered texts":
| https://digitalcommons.butler.edu/cgi/viewcontent.cgi?articl...
|
| (Not linking the solutions here to make it harder to spoil the
| puzzle, but you can find them online with a bit of effort --
| maybe this will help:
| https://digitalcommons.butler.edu/cgi/viewcontent.cgi?articl...
| -- and it's also reprinted in _Selected Papers on Fun and
| Games_.)
| themadturk wrote:
| I love writing with monospaced fonts (just as the author of
| article says, they look "writerly"), but I detest the fonts in iA
| Writer. I just can't stand to look at them, so I don't use the
| software (which would be great if it allowed me to choose other
| fonts). I also hate Courier New, which is a weak and spindly
| font. My favorite is Courier Prime.
| blakewatson wrote:
| Take a look at Drafting* Mono:
| https://indestructibletype.com/Drafting/
| h4n1 wrote:
| This is a great font! It feels to me almost like a
| 'handwritten' version of the font I use, [Julia
| Mono](https://juliamono.netlify.app/)
| glitchc wrote:
| Wow, this is amazing! Thank you for sharing.
| gnuvince wrote:
| Oh, that guy and his stupid habit of putting an asterisk in
| the font name--impossible to use in Emacs.
| vehemenz wrote:
| Reading is a big part of writing, and I'm not sure how almost
| monospaced fonts would perform for reading. Probably about
| average, if the conclusions from this study are correct:
| https://www.nngroup.com/articles/best-font-for-online-readin....
| moralestapia wrote:
| It would be nice to have a space character for the 50% or 150%
| width some of these letters use. That way you could still line
| things up if you chose to do so.
| idlehand wrote:
| Would be neat to have ligatures, for example for lowercase i
| followed by space, to restore column alignment.
| catlifeonmars wrote:
| Isn't that what tab does?
| moralestapia wrote:
| Not really, this is within characters.
| somethingsaid wrote:
| This exists as various white space characters
| https://en.m.wikipedia.org/wiki/Thin_space
| tooltower wrote:
| Another reason for using almost monospace: international
| languages. Many indic languages simply don't have good monospace
| fonts. It's not easy to design. They stick out in code, as a
| result.
|
| But I've always wondered if allowing three or four different
| widths would help. We could still align text if (narrow) spaces
| were the smallest unit, and other widths were repeated multiples
| of that.
|
| This makes me think it's doable.
| DenisM wrote:
| Neat idea. This would probably vindicate the "tabs" people of
| the tabs/spaces debate.
| adastra22 wrote:
| Same goes for East Asian languages which are monospaced, but
| square. If you mix English (or code) with
| Chinese/Japanese/Korean, you get a mixed-width mess.
| akho wrote:
| I'd say that for coding the critical bit is not "things lining
| up" -- it's a bad practice anyway -- but wide and clear
| punctuation (`[{(` &c).
| leephillips wrote:
| Proportional "typewriter" fonts are an old idea. TeX has them
| (cvtt).
| raldi wrote:
| To each their own, but this reads to me like an April Fool's
| post.
| asciimov wrote:
| Not sure if it's the font, the colors, the kerning, or my
| browser, but this website hurts my eyes!
| blakewatson wrote:
| Sorry to hear that. There's a toggle switch for light mode if
| that helps.
| delta_p_delta_x wrote:
| > iA Writer
|
| The typeface is a modification of IBM Plex Mono[0][1]. I'd
| recognise that 'a' glyph _anywhere_.
|
| [0]: https://github.com/IBM/plex
|
| [1]: https://www.ibm.com/plex/
| Ezku wrote:
| Well spotted!
|
| > This is a modification of IBM's Plex font.
|
| https://github.com/iaolo/iA-Fonts/tree/master/iA%20Writer%20...
| zichy wrote:
| I like your taste - Input and IBM Plex (on which the iA Writer
| family is based) are my favorites as well. iA's old typeface
| Nitti is great as well.
| blakewatson wrote:
| Nitti is the OG monospaced writing font for me. Soon as I
| experienced it on those older versions of iA Writer I was
| hooked. I do love IBM Plex and these derivatives but I also
| miss Nitti. Might have to pick that one up from Bold Monday for
| old times' sake.
| bsimpson wrote:
| Isn't the whole point of monospaced fonts columnar alignment
| (e.g. the table in the article)? Seems like "almost" defeats the
| point.
|
| Then again, I don't see values lined up much these days:
| { "someKey": "someValue",
| "someOtherKey:" "someOtherValue,
|
| and if you only care about leading whitespace (that is, the
| whitespace before a character appears on the line), maybe it
| doesn't matter how your font is spaced.
|
| I suspect numbers in these almost-mono fonts are monospaced, so
| numerical values should still have nice rhythm too.
| kqr wrote:
| Numbers in many non-monospaced fonts are also monospaced. It's
| a font feature known as tabular figures.
| opk wrote:
| I long ago concluded that trying to line stuff up in columns
| like this in code is a mistake. It often results in realignment
| of blocks for small changes so what should be a small diff in
| the git history ends up being big.
|
| Only rarely is the vertical alignment useful because mostly
| code isn't read vertically. Used in moderation, the reverse
| Christmas tree style used in the Linux kernel can be as good
| for readability (sorted longest to shortest). For some constant
| structures a reordering of fields to put the variable length
| element at the end of the line removes the need for padding
| space (like in the output of `ls -l` where filenames come
| last).
|
| A common indentation style for continuation lines is to align
| with the start of arguments to the function. I've never seen
| the sense of this variable amount where indentation after a
| while is much more than after an if. Double the normal
| indentation for continuation works well in languages where line
| continuation isn't otherwise distinct from normal blocks.
| ako wrote:
| I stopped manually formatting code long ago, just accept what
| the code formatter tool decides is good enough. Saves a lot
| of time.
| sverhagen wrote:
| In circumstances, and depending on configuration, the code
| formatter tool may still aim for alignment, such as
| assignment operators on subsequent lines. Whether you like
| that or not, for me the question still stands: how does
| that jive with "almost monospaced".
| pmontra wrote:
| I've been using proportional fonts in programming for
| about ten years. I stopped doing things like
| abc = 1 d = 2
|
| which add very little readability value IMHO.
|
| Things like func(arg1, arg2,
| arg3)
|
| usually don't align well because func( has a different
| width than the five spaces in the lines below. However
|
| 1) my text editor (emacs) aligns those lines for me
| (probably any programmer's editor does) so at least I
| don't have to do precision work
|
| 2) I ended up writing code like func(
| arg1, arg2, arg3 )
|
| especially with named arguments (arg=value). That aligns
| even with proportional fonts and all arguments
| immediately stand out.
|
| If the arguments are few (two or three) and there are no
| named arguments I don't break them on multiple lines.
|
| The result is that no coworker ever complained about my
| code.
|
| Languages with a formatter (Elixir) solve the problem
| once and for all and align well with both kinds of fonts.
| anilakar wrote:
| Formatting your code in an unintuitive way because of the
| font is a code smell to me.
| pmontra wrote:
| Honest question: which one is unintuitive?
| nkrisc wrote:
| Viewing the examples generally, the second one better
| communicates hierarchy at the cost of an extra line. The
| arguments are all grouped together visually and without
| distraction, while in the first example the first
| argument gets muddled with the function name. Why? To
| save a line break?
| kazinator wrote:
| The canonical notation is like this:
| func(arg1, arg2, arg3)
|
| the first example splits it across multiple lines in a
| way which maximally preserves the other aspects of the
| notation.
|
| The argument is already being muddled with the function
| in the same way.
|
| These conventions are seen in the wild:
| func (arg1, arg2, arg3)
|
| and func( arg1, arg2, arg3 )
|
| The real fix for that muddling is to drop the commas, and
| move the parenthesis to include the function:
| (func arg1 arg2 arg3)
|
| Now func and arg1 are no more or less muddled than are
| arg1 and arg2. :)
| alpaca128 wrote:
| Why? The purpose of code is to be readable to humans.
|
| At the same time I get your point and also the argument
| about Git diffs (which also should be readable). So maybe
| the ideal situation would be a separation of code and its
| formatting, so that we have more options than tabs and
| also no need for crutches like tabs. Like a better, more
| flexible code formatter that lets you display and edit
| code in the editor using one style but then saves the
| file in a standard format that's consistent across the
| whole project.
| seanmcdirmid wrote:
| That's what many auto formatter do anyways, even ones
| setup for fixed width fonts.
| amadvance wrote:
| I do something similar also with if() and others:
| if (condition... && condition... &&
| condition... ) {
| tuyiown wrote:
| Same here but pushed it to force same column condition
| statement: if (( condition1
| ) && ( condition2 ) && ( ...
| )) {
| Izkata wrote:
| But that loses the table-like structure and makes it
| harder to read.
| ako wrote:
| It should ignore "almost monospace". Most projects have
| multiple developers, you should assume different
| developers have different IDE/font preferences, so your
| formatting shouldn't try to cater for it.
| GoblinSlayer wrote:
| I just put stuff on one line and let the editor wrap them.
| Doesn't waste vertical space, compatible with any font, any
| size, any window width, any form factor, the best from all
| worlds.
| hnbad wrote:
| Arguably another problem with lining up code like in the
| example is that it emphasizes the relationship between the
| keys and between the values rather than between each key-
| value pair. This may be useful when writing out matrices but
| in the example of an object/dict with key-value pairs it
| seems a distraction more than an affordance.
| andai wrote:
| This just seems like a limitation of the technology. When you
| change the width of one column, the whole table should
| realign, without any changes to those parts of the file (it's
| just about how it's displayed).
|
| I recall reading something about "tab stops" that solved this
| problem, but I don't think there are any mainstream
| implementations of it.
| Rafert wrote:
| Tab stops are called out in the footnotes:
|
| > Never attempt to line up text by using spaces. The only
| exception is if you are using a monospaced font. But in
| word processing applications, there are appropriate tools
| available for lining up text, like tables[1] and tab
| stops[2].
|
| [1]: https://practicaltypography.com/tables.html [2]:
| https://practicaltypography.com/tabs-and-tab-stops.html
| archseer wrote:
| I think you mean elastic tab stops
| https://nickgravgaard.com/elastic-tabstops/
| operator-name wrote:
| Elastic tabstops actually mentions the input font in its
| "see also" section!
| throwaway290 wrote:
| Writing programs by manipulating text is the actual
| limitation of the technology here, alignment is just a
| minor detail by comparison.
| throw827474737 wrote:
| That's often heard, but what's the alternative? So far
| every other alternative has been more limiting, not?
| throwaway290 wrote:
| AST, GUI... The technology is not there yet.
| eru wrote:
| There are some sane alternatives.
|
| You can keep to mostly text, but give the editor more
| leeway in how to lay it out and make the code's structure
| more visible.
|
| Some really simple options, that you might not even
| recognise as going beyond text: folding of block and go-
| to-definition.
| mmis1000 wrote:
| tab stops is still available in terminals. Tab in terminal
| move the cursor to next x*8(depends on setting) position
| independent of what character you input before.
|
| But a major flaw is that it only works when your cell has
| less than 8 characters. Or it will go to the wrong stop.
| Which isn't that common today.
|
| Because why insist in short names and 80 width character
| limit? Almost everyone have a screen that can fit hundreds
| of characters per line today.
| eru wrote:
| > Because why insist in short names and 80 width
| character limit? Almost everyone have a screen that can
| fit hundreds of characters per line today.
|
| Yet, books don't work that way, even though we have the
| technology. Long lines aren't readable. There's a reason
| newspapers have columns.
|
| See eg https://baymard.com/blog/line-length-readability
| and https://en.wikipedia.org/wiki/Line_length
| mmis1000 wrote:
| Even without the line length problem, 8 character is
| unlikely to fit in a meaningful word. And because you
| need a space between each column, you actually only have
| 7. And nobody using random abbreviations now.
| thaumasiotes wrote:
| > I long ago concluded that trying to line stuff up in
| columns like this in code is a mistake. It often results in
| realignment of blocks for small changes so what should be a
| small diff in the git history ends up being big.
|
| Seems wrongheaded to me; that's the same reason Elm wanted
| you to write arrays like this: [item1
| ,item2 ,item3 ,item4 ]
|
| instead of a sane way. It means adding or removing an element
| only changes one line in the diff!
|
| Who cares? It's not hard to understand what's happening in a
| diff that makes this kind of change. You want the code to be
| easy to read, not easy to diff.
|
| You could also easily base your diff algorithm on a lexer for
| the language rather than a lexer for ascii, in which case
| changing the amount of whitespace would register as "not a
| change".
| mikojan wrote:
| This looks bad. Haskell is much better: [
| item1 , item2 , item3 , item4 ]
| thaumasiotes wrote:
| Compare lisp: (item1 item2
| item3 item4)
|
| ;p
| madsohm wrote:
| Many languages also support a comma after the last item,
| meaning you can still have one line diffs and have a sane
| reading structure: [ item1,
| item2, item3, item4, ]
| vore wrote:
| Leading comma is better at resolving textual 3-way merges,
| e.g.: [ a [ a [ a , b
| , b / , b , c --> , c / , c , d
| , d / , dd ] , e ]
| ]
|
| Your usual 3 way merge algorithm will correctly deduce:
| [ a , b , c , dd , e ]
|
| Contrast this with trailing comma: [ a,
| [ a, [ a, b, b, / b,
| c, --> c, / c, d d, /
| dd ] e ] ]
|
| You now have a merge conflict between "d," and "dd".
|
| However, if you were to require a trailing comma after the
| final element you wouldn't have this problem.
| [deleted]
| Izkata wrote:
| > Contrast this with trailing comma:
|
| Example doesn't have a trailing comma. If it did, it
| would act the same as the leading comma.
|
| But also the leading comma just moves the problem to the
| beginning of the list instead of the end. Trailing comma
| with the opening [ on its own line wouldn't have that
| problem anywhere.
| crispyambulance wrote:
| > ... trying to line stuff up in columns like this in code is
| a mistake.
|
| I've encountered this sentiment more than a few times and I
| find it hard to accept. It totally makes sense to align
| repetitive stuff in columns. That's why people use tables in
| other contexts, and code should be no different. This
| alignment makes clear any deviations from the norm and lets
| you "see" the structure of the data easily.
|
| It doesn't matter for minor stuff and, usually, the code
| linter/formatter is "good enough"-- but sometimes, you REALLY
| want to have columnar layout!
| rocqua wrote:
| The value of alignment (at least for me) is not in making the
| text of the code more readable. Instead, the value is
| communicating the structure of the code.
|
| Seeing the same shape repeatedly tells me a lot about what is
| happening. It also helps highlight changes between two lines
| that are very similar.
| galaxyLogic wrote:
| > the value is communicating the structure of the code.
|
| I agree and I think that is the same thing as code-
| readability. Code-readability means you can easily
| understand the code.
|
| I personally try to abide by what I call "hedge" formatting
| convention, the punctuation forms a vertical hedge which
| then shows the structure of your code clearly:
|
| [ a
|
| , b
|
| , c
|
| ]
|
| Moving my eyes down to look for the closing bracket is
| easier (to me) than moving my eyes from left to right to
| spot it somewhere on the right side of the page.
|
| Note how above ALL the punctuation is in the same (first)
| column, Having read that it then becomes easier to read
| what is on the rest of the columns.
|
| In general it helps when things that are the same, or have
| the same purpose, on each line are in the same horizontal
| position. It is is then easier to see what is different
| about each line, since it is easy to see what is the same.
| the_sleaze9 wrote:
| Thanks, I hate it.
|
| But as long as everything is written under the same
| guidelines, I will accept it.
| hoseja wrote:
| Yes, this is what I've also gravitated towards.
| q7xvh97o2pDhNrh wrote:
| Huh, I've always wondered about this style of code
| formatting and never fully understood why people did it.
|
| Your explanation makes good sense. I guess I just wasn't
| seeing the forest for the trees. ;)
| rrwo wrote:
| Typewriters and dot matrix printers were monospace. It had
| nothing to do with lining code up.
|
| When I attended university in the mid-1990s, and again in
| mid-2000s, we were required to hand in papers using monospace
| font, black ink, with a specific point size and margins.
|
| It kept everything looking consistent with typewriters (which
| some people still used through the 1990s), but also kept people
| from using distracting or illegible fonts, or trying to work
| around page or word limits by using different fonts.
| blakewatson wrote:
| Yeah, you're right. You lose columnar alignment but beginning
| indentation still aligns and, in Input Sans, I believe the
| numbers are tabular. David Jonathan Ross makes this argument in
| the explainer for Input:
|
| > Sometimes programmers rely on the monospaced grid to create a
| second column of values or comments on the right side of the
| page. It's true, these secondary columns won't align in a
| proportionally spaced font. But why are we making these columns
| in the first place? Even in a monospaced font they can be
| finnicky and hard to maintain.
|
| > In virtually every other form of typography, the
| responsibility of alignment is given to the typesetting
| application, not the font. If source code editors can highlight
| syntax, they could also interpret tabs and syntax to create
| true, adjustable columns of text.
|
| https://input.djr.com/info/
| bsimpson wrote:
| I still can't believe personalization isn't more widespread
| in coding. For instance, it ought to be reasonably trivial to
| set up your formatting preferences in your editor, but have
| the file saved to disk be in a common format.
|
| You want 8-space tabs and braces on their own lines? Cool.
| We'll save the file with all the formatting defaults, but run
| a formatter tuned to your preferences before displaying.
| kevin_thibedeau wrote:
| This invariably leads to fucked up diffs and useless
| blaming. In theory tabs are superior as a way to provide
| configurable layout but as soon as you have to collaborate
| between users with different tooling you end up in a mixed
| whitespace hellscape.
| Beltalowda wrote:
| Accurate reporting of the error positions is one reason
| this is a non-trivial thing to implement. It's a fixable
| problem, just takes quite a bit of tooling and complexity
| for a good experience, and all things considered: is it
| really worth it?
| throwaway27727 wrote:
| Ask and receive:
| https://blog.jetbrains.com/idea/2022/11/intellij-
| idea-2022-3...
| coldpie wrote:
| IMO, the fact that personalization isn't more widespread is
| good evidence that code style doesn't actually matter.
| Humans adapt. So long as it doesn't actually interfere with
| the function of writing code (eg mixed tabs & spaces;
| wildly inconsistent identifier names), your reader will get
| over it quickly after some snide comments to their friends
| on IRC, and then work on the actual work that needs doing.
| I think people spend too much thought on this topic.
| kaashif wrote:
| Here's my reason: if what I see on screen doesn't match the
| code actually being committed, that freaks me out.
|
| Same reason I don't like using those things where <= turns
| into <= in your editor but it's written to disk as <=.
| somethingsaid wrote:
| Similarly, for some languages the meaning of what is
| written can change based on the indentation and line
| breaks. Or a statement written under one formatting
| standard can become significantly harder to read under a
| different formatting standard.
| bsimpson wrote:
| There are plenty of automated formatters - clang-format,
| prettier, gofmt, black. You would delegate to one of
| them, configurable in the project/editor, and adjustable
| by file extension.
|
| If the code doesn't parse, save it as-is. If it does, run
| the formatter with the defaults before saving. When
| opening, run the formatter with the user's preferences
| before displaying.
|
| Gets you the benefits of a formatter, with the freedom to
| control your environment to your tastes. You can already
| pick your editor, font, and color theme. You ought to be
| able to pick your formatter settings too.
| lelanthran wrote:
| With non-monospaced fonts, it doesn't matter how many or how
| few leading spaces you insert, the columns may never line up,
| and your IDE can't determine them automatically.
|
| With monospaced fonts, the columns will be guaranteed to line
| up with the correct number of spaces, which your IDE will
| determine anyway.
| rob74 wrote:
| Yeah, that's why I'm skeptical about these "almost monospaced"
| fonts too. In my opinion, the actual problem is _sans serif_
| monospaced fonts: there _most_ of the glyphs are sans serif,
| but then the designers are forced to add serifs only to the
| narrow glyphs to fill up the available space, so these end up
| sticking out like sore thumbs. So monospaced fonts that have
| serifs on all glyphs look much better IMHO.
| jen20 wrote:
| This "feature" of lined up values annoys the hell of me when
| using Go (in particular) and also seems prevalent in Ruby-
| derived things. IMO unless you pinstripe line backgrounds, it
| makes it harder to trace which value maps to which key in the
| presence of a single longer key name. It also leads to noisier
| diffs.
| Cthulhu_ wrote:
| You know, now you mention it, I thought about this and realized
| I mainly want items to START on the same column, after that I
| don't care; only exception is tables in markdown, but those are
| few and far between.
|
| I might give these fonts a try, although I've been used to
| Menlo for a long time.
| WithinReason wrote:
| I wonder if it would be possible to create a font that is not
| monospaced for letters but it's monospaced for words, so if
| you have a word + white space the end of the white space is
| the same as it would be with a monospace font. Alternatively,
| one could write "alignment characters" like & if one wanted
| to align lines like in LaTeX formulas.
| IshKebab wrote:
| From the article:
|
| > You might be thinking, "Okay, but now characters won't line
| up neatly."
| jamesfisher wrote:
| I agree "almost" defeats the point, and that columnar alignment
| is not very valuable, and so there's actually a stronger
| argument to be made: we should just use normal fonts for
| coding. What's wrong with, say, Helvetica?
| scythe wrote:
| If you drop the awkward "3/4" width and just have 0.5, 1, 1.5
| char widths, then you could recover alignment by using U+2009
| as the half-width space, maybe entered as Shift+space.
| lucideer wrote:
| Another benefit of monospaced fonts is ease of calculation of
| text-container width: any line x character count will always be
| the same length as any other.
|
| The main use of this in practice is using line-char-count
| limits as a proxy to lint for code readability, but it can also
| be beneficial in other contexts.
| karmakaze wrote:
| If spaces had half-width, then the Duo could still use spaces
| for alignment, though monospaced text would need to be run
| through a filter.
| joshjb17 wrote:
| Two big reasons for continuing to use monospaced fonts in
| programming:
|
| 1) Support for vim navigation, where hjkl move you one character
| in a direction on an evenly spaced grid. Remove that uniform
| spacing and up ceases to be "up"
|
| 2) Legibility for formatted comments and ASCII art (could argue
| these should be avoided but I've seen some magical ASCII art in
| code)
|
| ////////////////
|
| // My Comment //
|
| ////////////////
| WastingMyTime89 wrote:
| I both use vim movement and a proportional font for coding.
|
| 1/ That's already broken by line wrapping. _gj_ is the command
| moving up in the grid not _j_. The fact you are confusing the
| two should tell you how little of a difference some sideway
| movement makes.
|
| 2/ Don't use ASCII art in code. It's annoying for people not
| using monospaced font and I'm not alone.
| adrusi wrote:
| Many people map j/k to gj/gk and forget that's not the
| default behavior.
| joshjb17 wrote:
| Interesting, wasn't aware of gj. I've always worked in code
| bases where a 120 or less character width is imposed,
| removing the possibility of line wrapping. TIL, mapping j to
| gj sounds like a good move.
| raydiatian wrote:
| > Almost monospaced: the perfect fonts for writing
|
| The article doesn't use the font it is extolling the virtues of,
| except for illustration. I found that interesting.
|
| Also, there is something that gets under my skin about using
| anything other than monospaced to write code, as was one of the
| demo's. I would genuinely be fine with writing code in a
| monospaced Arial or Times, but even courier-semispaced makes me
| shiver inexplicably.
| blakewatson wrote:
| > The article doesn't use the font it is extolling the virtues
| of, except for illustration. I found that interesting.
|
| I do use them for writing and coding.
| raydiatian wrote:
| Don't misread what I am saying: I am not judging you for
| finding something that works for you, or attacking you for
| sharing.
|
| I'm bummed out to see an article about "a perfect font",
| especially being a monospaced one (or nearly), but that does
| not use said font throughout. I was sort of hoping to be
| immersed in this font for awhile, but wasn't.
|
| I use fira+ligatures. I am a monospacer too.
| DavidAdams wrote:
| I think the point of the article is that monospaced fonts,
| or near-monospaced, are good for production (writing),
| though arguably proportional fonts are better for
| consumption (reading).
| raydiatian wrote:
| I must be misunderstanding your meaning, what forms of
| writing don't also require reading in the form of
| rereading?
| blakewatson wrote:
| Yeah this is my anecdotal take. Haven't looked at studies
| on this, if they exist, but in my experience, reading
| monospaced fonts for several paragraphs is tiring.
| ComputerGuru wrote:
| See also: a little bit pregnant, almost alive, and close but no
| cigar.
|
| Yes, I read the article to the end. No, I don't get it. Either
| they line up or they don't. Either it's monospace or it's not.
| vehemenz wrote:
| Within the fonts that aren't monospace, some fonts have less
| variation in glyph width than others. It's a spectrum. You can
| choose a font that is mostly monospace, but not completely, to
| confer benefits for readability.
|
| If all you're saying is that you personally don't care to make
| a finer distinction than monospace/proportional, that's fine,
| but it's probably not worth commenting on either.
| CPUTranslator wrote:
| I've thought about ideal fonts for both writing/reading and
| programming quite a bit, and have been let down at the choices
| out there. It seems most popular monospace fonts (Fira Code,
| Iosevka, Ubuntu Mono, etc) attempt to either fit as many
| characters on the screen as possible, or are so wide, that larger
| sizes make it impossible to fit even a function on screen; both
| design choices hurt overall readability and end up forcing me to
| fiddle with line spacing, sizing, and custom font versions just
| to be somewhat happy. At this point I've just stuck to putting
| consolas on virtually every machine I use, but that's also not
| great.
|
| I really hope some font foundry out there focuses on designing
| something specifically for readability of large bodies of
| monospace/duospace text.
|
| It'd also be nice to have a provable metric for readability,
| rather than the anecdotal evidence I tend to see, but I suspect
| this is hard in and of itself.
| flobosg wrote:
| A while ago, while repurposing an old laptop into a distraction-
| free "typewriter" I researched fonts with a typewriter-like
| aesthetic. Here's what I found:
|
| Sun Gallant Demi, Solarize, Libertine/Libertinus Mono,
| Triplicate, Prestige Elite, CMU Typewriter, Latin Modern Mono,
| MingLiU, sony-misc, Verily Serif Mono, Century Schoolbook Mono
| BT, UM Typewriter, American Typewriter, Courier, Pitch,
| TiredOfCourier, Xanh Mono, DSE Typewriter, LTC Remington
| Typewriter, Bitstream Pica 10 Pitch, Italian Typewriter, Typist
| Slab, FF Elementa, EF Techno Script, Drafting* Mono, Bodoni
| Egyptian Mono.
|
| (I don't remember which one I ended up using, though.)
| fbdab103 wrote:
| >(I don't remember which one I ended up using, though.)
|
| Buried the lede on that one. Was looking forward to _the_
| recommended typewriter font.
| Multicomp wrote:
| The freeware screenwriting program trelby had some articles
| that led to one recommending the use of courier prime. I use
| it when I am working on manuscript copy, it could probably do
| okay for programming as well.
|
| https://www.1001fonts.com/courier-prime-font.html
| AlanYx wrote:
| Another one you might like is TT2020:
| https://copypaste.wtf/TT2020/docs/moreinfo2.html This one aims
| to replicate the ink characteristics of typewriters; there are
| 9 versions of each glyph that get combined via Unicode rules to
| simulate the way typewriters would inconsistently distribute
| ink.
| rgovostes wrote:
| See also: Duospaced font
| https://en.wikipedia.org/wiki/Duospaced_font
| grose wrote:
| PragmataPro is an example of such a font. Love it. It comes in
| a monospaced and duospaced variant.
| https://fsd.it/shop/fonts/pragmatapro/
| syrrim wrote:
| That article is strange. I was of the belief that most western
| "monospace" fonts were in fact "duospaced" under their
| definition. This distinction isn't apparent for normal writing,
| but such fonts usually make most emoji two chars wide. This is
| true at the very least for Adobe's "source code pro", which I
| typically use. It mentions the OP font as the only western
| example of such a font, but iA writer doesn't use integer
| multiples of the base width (necessary to qualify under their
| definition, as well as under common sense) for M and W.
| derefr wrote:
| IIRC it's not that monospaced _fonts_ have double-width
| emoji; monospaced fonts just tend to not define glyphs for
| emoji at all, and instead allow the renderer to fall back for
| rendering of those glyphs to a non-monospaced font in the
| stack. This may result in emoji taking up basically-arbitrary
| width in text edit fields, breaking the monospacing.
|
| Terminal emulators, however, have a model on which glyphs are
| always placed onto a visual grid (the PTY render-model grid,
| emulating text-mode VRAM); so in a terminal emulator that
| supports rendering Unicode at all, any glyph will have its
| visual width "snapped" to an integer multiple of the grid
| spacing, and will be considered to take up that many grid
| cells. It is up to the particular terminal emulator where it
| places the glyph within that array of grid-cells; some left-
| align glyphs, others center-align.
___________________________________________________________________
(page generated 2022-11-07 23:02 UTC)