HN Reader

The main reason I use semantic line breaks, not explicitly mentioned in this article, is that it minimizes reformatting when editing. Only the subclause being edited is reformatted, while the rest of the paragraph remains as-is. This also minimizes the changes in line-oriented diffs.

While one could rely on automated line-wrapping instead of using hard line breaks that require reformatting, it isn’t usefully available in all environments, in particular for indented paragraphs and when having elements like ASCII art or code that shouldn’t be word-wrapped, and it makes plain-text diffs larger than necessary when whole paragraphs are on a single source line.

> Without any line breaks at all, this paragraph appears in source as a long, continuous line of text

Of course it doesn't because

> (which may be automatically wrapped at a fixed column length, depending on your editor settings):

Indeed, are you short on apps that support this ancient text formatting feature?

> Adding a line break after each sentence makes it easier to understand the shape and structure of the source text

Nope again, visually you've just wasted my devices width or overestimated my smartphone's width and I get exactly the same issue you've just complained about: a single sentence that doesn't fit.

Semantically, what you're looking for already exists and is called a paragraph. A sentence has a different meaning, which you break by line breaking after every single one. It kills the structure, not "makes it easier to understand the shape and structure of the source text" (also, bullet points exist)

PS By the way, why deprive readers of extra clarity offered by this formatting?

> We can further clarify the source text by adding a line break after the clause “with reason and conscience”. This helps to distinguish between the “and” used as a coordinating conjunction between “reason and conscience” and the “and” used as a subordinating conjunction with the clause

> A semantic line break SHOULD occur after an […] em dash (—).

I agree with this, however it means that no existing markup language supports semantic line breaks, because every last one of them just turns the break into a space—and em dashes are, in most locales, not to be surrounded by a space. Consequently, you’ll end up with a stray space if you do this.

My irritation at being unable to break after an em dash (which I want to do quite frequently) was one of the things that headed me down the path of designing my own lightweight markup language (LML), to fix this and other problems I observe with existing LMLs. I’ve been using it for all my personal writing for something like four years now (though a a fair bit has changed since then), and I expect to finally have a functioning parser before the end of this year.

One of the other fun complications of this kind of line break in source code is languages that don’t have a word divider—inserting a space at all is incorrect in them.

CSS presently just leaves such decisions UA-defined <https://drafts.csswg.org/css-text-4/#line-break-transform>:

> any remaining segment break is either transformed into a space (U+0020) or removed depending on the context before and after the break. The rules for this operation are UA-defined in this level.

My LML currently turns segment breaks into a space unless the line ends with an en or em dash, unless there’s a colon or a space before that. I haven’t got anything in place for languages with no word separator yet, but it is unusually well-suited to such languages.

I don't get it.

TBH most of the time I find markdown's collapsing of whitespace annoying - if you want a 'visual' line-break you have to add unnatural double space at the end of preceding line. And even this is renderer dependent, I don't think is part of the spec (?) so some renderers don't respect it (and IIRC GitHub comments renderer does't need it, i.e. doesn't do semantic line breaks)

Another pet hate is text editors which auto-convert double space into ". " - I find this even cropping up in IDEs now, so you try to add an end of line comment "...] # here" and it turns into "...]. # here". Awful

> are not shown to readers.

I also wonder, why conceal bits of information from readers, while they could possibly benefit of them the same way editors and writers do. Admittedly, the outcome then seem like a poetry, but … why not?

To give it a shot on that page, simple way to see these breaks it to run

    document.body.insertAdjacentHTML
    ( 'afterend'
    ,`<style>p, li { white-space: pre-line; }</style>`
    )

in devtools console. (Using `pre-wrap` instead of `pre-line` is also interesting: indents "wrapped" lines by the source code indent, what gives it even more clarity.

(By the way, HN comments also preserve line breaks in the source output, but unless revealed by some extra style, they are usually not presented on the surface.)

this seems to consider "text being read after formatting" and "text being read before formatting" as different things.

Which I guess, if you're the sole author of the text might be true.

But in my experience most text that gets rendered is also read and edited by multiple people in its source form, so why wouldn't you want to make source just as easy to read?

The article mentions the git diffing command `git diff --word-diff`, which is cool, but I find an even better version to be:

   git diff --color-words

which shows words removed in red, and words added in blue. The output produced is similar to `latexdiff` in case you're familiar.

The problem is that this makes having line breaks that are not paragraph breaks in the output much more awkward and I think those are much more important than line breaks that are only there in the source.

This is especially true for Markdown which is supposed to be a pretty rendering of conventions that were already common in text only communication so it's weird when explicitly entered line breaks are ignored in the output.

I’ve often thought this would be useful for version control and change review, since it allows diffs to be a lot less noisy. I’m imagining how much easier it would be to review a PR with significant README edits if the file was already structured with semantic line breaks.

I’ve previously had the above thought and applied it to the end of sentences, but the idea of introducing them at the level of semantic thought had not occurred to me. But if this is where we’re going I’d start to wish for indentation possibilities. I’ve do this frequently with SQL statements, introducing both line breaks and indentations to provide a visual structure that mimics the semantic structure of clauses and the details they contain.

This seems related to "ventilated prose", as invented by Buckminster Fuller: https://vanemden.wordpress.com/2009/01/01/ventilated-prose/

I can confirm that while this technique feels odd at first, it does prove very useful when you need to edit or shorten a "wall of text", or express something very concisely. Somehow, the relevant/irrelevant parts of a sentence or thought stand out better this way.

IIRC, I even wrote a simple Vimscript function back in the day to join a "ventilated" secton back into a traditional, coherent sentence.

I made a command-line tool [0] powered by Transformer models that performs semantic linebreaks to breaks lines in a text file at semantic boundaries. It supports multiple file types including LaTeX, Markdown, and plain text, with automatic file type detection.

[0]: https://github.com/admk/sembr

There is a very good technical argument for NOT using "semantic" line breaks when editing markup source code, especially of the "hardwrap" variety, and that is the ability to easily diff two versions of the same document, e.g. when comparing latex git commits.

Anything that reorganises the sentence around for the sake of maintaining justification, completely destroys any meaningful diff from taking place.

And ideally your editor should support both hard and soft wrapping, so that aesthetics of wrapping shouldn't be a big issue.

And I say this as a fan of hardwrapping text.

If your editor auto reflows the text, that will conflict with this, by erasing line breaks you inserted.

This is imposing an 80-character line length limit. With a line length limit, I want an editor to reflow my text so I don't have to do the line length limit manually.

Wonder if any linters know about this convention.

i thought this was for ruby and javascript and this would be really cool.

automated formatting including newlines, would be great.

Prior art on writing line oriented prose comes from one B. Kernighan, no less! Via this blog post:

https://rhodesmill.org/brandon/2012/one-sentence-per-line/

> Start each sentence on a new line. Make lines short, and break lines at natural places, such as after commas and semicolons, rather than randomly. Since most people change documents by rewriting phrases and adding, deleting and rearranging sentences, these precautions simplify any editing you have to do later.

— Brian Kernighan, 1974