In English we put tabs after punctuation so everything lines up & readers can adjust the width for what works for them.

This is even worse, we French people put space before sentence-ending punctuations (like ?!:), except for dots where space is only after the dot. Despite being French, I think this is weird and prefer the English way :)

I do the same, it’s what is called Semantic Line Breaks which effectively makes the argument in the OP moot.

Git doesn’t work better or worse with semantic line breaks as such, but its built-in diff and merge algorithms are indeed line-based. The reason I’m making this distinction is that you can use different diff and merge algorithms per file type, which opens up using things like using word-based diffing tools (e.g. wdiff or wiggle) for Markdown/org/whatever files while keeping line-based diffs elsewhere.

When I learned LaTeX, this was recommended because it made CVS work better. I kept using it with Markdown and AsciiDoc, and Subversion and git. It significantly reduces editing conflicts, means I don’t need to reflow text, and makes moving sentences around easier.

When I got the draft of my first book back from the copy editor, entirely full of annotations telling me to move text around, I was very grateful to whichever LaTeX guide told me to do this. I’d made my life much easier.

I’ve since insisted on it in other papers and in docs for my open source projects. Usually people grumble, think it’s weird, then find it’s saved them a pile of work and start doing it elsewhere.

This works well. Brian Kernighan recommended it on page 10 of UNIX for Beginners in 1974 :)

To be fair, they may be right… the last person I knew using two spaces after a sentence didn’t know you could do double-spaced lines in Word without hitting enter twice. Every time they changed the font size, they had to reformat the document.

And they were strangely resistant to learning how to use the line-spacing feature, while continuing to reformat documents manually and complaining about how much work it was to fix the line endings…

Which is very odd because they started with DOS and used Word Perfect just fine.

Sounds like kind of person who would name their OS after the worst movie of all time.

One of my uni lecturers used to make his slides and handouts with proportional fonts on a monospaced grid. Claimed it was easier to read. It was not.

I use variable width fonts in some text modes in Emacs. (But I use fixed width fonts for code.)

I wish vim supported proportional fonts, I would be using one.

They look better, isn’t that reason enough? I think the main counterargument is if you like to align things. But I don’t find this particularly convincing.

1. I generally don’t like aligning things anyways. It makes diffs messy when you rename functions, add a new item with a longer name…
2. Most of the things that I want to line up are the same prefix, so they do with proportional fonts as well.
3. The other things that may be nice to line up are numbers, but many fonts support tabular numbers.

So none of these seem like major downsides.

This is the #1 reason I’m not using Typst…

I love everything about it, but (for me) the thing that makes TeX documents look so good, and that distinguishes them from those made in something like Word or Google Docs, is the great spacing - not just between words and sentences, but also between paragraphs.

You can see this in action if you use something like TeXmacs, since it’ll auto-reflow text as you type and uses the same spacing algorithms as TeX. You’ll notice that it justifies spacing, not just between words, but between paragraphs. This leads to all pages having essentially the same height of text, no hanging headers, and minimal page breaks inside paragraphs. IMO it just looks objectively better, and once I noticed it I couldn’t get myself to use Typst, because for me the output just looks worse…

It’s a shame, because I really like everything else about Typst. Maybe one day they’ll implement it, but given how I’ve seen zero mention of this in their issue tracker, it seems I’m the only one who actually cares about this. Oh well.

It’s weird that it’s presented as opinion without any mention of usability studies, but I think that’s indicative of a broader trend. When I read the TeX papers (20 years ago now, so forgive my fuzzy memory of exact figures) they cited studies on reading speed and comprehension in most of their typesetting decisions. These included their rule of 66 non-white space characters per line and their decision to put (I think) 1.2-space width spaces at the end of sentences. As with the line width question, there’s a range and you get different failure modes in both directions. If your spaces at the end of sentences are small, it’s easier for someone reading quickly to miss the end of the sentence[1], if your spaces are too large then it’s a jarring break for readers and gives them a subconscious clue that the ideas are not related.

All of that, of course, applies only to the typeset output, not the input. If you’re writing Markdown, LaTeX, AsciiDoc, or whatever yourself, do whatever you want. If you’re using a revision control system and collaborating with others, put one sentence on each line; you’ll thank me later.

[1] The reason for this wasn’t known at the time of the TeX papers but there were some interesting eye tracking studies 20 years later that showed that fast readers don’t actually read the words in order, they appear to scan blocks of text in bulk. They’ll often do things like get to the start of a sentence, jump to the end, scan backwards, scan forwards, then move to the next. They will then, when interviewed, be convinced that they read each word in turn, because all of that was preprocessing in their visual cortex that was no more exposed to their conscious mind than small eye movements for judging depth. Making it harder to find the end of sentences breaks this kind of pattern.

i wish this wasn’t merged as a subtopic because this article is like a refreshing drink of clean water.

While typography is the topic of the day, I wanted to add that I like your blog’s theme, especially the balance it strikes between simple and attractive. I’ve been shopping around for a new theme myself and find that most are either too busy or too spartan.

I’m guessing from the reference to Practical Typography that you made it yourself. Any advice for those of us trying to ditch our old and janky blog stylings?

Sometimes, I leave 2 blank lines in my source code, for separation. Is that so bad ?

I usually have two blank lines between functions.

Inside functions, I’ll nominally have a single blank line between major chunks. Like between a for loop and some post-loop logic. I’ll often have single line comments before each chunk. I don’t describe what the code does, it is just akin to a section title.

// left
for (i = 0; i < left_side_count; i++) {
   ...
}

// right
for (i = 0; i < right_side_count; i++) {
   ...
}

With colorization, it helps to make clear what the different chunks are doing.

I’ve been fiddling with this (trying to get the first sentence from a book) and, ad-hoc, no, it’s a nightmare[1]. I switched to using some NLP package that had a “break into sentences” method which is much more successful (but still not 100%) Be interesting to see if an LLM does better at this.

[1] Admittedly a non-zero part of this is because EPUB is a HORRIBLE format.

Yeah it’s a Yank thing. Been an internet meme since as long as I can remember.

Here’s a fixed link.