That way, diffs between commits have a fighting chance of being readable. Realistically, I think everyone reads these on GitHub or at least has access to a markdown renderer, so line width is unimportant for readability of the documents themselves.
so line width is unimportant for readability of the documents themselves.
Of course it's important! It's important to the person writing it. Everything I write in my editor is wrapped to 79 columns with appropriate line breaks.
It's 2016 you know, and editors can display text wrapped even if the underlying text isn't :).
http://rhodesmill.org/brandon/2012/one-sentence-per-line/ calls this "semantic linefeeds". The point is not to keep entire sentences unbroken, it is to avoid re-wrapping an entire paragraph when editing it (e.g. inserting a few words in the middle). To do that, break not to maximize the length of each line within the set maximum width, but break at "logical" points like between sentences, after commas, etc.
An example from this article:
...
the definition in place of it.
-The beauteous scheme is that now, if you change
-your mind about what a paragraph should look
-like, you can change the formatted output merely
-by changing the definition of ‘‘.PP’’ and
-re-running the formatter.
+The beauty of this scheme is that now, if you
+change your mind about what a paragraph should
+look like, you can change the formatted output
+merely by changing the definition of ‘‘.PP’’
+and re-running the formatter.
As a rule of thumb, for all but the most
...
...
the definition in place of it.
-The beauteous scheme is that now,
+The beauty of this scheme is that now,
if you change your mind
about what a paragraph should look like,
you can change the formatted output
merely by changing
the definition of ‘‘.PP’’
and re-running the formatter.
As a rule of thumb, for all but the most
...
I like to read the raw (on GH, this allows commenting at the same time as reading) rather than rendered text and this would make it much harder, so -1 from me.
@nrc I do too. See e.g. https://github.com/rust-lang/rfcs/pull/1133/files and https://github.com/rust-lang/rfcs/pull/1133/commits/54aa0019eea1e8f9ed1f1de94a14855c85b6b481 github raw will wrap lines, so I don't see an issue.
@aturon Ping; Is this something we might want to do? (Personally I think formatting can be left up to the person writing the RFC...)
@Centril I don't think this is worth the hassle.
@aturon I agree. Shall we (you) close / fcp close then?
Since Aaron didn't think it was worth the hassle; I'll just close this unilaterally to reduce the backlog.
If you think this was done in error, please speak up :)
FWIW I like semantic linefeeds and use them in my own writing (including RFCs), but I agree that it’s not worth making everyone to reformat their submissions.
Most helpful comment
http://rhodesmill.org/brandon/2012/one-sentence-per-line/ calls this "semantic linefeeds". The point is not to keep entire sentences unbroken, it is to avoid re-wrapping an entire paragraph when editing it (e.g. inserting a few words in the middle). To do that, break not to maximize the length of each line within the set maximum width, but break at "logical" points like between sentences, after commas, etc.
An example from this article: