1. 39

    1. 38

      This is the silliest thing to argue about ever and I can’t even imag–

      oh right French puts a space before sentence-ending punctuation and it bugs me so much grr argh

      ahem, as I was saying, I can’t believe anyone would take the time to worry about this. :-P

      1. 11

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

        1. 5

          Only in countries that use metric punctuation though. In America, we use the imperial punctuation space which equates to about 0.254 metric tabs worth of spaces.

          1. 2

            And yet some how the British are still using Imperial tabs defined by the width of the current king/queen’s pinky finger.

      2. 9

        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 :)

        1. 6

          The rule I was taught is the space comes before and after a punctuation mark if and only if it is non-connex: ?!:;«» but not ,.()/

          1. 1

            What does non-connex mean?

            1. 1

              Sorry I meant disconnected/non-connected. It means it’s in two parts that don’t touch: https://en.wikipedia.org/wiki/Connectedness

              1. 1

                Thanks! I’ve been taught the same rule, except for the “disconnected” concept :)

        2. 2

          And that is why we have   :)

    2. 17

      Eh, when I’m composing longer text like this, I tend to write in Markdown, with a line per sentence. It’s easier to rearrange sentences, and when collaborating, git works much better, and the diffs are much easier to read.

      1. 14

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

        1. 8

          It’s a really good idea, but I have to wonder if the time you save rearranging sentences actually makes up for the extra time spent explaining semantic line breaks to contributors.

          In the end I always read these things (Semantic line breaks and the OP) and think like “yeah, I should do that!” and then I end up forgetting a few days later and going back to one space.

          1. 2

            It’s difficult, especially if you don’t have a linter that can point it out to people and enforce it.

            You don’t necessarily need to go through and change all old text. You can just migrate text to use sembr whenever you edit it.

          2. 1

            that’s why having the website’s nice 😄

            1. [Comment removed by author]

          3. 1

            I don’t save much time rearranging sentences (though I do save some) but I save a lot of time from not having merge conflicts when two people edit different sentences in the same paragraph. Telling contributors ‘one line per sentence, it will make merging easier’ doesn’t take long.

        2. 5

          SemBr appealed to me at first, but I disliked it when I tried using it. When you have short clauses, the source ends up looking weirdly like poetry (or like it’s trying to be a poem).

          1. 1

            I tend to not be that strict with sembr and tend to mostly put in a line break when I input a period or sometimes a comma, if I’ve written a long sentence.

        3. 4

          I only use SemBr with line-based markup formats, which these days is only mandoc. When writing markdown I try to make it look as much as possible like I intended the source to be the version that people read - after all that was the point of markdown, and it fits my habits from learning usenet netiquette at an impressionable age.

        4. 4

          I use that too when I’m writing manual pages — the roff(7) syntax assumes that intraline periods are for abbreviations so it won’t split the line at them. It’s a very convenient convention, I just find it distracting to read my own text with the linebreaks.

          Anything else, I two space and get the benefits of greater readability and vim/emacs/fmt/etc compatibility.

        5. 2

          I don’t care if document authors use semantic line breaks “behind the scenes,” but when they escape into the rendered version—i.e., when the user-visible paragraphs have line breaks in the middle of them—they are distractingly unprofessional-looking.

          This tends to be especially common on Stack Exchange sites, for some reason; maybe their Markdown parser renders intra-paragraph line breaks as real line breaks.

          1. 2

            Funnily enough, many markdown generators consider two spaces at the end of a line as a line break. I typed enter once before this sentence, but it’s not in a new paragraph. It obeyed semantic line breaks. But now I’ll type two spaces after this colon:
            This sentence also had only one newline before it, but the two spaces at the end of the line before it added a line break.

            1. 3

              Yeah, I think that’s a fairly widely-supported Markdown thing. Trailing whitespace is usually considered sloppy, if not an outright mistake; this is the only context I know of where trailing whitespace is actually semantically meaningful.

          2. 1

            GitHub’s markdown renderer does this too. I seem to remember hacking my markdown exporter to spit out paragraphs as a single line to get around it.

            1. 2

              Hmm? I think that’s an issue on comments in PRs, but not for Markdown files in repos.

              I’ve collaborated on a couple of books in Github repos, and the one with line-per-sentence / semantic line breaks looked as expected, while the one with paragraph-per-line had frequent merge conflicts.

              1. 1

                Oh, maybe. Comments and also the PR summary itself. (Which I tend to go to town with.) Weird that they should use different renders for Markdown files vs Markdown text in comments etc, huh?

        6. 1

          Glad to know there’s several of us weirdos. Though I always broke down my lines to be 80 characters, a sentence spanning multiple if need be. Not all editors will navigate a wrapped line every effectively.

        7. 1

          Is it though? AFAIU SemBr is not just about one line per sentence, it’s that plus adding line breaks where it makes sense.

      2. 6

        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.

        1. 2

          I knew about wdiff, but not wiggle! That’s … potentially useful? It’s hard to get a sense of it from the repo.

          1. 1

            Behind-the-scenes, wiggle works effectively by exploding all spaces to line breaks, doing a diff on that, and then stitching it back together for editing/approval/etc. This does occasionally break in fascinating ways, but it’s served me well for…what, gotta be near a decade at this point.

      3. 3

        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.

      4. 1

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

    3. 9

      Some places I worked viewed using two spaces after a period as a sign of being tech illiterate.

      1. 5

        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.

    4. 9

      I had to laugh at this little bit:

      Text editors use monospaced fonts!

      I know a guy who uses a proportional font for coding. And no, I don’t know why he likes that way.

      1. 12

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

      2. 3

        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.

      3. 3

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

      4. 1

        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.

    5. 9

      Back when it came out, this article actually convinced me to one-space because I don’t find any of the arguments for two-space compelling, but I agree with all the one-space arguments.

    6. 8

      This was much more interesting and convincing to me than the other article, thank you.

      Anyone else interested in how LaTeX handles sentence-spacing might like to check out this link. LaTeX varies the stretch (“glue”) permitted for a space based on the preceding character and has some simple (often wrong) heuristics to decide if period ends a sentence or not. Personally, I like the idea that two spaces or a line break after a period indicates a sentence-ending period. That would be easy for writers to use without requiring the kinda ugly macros that LaTeX has for explicitly defining what the space after a period should be.

      Another option would be to use smarter heuristics, but of course they would not be infallible.

      The more recent typst system appears to use a simpler algorithm with constant stretch after “words” which, now that it has been pointed out to me, I perceive as worse. Thanks typographers.

      Shame that browsers justify en-spaces and em-spaces incorrectly. Looking at the CSS standard, this is a bug because non-collapsible whitespace characters should “hang”: ref

      1. 3

        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.

        1. 2

          We’re aware of the subpar spacing compared to TeX. Layout engine improvements including but not limited to spacing are planned, but we’re a small team and some other things have higher priority right now. Feel free to open an issue about this!

          1. 1

            This is great news! I really do love everything else about Typst, sorry if I came off a bit harsh. Looking forward to it! Might open an issue so it can be used for tracking then :)

    7. 8

      Figured I’d throw my two cents in to today’s flame war.

      1. 9

        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.

      2. 1

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

        1. 1

          Thanks for the kind words. I did think it worked as its own submission, but our friendly sysop disagreed, and it’s his call in the end.

      3. 1

        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?

        1. 1

          Yeah, I made it myself with handwritten HTML/CSS in Jekyll, based mostly on inspiration from Practical Typography and qntm.org’s old blue theme.

          I’m not sure I can give any advice better than just reading Practical Typography, though if you have any specific questions I can maybe try to answer them.

          There’s also a ten-year-old article from back when I first made the theme, which is when I finally ditched my janky old blog theme. It’s slightly outdated today, for example:

          • The issues with subpixel rendering I mentioned are mostly moot these days with hi-dpi screens.
          • I’ve since made the website repository closed-source, though the source and CSS is still pretty readable and not (yet) minified if you want to take a peek.
          • Jekyll’s since gotten better at pagination, meaning I could get rid of my custom plugin.

          But it does go into some of my thought process I had building it at the time, if you think that’s valuable.

    8. 6

      I feel like this post uses the Slate article as a strawman. I would be fine with OP saying that they’ve been told “well, actually” too many times by misguided two-space evangelists (which seems to be the case). But it seems pretty clear from the Slate article that its author and intended audience are indeed the WYSIWYG users, like most of the non-techie world. Given the discussion of monospace fonts, I don’t doubt that the Slate article author would agree it is fine to use two spaces in source code. Seeing as the OP also uses single spaces for rendering text on their website, it seems like there isn’t much for them to disagree on.

      To be clear:

      I don’t object to the arguments OP uses in favor of using two spaces in source code.

      I also don’t object to taking the author of the Slate article down a peg, since I could smell their condescension through the screen.

      But I do object to thinking that the author was trying to call out people writing source code.

    9. 6

      I prefer double spaces. It always looks better. Everyone else just has bad taste :D

      When I was a child, I used to write not only ALLCAPS,BUTALSONOSPACES. I would hyphenate just about every word ending a line if it didn’t fit exactly. [1]

      The HTML “normalization” definitely smells worse-is-better, not “better”.

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

      [1] I didn’t learn until much later that the ancient Greeks did that, or something like it, but I don’t hold that up as “tradition” nonsense or “how it’s really done”

      1. 1

        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.

    10. 4

      I was hoping for a discussion about garbage collector implementation.

    11. 4

      When using Markdown or similar, sembr or gtfo.

    12. 3

      Double-spacing after full stops is an anachronism from the typewriter era, anyone doing it now is a cop 😎

    13. 3

      Two-spacing provides more semantic information, which means that software can parse and work with it more easily.

      Not sure I agree that spaces (like asterisks and underscores and so on) provide any semantic information. We certainly try to overload them with semantic ~intentions, but our success depends heavily on uniform and exclusive use.

      As soon as there are spaces or asterisks or underscores that don’t conform, we’ll have to confront the fact that we don’t actually have semantic information. This can get particularly troublesome when we need to translate between systems that independently try to overload significant whitespace with their own conflicting semantics.

    14. 3

      [two spaces] looks better in your editor.

      No it does not.

      [two spaces] gives you more power when editing and parsing.

      Surely there must already be methods for detecting where sentences start and end, especially in the age of large language models?

      1. 1

        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.

    15. 3

      Blast from the past. This is the article where I originally learned that two-spacing is even a thing. Asked a few people about it in the meantime and the verdict seems to be: Americans of a certain age use it, hardly any Europeans. (Maybe UK, not sure.)

      1. 1

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

    16. 2

      Things are changing in this area.

      APA updated it’s style guide in 2019 (for the 7th edition) to be a single space and Microsoft switched to marking it as a mistake by default in 2020.

      One thing that I never see addressed with all of this is the cost of changing. I’ve been trying to use single space, but double is so ingrained that I end up with mixed and it’s so ugly. Are there any resources that will help correct this in a web browser? CTRL-F for double space is not enough as you must jump through three actions to edit, and then go back to finding again.

    17. 2

      If you’ve got to convince me to change my age-old ways, then it’s probably going to be a no unless it’s less work for me.

    18. 2

      If you look at the source code for this blog, you might notice that all my blog posts have two spaces after every period.

      Broken link.