4 ms·

I think you might be misunderstanding. The semantic line breaks described here are not shown to readers. They are visible only to the person writing/editing the

by dkh 1y ago

I think you might be misunderstanding. The semantic line breaks described here are not shown to readers. They are visible only to the person writing/editing the text, as a tool for their own use. If you aren't someone who finds a tool like this useful for your own writing, then no worries! Nobody has been harmed by this existing but not being used. It has no effect on the result. While I never knew there was a name for this, I naturally do something very similar when writing, keeping thoughts separated by at least a line or two, even if I imagine they'll be in the same paragraph in the end result, just so I have a visual sense of where my different thoughts are and how long they are.

eviks 1y ago
> are not shown to readers. Sure they are, though the spec hides some readers behind other names like "editors, and other collaborators" But also, have you never read the plain text / source of some markdown/other markup language written by someone else? Readme.md in its raw form? And the spec explicitly applies to plain text, so it's self-contradictory as "the final rendered output" of plain text is... itself.
- tolerance 1y ago
  I like your extension of the term “readers” but I don’t think that’s the intended use for this matter. And if it were, would it be safe to assume that editors and other collaborators would consent to this standard? > But also, have you never read the plain text / source of some markdown/other markup language written by someone else? Readme.md in its raw form? That’s beside the point because the spec states "A semantic line break must not alter the final rendered output of the document.” And I think you’re misinterpreting what “plain text” refers to here. Not .txt files exclusively, but the markup languages mentioned as well that are...plain text. The final rendered output of these kind of documents are not themselves. The expectation is that the source of whatever flavor of plain text is not the final output. If this practice offends you, don’t use it. This is a specification suggesting a practice for you* to use. How have you been able to manage with hard-wrapped text elsewhere?
  - eviks 1y ago
    > And if it were, would it be safe to assume that editors and other collaborators would consent to this standard? Easy no, only some of them in some instances. There is no uniformity at such a scale / variety of collaboration. > That’s beside the point because the spec states It's not, and I've addressed this in the very next semantic line! And you've also ignored the very point in your quoted line as well. Editing "Readme.md in its raw form" with the extra line breaks is still bad regardless of the final rendered output. > Not .txt files exclusively I don't need exclusivity, complementarity still works. And again, final output doesn't save you > If this practice offends you, don’t use it. If the criticism offends you, practice in the shadows and don't publish the raw misformatted specs/docs! > How have you been able to manage with hard-wrapped text elsewhere? Sometimes by batch-replacing those extra newlines in a text editor, sometiems by abandoning reading because the text reflow is too broken, sometimes just by plowing through while cursing the cavemen that force their habits onto the readers with different devices.
    - tolerance 1y ago
      Your aversion appears to be psychological. It seems to me like you have trouble examining things by the sum of their parts and semantic line breaks agitate this. You’re free to the render “misformatted” text in the format that it’s intended to be viewed. And I take it that physical literature is a burden for you to bear. My condolences.
      - necovek 1y ago
        I imagine this type of formatting caused you to sneak in a typo or two like "free to the render" — if you had it as a free-flowing sentence, it'd be easier to catch. The point is that if these formatting snippets are useful for reading, we should extend this to all the readers too. If they are not, we should be mindful not to micro-optimize lest we confuse others and ourselves.
        1y ago
pests 1y ago
I’ve always done similar. My initial writing is a disconnected jumble of sentence parts, sentences, more fleshed out paragraphs, etc just to get ideas out and they later get organized into something cohesive.
necovek 1y ago
GP brought the point up that addresses this: "why deprive readers of extra clarity offered by this formatting?" So if this is something that's valuable when reading or editing material, why not extend that to the final, rendered output? To me, this smells of micro-optimization that's not well thought through: where are the boundaries between being able to edit vs being able to read? If we make every word be on a line by itself, you can use remove-line command in your editor, and diffs will automatically become word-diffs, and it would encourage writers to limit sentences to clearer sentences by fitting them into one ~50 line/word screen. By using double newlines, you can still keep "semantic" newlines too. Wouldn't that be appealing? "No" is what I would say.

by dkh 1y ago

eviks 1y ago

> are not shown to readers. Sure they are, though the spec hides some readers behind other names like "editors, and other collaborators" But also, have you never read the plain text / source of some markdown/other markup language written by someone else? Readme.md in its raw form? And the spec explicitly applies to plain text, so it's self-contradictory as "the final rendered output" of plain text is... itself.

tolerance 1y ago
I like your extension of the term “readers” but I don’t think that’s the intended use for this matter. And if it were, would it be safe to assume that editors and other collaborators would consent to this standard? > But also, have you never read the plain text / source of some markdown/other markup language written by someone else? Readme.md in its raw form? That’s beside the point because the spec states "A semantic line break must not alter the final rendered output of the document.” And I think you’re misinterpreting what “plain text” refers to here. Not .txt files exclusively, but the markup languages mentioned as well that are...plain text. The final rendered output of these kind of documents are not themselves. The expectation is that the source of whatever flavor of plain text is not the final output. If this practice offends you, don’t use it. This is a specification suggesting a practice for you* to use. How have you been able to manage with hard-wrapped text elsewhere?
- eviks 1y ago
  > And if it were, would it be safe to assume that editors and other collaborators would consent to this standard? Easy no, only some of them in some instances. There is no uniformity at such a scale / variety of collaboration. > That’s beside the point because the spec states It's not, and I've addressed this in the very next semantic line! And you've also ignored the very point in your quoted line as well. Editing "Readme.md in its raw form" with the extra line breaks is still bad regardless of the final rendered output. > Not .txt files exclusively I don't need exclusivity, complementarity still works. And again, final output doesn't save you > If this practice offends you, don’t use it. If the criticism offends you, practice in the shadows and don't publish the raw misformatted specs/docs! > How have you been able to manage with hard-wrapped text elsewhere? Sometimes by batch-replacing those extra newlines in a text editor, sometiems by abandoning reading because the text reflow is too broken, sometimes just by plowing through while cursing the cavemen that force their habits onto the readers with different devices.
  - tolerance 1y ago
    Your aversion appears to be psychological. It seems to me like you have trouble examining things by the sum of their parts and semantic line breaks agitate this. You’re free to the render “misformatted” text in the format that it’s intended to be viewed. And I take it that physical literature is a burden for you to bear. My condolences.
    - necovek 1y ago
      I imagine this type of formatting caused you to sneak in a typo or two like "free to the render" — if you had it as a free-flowing sentence, it'd be easier to catch. The point is that if these formatting snippets are useful for reading, we should extend this to all the readers too. If they are not, we should be mindful not to micro-optimize lest we confuse others and ourselves.
      - 1y ago

pests 1y ago

I’ve always done similar. My initial writing is a disconnected jumble of sentence parts, sentences, more fleshed out paragraphs, etc just to get ideas out and they later get organized into something cohesive.

necovek 1y ago

GP brought the point up that addresses this: "why deprive readers of extra clarity offered by this formatting?" So if this is something that's valuable when reading or editing material, why not extend that to the final, rendered output? To me, this smells of micro-optimization that's not well thought through: where are the boundaries between being able to edit vs being able to read? If we make every word be on a line by itself, you can use remove-line command in your editor, and diffs will automatically become word-diffs, and it would encourage writers to limit sentences to clearer sentences by fitting them into one ~50 line/word screen. By using double newlines, you can still keep "semantic" newlines too. Wouldn't that be appealing? "No" is what I would say.