Hacker News Reader

Comment by michaelmior | Hacker News Reader

I personally use this approach but mostly because a lot of what I write ends up in a git repository and diffs make way more sense when there is only one sentence per line. I also find things much easier to manipulate in vim when sentences don't span lines.

View on HN

> diffs make way more sense when there is only one sentence per line

I did the same thing for some time for papers at university for the same reason. It used to annoy me, because I hate to change for my tools, I rather have my tools support my workflow: There should be a nicer diff for that.

You could write a script which replaces the end of sentences with a new line and use git hooks[0] to run it before every commit. You wouldn't have to write any differently.

0. https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks

This would require accurately detecting the end of the sentence which is not an easy thing to do correctly consistently.

Two spaces between sentences makes this easy, and should be just as easy a habit as one sentence per line.

That's about as unnatural for most people as newline per sentence, and has the added risk that you'll accidentally publish like that and it'll look weird. One per line would be _much_ harder to accidentally publish because it's more obvious.

Two spaces between sentences is how I've always typed them, even if it's in HTML or MD or other forms that will condense them into a single space in the final render. The two spaces mark a clear intent to end a sentence instead of a period to punctuate an abbreviation.

Many people learned to add two spaces to the end of each sentence which is now built in to their muscle memory. My father learned to type adding two spaces to the end of every sentence, they tried to teach that to me in computer class in middle school but since I had a lot of experience typing already without it I never felt motivated to change my habit to add two spaces. I never really saw the point, in most formats I can't see the two spaces.

Two spaces after each sentence comes from typewriters, where it supposedly looked better. On computers it made sense in the time of monospaced fonts, but with "modern" fonts being able to control the amount of space behind punctuation it's largely redundant.

Except for when you want to do diffs at the end of a sentence.

Good typography seems to dictate a wider space after a sentence than between words. So this is a typewriter habit to mimic that kind of thing (like the sibling noted).

Some people might prefer two spaces, but my understanding is that all authorities on “good typography” have standardized on one space:

https://practicaltypography.com/one-space-between-sentences....

Interesting. I definitely respect Butterick’s opinions on typography.

Rendering engines can do anything they want. The question is about source representation only, for semantic purposes. That has nothing to do with output representation. Even practicaltypography completely misses that distinction.

You wouldn't publish anything with line breaks between sentences either. Double spacing or line breaks both work nicely for semantic purposes because html (or markdown which almost always ends up displayed somewhere as html) will ignore it.

Any print publishing software in the 21st century should be aware that two spaces in a prose text source is a hint for a sentence break, and treat it appropriately. They often apply custom spacing (slightly more than 1, but nowhere close to 2) between sentences anyway. Without the two spaces, they have to algorithmically guess at sentences. You just won't notice when there are sentence detection errors, unless you're a typography fanatic; who's going to notice 1 space instead of 1.2 or whatever the optimum happens to be?

Maybe I'm just being slow this morning, but isn't the fullstop the indication of the end of the sentence?

What extra information is encoded by fullstop + 2 spaces?

The period also indicates the previous word was abbreviated, or can be used in an ellipsis, probably other situations that aren't top of mind right now.

GP:

> Good typography seems to dictate a wider space after a sentence than between words.

You:

> Rendering engines can do anything they want. The question is about source representation only, for semantic purposes.

The thread you’ve commented on is literally about rendering, not source representation and semantics. I agree that you can use a double-space as a sentence delimiter, but we’re currently discussing whether it’s “good typography” to render it that way.

Your reply cited Butterick which doesn't distinguish the two issues. Every "authority" I've seen strongly admonish against the use of two spaces fails to make this distinction. Which is why I emphasized it.

I don't think there's much dispute that two spaces is too much in modern properly rendered prose, so I don't know who "we" is. (And anyone who does think two word spaces is just fine, would probably also agree that it should be configurable and not dependent on two spaces in the source text.)

If there's a text renderer out there that renders two spaces as two word spaces in prose, that should be patched, not writers' brains.

Those authorities on "good typography" are wrong. They prioritize text looking pretty over text conveying information clearly and accurately, and the world is worse off because of it. Two spaces as the sentence delimiter is superior in every way that actually matters, and I will die on that hill.

Take a ruler to some text that's traditionally typeset and you'll notice that the width of the whitespace after a sentence end is slightly wider than the space between words. That's either an em space or an en quad. Between-word spacing would be about 1/2 an en.

Studies examining whether or not wider spacing between sentences improved readability have been inconclusive.

There is one good reason to use two spaces between sentences, at least for text that's going to be processed automatically. It can be very difficult for software to know whether a given punctuation mark is the end of a sentence or something else, like an abbreviation. GNU Emacs, for example, is (or was) coded to recognize sentences by looking for two spaces after a ., ?, or !.[1]

1 https://www.gnu.org/software/emacs/manual/html_node/emacs/Se...

For me it's a holdover from a high school typing class, but I find it useful. I mostly write in LaTeX which just ignores the extras. On the iphone, two spaces are replaced by a period and a space, which is quite handy.

Yeah I believe this is a generational thing. I learned double-space as well, but pretty sure not long after me they stopped teaching that, and I've totally stopped doing it.

Double spaces was the norm on (almost always monospaced font) typewriters [EDIT: in English]. I assume it lingered on computers until sometime in the 80s but was shifting especially once proportional fonts for written material (other than things like code of course) became the norm.

I couldn't tell you when I switched.

I was taught to use double spaces in highschool typing class (we used electric typewriters with the buffer off). In the ~35 years since I have only ever met a handful of people, all older than me, who did it in practice.

I continued through university while using a computer to type things up, I'm pretty sure my thesis had double spaces after periods, written in WP. Once I graduated I dropped it pretty quickly.

Was there an early version of Word's spell-check-on-the-fly that underlined double spaces, or am I miss-remembering?

>Was there an early version of Word's spell-check-on-the-fly that underlined double spaces, or am I miss-remembering?

I don't remember that and I was a fairly early user of Word going back to DOS days although I rarely use it any longer.

Apparently you could set up one or two spaces depending on your preference, however recent versions of Word now mark double spaces as an error by default.

Double spaces was the norm for English. I understand it is considered mostly obsolete nowadays.

It has not been the norm for German ever.

Edit: Related discussion: https://news.ycombinator.com/item?id=22975299

I've seen two spaces listed as a "resumé don't-do" cos it marks you as an oldster.

My résumé is in LaTeX, so they literally would never know.

I am an oldster, but never used two spaces. Probably because I never did typing lessons at school (hell I don't think it was even an option at my schools - computers hardly featured either).

I used to write like that (even though I’m not an American or a former typewriter) but pressing double space got annoying after a while. :-)

No, but NLP toolkits like opennlp already do this quite well.

Fair point, but I still prefer the solution of just putting in a new line myself. Then I don't have to worry about maintaining such a script, setting up the git hook, etc.

git diff --word-diff

There is! If you're using Git, you can do git diff --word-diff to enable word mode, which is computationally more expensive, but computing power is cheap these days. There's also an "ignore whitespace" mode (-w), though that doesn't play well with Python.

Cool! An example:

You are in a maze of twisty little passages, all different. You are in a little maze of twisty passages, all different. You are in a little maze of twisting passages, all different.

You are in a maze of twisty little passages, all different. You are in a[-little-] maze of twisty {+little+} passages, all different. You are in a[-little-] maze of [-twisting-]{+twisty little+} passages, all different.

You are in a {+little+} maze of twisty[-little-] passages, all different. You are in a little maze of twisty passages, all different. You are in a little maze of [-twisting-]{+twisty+} passages, all different.

You are in a {+little+} maze of [-twisty little-]{+twisting+} passages, all different. You are in a little maze of [-twisty-]{+twisting+} passages, all different. You are in a little maze of twisting passages, all different.

Plugh

Thank you, that's a nice feature. I hope I won't forget it until I need it again.

Vim has built-in text object for sentences. It supports sentences spanning multiple lines.

Yes, but I still find it more convenient to have sentences on their own line. Vim's sentence text object does also not always correspond correctly to actual sentences.

I mean, I’m happy that this was not a yet another sysadmin/programmer-as-writer justification (adjusting one’s whole workflow based on the handful of terminal programs that one uses).

EDIT: Meaning that I think this kind of justification is more interesting since it is meant to affect the process of writing itself.

I won't say I'm not guilty of that too sometimes. Although I don't think it's so bad. If there's a tool that you really like using that can be adapted to work in a variety of scenarios, I can understand the justification. For some of the things I do, there probably are better tools for the job, but if I can make use of existing tools I already know how to use well, even if in a suboptimal way, that might be more worthwhile to me than investing in learning something new.

Yep, indeed. Whatever works.

Exactly, I mostly write in Latex and one-sentence-per-line makes so much sense for that.

Yeah, same here. If you're going to have any text commited to git, it'll work much better if it's one sentence per line. Not that git is great for prose, but it kinda does the job and I don't need to have a new tool. Hammers, nails.

> Not that git is great for prose, but it kinda does the job and I don't need to have a new tool.

Is there really something better? Git is pretty great in general, and prose doesn't seem like there'd be much room for improvement in tooling. I'm not a writer really though, so maybe I'm missing something?

At least with a controlled circle of people who respect that, say, handing off a doc to an editor means they shouldn't make inline changes any longer, collaborative doc editing like Google Docs.

As the above implies, you don't have great version control and some of the process management is manual. But it works well for people accustomed to working that way and it's much more familiar for people who don't regularly use git (or use it at all).

Reply on news.ycombinator.com