16 ms·

It's wild to me that so many technical people, including the author, consider arbitrarily inserting \ns at a certain character length a desirable feature. Addin

It's wild to me that so many technical people, including the author, consider arbitrarily inserting \ns at a certain character length a desirable feature. Adding semantically insignificant line breaks results in a loss of information - if you break lines at 80 characters, you can't distinguish between a semantically significant line break at character 80 vs. just running out of space in the line. It also imposes the writer's preferred character width on the reader: What if I want 132 characters? What if I have poor vision and/or a small monitor and can only fit 60 in my desired font size in the desired portion of my screen? And it necessitates weird rules and/or stricter line-length restrictions to deal with stuff like quoting, e.g. as described in https://useplaintext.email https://useplaintext.email. So it sounds to me like Gemini got this one right, and if your text editor isn't smart enough to wrap lines when the input doesn't contain a literal \n you should probably find a better text editor. /rant In terms of the other limitations the author mentioned...yeah, those do seem kind of silly. I guess I don't see the advantage of a custom and even more limited format over, say, Markdown. But of course everyone has their own preferred subset of "important" features and if you just take the union of them all you'd wind up back at something close to the current feature set of the Web.

skybrian 5y ago
In the case of Markdown, the extra newlines are there so that you can write for two different kinds of readers at the same time. A text editor will show the unrendered state and a Markdown converter will take it to the rendered state. Both should be readable. So the newlines aren’t “semantically insignificant” any more than comments are in source code. Just because they’re stripped during the conversion doesn’t mean they’re meaningless in the unconverted state.
- nyanpasu64 5y ago
  > A text editor will show the unrendered state and a Markdown converter will take it to the rendered state. Both should be readable. And unwrapped markdown in a line-wrapping text editor (most text editors support soft-wrapping) is perfectly readable even without rendering.
  - skybrian 5y ago
    Sure, but there is also a long-standing tradition of making text files readable without soft-wrapping, by using line breaks where it makes sense. The style guides for many programming languages require you to put hard breaks in long lines, for example. Also, old-school mailing lists require this.
    - tfehring 5y ago
      Right, the point I was arguing in my top-level comment is that that tradition is misguided and should be done away with. Including in mailing lists and commit messages. The place where it "makes sense" to have a line break in prose is a function of the reader's desired line width, which is not only unknown to the author at the time of writing, but also varies from reader to reader. If you don't insert semantically insignificant newline characters, any modern application for reading text can soft-wrap long lines to that width. But because arbitrarily inserting newline characters destroys information, the opposite isn't true. If you add \ns to break your lines at 80 characters and I try to read your text in a 60-character-wide terminal, I'll get alternating line widths of ~60 characters and ~20 characters. And I can't just replace all the newline characters at position ~80 with spaces and re-wrap the resulting text myself, because for all I know one of those line breaks could have been semantically significant. Line breaks in code are pretty much always semantically significant to the human reader even if they're not semantically significant to the compiler because the relative vertical and horizontal alignment of non-whitespace characters is fixed and intentional. If you resize your browser window or zoom in or out so that the line wrapping in this comment occurs at different places in the text, the readability and meaning of this text is essentially unchanged. That's not generally true of code - even in languages whose compilers ignore whitespace, arbitrarily shifting, adding, and deleting line breaks doesn't preserve meaning (to humans) because programmers generally use whitespace methodically for the sake of clarity and readability.
      - nyanpasu64 5y ago
        > Line breaks in code are pretty much always semantically significant to the human reader even if they're not semantically significant to the compiler because the relative vertical and horizontal alignment of non-whitespace characters is fixed and intentional. What would be cool is a well-behaved autoformatter like Black, or perhaps gofmt or rustfmt (clang-format definitely fails since it's not even idempotent), which automatically reflows code to the width of your text editor (or even shrinks the indentation size) as you resize or split the window, and reformats it back to a standard width upon saving and committing. This requires that formatting to a different width then back to the original is a no-op, which I believe Black and rustfmt can achieve, but is harder to get right than storing the code as an AST on-disk. Also, rustfmt fails to reformat the interior of macro invocations.
gerikson 5y ago
Author here. Treating a paragraph or block as a logical unit is what I am used to. It works in Markdown, HTML, Latex, and basically every word processor. Treating a single line as a logical unit is just as valid, technically, but it imposes requirements on me, the author, to change my workflow. If I found Gemini more compelling that might be worth it, but as I'm sure you've all noticed, that is not the case.
- tfehring 5y ago
  To clarify, I don't think of it as lines vs paragraphs. The text I'm typing right now doesn't contain any newline characters, but it's still a paragraph. I think of it more as a distinction between paragraphs with line-wrapping points predefined by the writer vs. paragraphs without them. Either way I'm very underwhelmed by Gemini myself so I don't blame you in the least for not wanting to change your workflow to accommodate it.

skybrian 5y ago

In the case of Markdown, the extra newlines are there so that you can write for two different kinds of readers at the same time. A text editor will show the unrendered state and a Markdown converter will take it to the rendered state. Both should be readable. So the newlines aren’t “semantically insignificant” any more than comments are in source code. Just because they’re stripped during the conversion doesn’t mean they’re meaningless in the unconverted state.

nyanpasu64 5y ago
> A text editor will show the unrendered state and a Markdown converter will take it to the rendered state. Both should be readable. And unwrapped markdown in a line-wrapping text editor (most text editors support soft-wrapping) is perfectly readable even without rendering.
- skybrian 5y ago
  Sure, but there is also a long-standing tradition of making text files readable without soft-wrapping, by using line breaks where it makes sense. The style guides for many programming languages require you to put hard breaks in long lines, for example. Also, old-school mailing lists require this.
  - tfehring 5y ago
    Right, the point I was arguing in my top-level comment is that that tradition is misguided and should be done away with. Including in mailing lists and commit messages. The place where it "makes sense" to have a line break in prose is a function of the reader's desired line width, which is not only unknown to the author at the time of writing, but also varies from reader to reader. If you don't insert semantically insignificant newline characters, any modern application for reading text can soft-wrap long lines to that width. But because arbitrarily inserting newline characters destroys information, the opposite isn't true. If you add \ns to break your lines at 80 characters and I try to read your text in a 60-character-wide terminal, I'll get alternating line widths of ~60 characters and ~20 characters. And I can't just replace all the newline characters at position ~80 with spaces and re-wrap the resulting text myself, because for all I know one of those line breaks could have been semantically significant. Line breaks in code are pretty much always semantically significant to the human reader even if they're not semantically significant to the compiler because the relative vertical and horizontal alignment of non-whitespace characters is fixed and intentional. If you resize your browser window or zoom in or out so that the line wrapping in this comment occurs at different places in the text, the readability and meaning of this text is essentially unchanged. That's not generally true of code - even in languages whose compilers ignore whitespace, arbitrarily shifting, adding, and deleting line breaks doesn't preserve meaning (to humans) because programmers generally use whitespace methodically for the sake of clarity and readability.
    - nyanpasu64 5y ago
      > Line breaks in code are pretty much always semantically significant to the human reader even if they're not semantically significant to the compiler because the relative vertical and horizontal alignment of non-whitespace characters is fixed and intentional. What would be cool is a well-behaved autoformatter like Black, or perhaps gofmt or rustfmt (clang-format definitely fails since it's not even idempotent), which automatically reflows code to the width of your text editor (or even shrinks the indentation size) as you resize or split the window, and reformats it back to a standard width upon saving and committing. This requires that formatting to a different width then back to the original is a no-op, which I believe Black and rustfmt can achieve, but is harder to get right than storing the code as an AST on-disk. Also, rustfmt fails to reformat the interior of macro invocations.

gerikson 5y ago

Author here. Treating a paragraph or block as a logical unit is what I am used to. It works in Markdown, HTML, Latex, and basically every word processor. Treating a single line as a logical unit is just as valid, technically, but it imposes requirements on me, the author, to change my workflow. If I found Gemini more compelling that might be worth it, but as I'm sure you've all noticed, that is not the case.

tfehring 5y ago
To clarify, I don't think of it as lines vs paragraphs. The text I'm typing right now doesn't contain any newline characters, but it's still a paragraph. I think of it more as a distinction between paragraphs with line-wrapping points predefined by the writer vs. paragraphs without them. Either way I'm very underwhelmed by Gemini myself so I don't blame you in the least for not wanting to change your workflow to accommodate it.