Updated misc articles to fix up version numbers, and update text to …

[OsirisTerje]

…match latest versions of NUnit

[OsirisTerje]

@SeanKilleen Line length again.......

I can cut down one 'and', but then what?

If I cut at the words starting, which made sense to me:

So I have to cut just after the previous word.

Is this about writing text? When I write I want to write consecutively. If I add hard line breaks, and then later decide to change something in the text, the text can't be read properly in the editor being spread over multiple lines. This is like going back to the days when the wrap-lines weren't invented.

It is just extremely frustrating.

[SeanKilleen]

@manfred-brands this was something you felt passionately about. Would you like to weigh in?

[SeanKilleen]

@OsirisTerje from my perspective, though I agree it's not a choice I'd have made, it's really not a problem at all, practically speaking. I just hit the enter key to wrap the text, and the ruler helps guide me. Not a big deal.

Or, I use the built in VSCode extension that shows up if I open the repo in VSCode or a dev container and auto format it at the end.

Even as I implemented this across the entire codebase, it really wasn't a problem. So it's hard for me to understand where the frustration or time cost is coming from.

[SeanKilleen]

This shouldn't be added unless we can't adhere to the rule for some reason.

[OsirisTerje]

@SeanKilleen IIRC it was about diff tools not wrapping long lines, so one had to horizontally scroll, and it was also hard to read it. To me that sounds like a problem to be solved in the diff tool, not by enforcing changes to ordinary text. I understand it for code, but not for text.

I also use VS Code, probably have missed auto formatting there, and does it also unwrap when a line is too short ? And how is that enabled or run?

I have written on old manual typewriters long time ago, this sort of reminds me of those.

It frustrates me because I have finished writing the
text, spelling is corrected, and the
lines are shortened down to something that
was
meant
to be a paragraph. Suddenly it is harder to read as a flow of words, instead it is a flow of lines. One thing is the first writing, then comes correcting sentences, changing them, and suddenly there are breaks all over. Ok, markdown puts them together again, but the text is unreadable when editing it.
And all for the purpose of having diff more easy??

Also, we have the issue with links, the release notes PR, which also was blocked because of line lengths, so one must be very careful with long links too it seems.

Sorry, but this rule just triggers my insanity check...... Sorry, sorry....

Yes, I gave up correcting the lines, I did it in one file, but on the others I just added the suppression. If your VS Code autocorrects them, feel free to do so. But it would be nice not to have to ask you to do stuff like this... I feel bad about that too.

[SeanKilleen]

@OsirisTerje if it's frustrating for you but not for me, I (truly!) don't mind doing it. :) much like it was a problem for @manfred-brands to not have it so I tried to accommodate him as well. I'm just doing my best to remove roadblocks. If the formatting is a roadblock I'm happy to have you turn it over to me to do it.

I don't remember the exact VS Code command but if you type "wrap" I believe it will come up. I'll add a task to document this well in the README.

[OsirisTerje]

I looked up more on MD013. There are discussion on this, and the main point for readability is what they call Semantic Line Breaks.
This talks about having sentences on separate lines.
That makes more sense to me, than having arbitrary configured line lengths enforcing breaks in the sentences.
A good issue is in markdownlint repo #502, the reporter there express much better than me what is the reason for setting MD013 off, and replacing it with a sentence rule.

That issue is taken further in issue #298 which is still open, but there is a PR there which seems to have been merged.

That means there are multiple modes for this:

Modes:

space - First space past 80 chars. Current default. Plan to deprecate.
wrapped - 80 chars, like any other linter. aliased to strict for NodeJs compat. Maybe to be the future default.
not_wrapped - No wrapping - every para is a single line.
sentence - Must break at every sentence, and no mid-sentence breaks
semantic - Must break at every sentence, allows mid-sentence breaks.
Other options:

code_blocks - same as today, enforce on codeblocks
tables - same as today, enforce on tables
exempt_single_words - Exempt single worlds.

I am not sure this covers the #502 comments, but should do.

If the automatic formatter @SeanKilleen mentions works with this in VS Code (and he can explain where to find i, I didn't, Format document have no effect on this) it should be better than arbitrary in-sentence breaks.

[OsirisTerje]

Thank you for offering to format stuff. But what do we do with later editing text that have a lot of breaks in it ?

We could separate between formatted text and non-formatted text and then use a script to do the line breaks moving the original non-formatted text into a new formatted document. That way it would be possible to edit the original text without having it broken up into pieces. And still have formatted text passing the linter.

PS: Checked the different wrap functions, but couldn't find one that worked on a long line. Also set rewrap to auto, but no effect.

[SeanKilleen]

@OsirisTerje

I ran lint inside the dev container and then ran that command on all offending files. Linting fixed.