proposal: use hard wrapping for code and soft wrapping for prose

[ryansobol]

As a newcomer, I find hard wrapping prose to be extremely annoying and time consuming. I'm eager to hear counter arguments, but IMHO, it seems like a rule that just creates extra work for writers and reviewers.

[bnoordhuis]

Consistency > convenience. The rule in core is 80 columns, the documentation should not be an exception.

[jasonrhodes]

When you say "core", you're talking about a rule for code files, right? I've never heard of hard-wrapping paragraphs in markdown—is this already being done like this?

On Jan 9, 2016, at 8:12 AM, Ben Noordhuis [email protected] wrote:

Consistency > convenience. The rule in core is 80 columns, the documentation should not be an exception.

—
Reply to this email directly or view it on GitHub.

[bnoordhuis]

I mean the markdown files here - https://github.com/nodejs/node/tree/v5.4.0/doc/api - and those are hard-wrapped at 80 columns. You may find a few lines that are longer if you go looking but those are the exception, not the norm.

[benjamingr]

I'm +1 on this, it feels like a very arbitrary limit for doc text.

[ryansobol]

You may find a few lines that are longer if you go looking but those are the exception, not the norm.

While this is true, it demonstrates how inconsistent doc contributions are. Simply put, it's easy to forget to to apply the rule as a writer and check for it as a reviewer. Don't get me wrong, I'm in complete agreement about maintaining consistency of code contributions, no matter if they're in the core or the docs. But I argue that those same rules might not make sense with prose contributions.

[bnoordhuis]

I think most of the existing style violations date back from years ago, when reviews were much sloppier than they are today.

[chrisdickinson]

I much prefer hard wrapping at 80 since many will be editing the docs in monospace; this should be automatically checked though.

[Qard]

-1 In some cases, the place in which the content is being viewed may not provide soft-wrapping and will instead require horizontal scrolling, which is even more annoying, in my opinion.

[benjamingr]

In some cases, the place in which the content is being viewed may not provide soft-wrapping and will instead require horizontal scrolling, which is even more annoying, in my opinion.

Any example for such a place @Qard ?

[Qard]

Many command line text editors, github raw view, probably lots of other places.

[sam-github]

@Qard command line text editors don't have to wrap if its kept at 80 chars, and github raw view doesn't, either. A number of github tools in fact work quite poorly for text over 90 or a 100 chars, often you can't even see the horizontal scrollbar at the bottom as you stare at the beginning of an unwrapped line.

That's the point of hard wrapping in-source: the author does it, so that all the wide variety of tools that come after do not.

@ryansobol What editor do you use? I'm surprised it won't wrap for you.

[sam-github]

And as far as node's source goes: having one rule for markdown and one for all the others is not so handy.

[evanlucas]

Yea, I think it should be a hard limit for both code and docs for consistency. -1 from me.

[RichardLitt]

Yea, I think it should be a hard limit for both code and docs for consistency.

I agree with this. -1.

What is the procedure in place for coming to consensus on closing (or merging) this PR?

[eljefedelrodeodeljefe]

There rather is no process. This can be closed as the majority of contributors is against it.

[eljefedelrodeodeljefe]

thanks for the proposal though, Ryan.