Line Length Lint

[ozkriff]

Currently, a line-length lint is enabled and set to 80 chars. In #638 @Keavon proposed to get rid of it:

@Keavon: this be a good place to propose we get rid of the nonsensical linter requirement for a line length limit in markdown files? It's seriously quite a pain and provides no benefit.
@17cupsofcoffee: I'm not particularly attached to the line length limit (and if we do keep it, it might make sense to bump it up to 120 characters or something like that), but will see what the other maintainers think.
@Keavon: Since 120 characters is shorter than a paragraph, that wouldn't really be an improvement. Let's stick to proposing no limit.

I don't agree that the current limit is nonsensical - it's an ancient question with no universally right answer that fits for all projects. In my personal experience, lengthy versioned and collectively reviewed/edited Markdown files with no line limit were quite annoying. Also, following to semantic line wrapping seems to ease the downsides of strict line limits a lot. Lots of similar projects (the official Rust blog, Veloren blog, etc) seem to come to the same conclusion.

So I'd prefer to keep the limit (as it simplifies versioning, reviewing, and collective editing) but if there're a lot of contributors who hate it then it might be worth considering switching it off (or raising the limit to 100 or 120 chars).

What do you think?

[17cupsofcoffee]

Been thinking about this some more since the quoted comment, and I think there's two sides to this that have to be balanced.

As a section writer, I find it slightly annoying, due to the fact that GitHub's built-in editor does not (as far as I can tell) give you an indication of your line length, so I'll often go over the limit by one or two characters and have to re-edit. It's not the end of the world, but it's a little irritating.

As a section reviewer, it's kinda nice to not have an entire paragraph on a single line, because:

• When pointing out issues to contributors, it's helpful to be able to say 'this thing on line X needs changes'.
  • Similarly, the CI linter outputs stuff with line numbers, which would be less useful without text being split across lines.
• Using GitHub's review interface and making edit suggestions is a bit more painful when lines are really long/not broken up.

I still don't feel super strongly either way, and I'm happy to go with what the majority of contributors want, but just wanted to put forwards some concrete advantages I've run into while working on the newsletter.

[alice-i-cecile]

As a writer, I found this somewhat silly and frustrating. I would be in favor of bumping this up to something more moderate (e.g. 120 characters) or removing it entirely.

[AngelOnFira]

As the weekly Veloren devblog editor, I didn't actually start forcing myself to limit line length for quite a while. However, I found that I much prefer it in my workflow.

Example from Veloren, before line length, and after line length.

I do want to note, I use this plugin for VS Code which makes it trivial for me. Also, when I'm the editor, I do a rewrap pass during my final review process.

Without re-iterating what's already here, I pretty heavily agree with @17cupsofcoffee's points. It's easier to review, and to understand a general length of a section as an editor. It also creates more structured markdown in my opinion.

That being said, I do understand how this isn't very ergonomic for writers. I wouldn't mind finding some way where I could add my own commit on incoming PRs that format it; it all gets squashed anyhow so it shouldn't be that much extra bloat. That way people can write it as they like, and right before it's ready to be merged, it gets cleaned up.

[janhohenheim]

Coming in from the future while reviving the newsletter.
I'd like to keep friction for contributors as low as possible. So, while I agree with @AngelOnFira for things I write by myself, I'd like to bump the limit to 160 chars (arbitrary choice) until the newsletter is going on regularly again. Until then, I think any extra friction for contributors should be heavily scrutinized.
Is that fine for you, @AngelOnFira, @Vrixyz and @17cupsofcoffee?