The Art of Plain Text (2015)

Counterpoint from Linus Torvalds regarding wrapping text for git commit messages: [0]

> Word-wrapping is a property of the text. And the tool you use to visualize things cannot know. End result: you do word-wrapping at the only stage where you can do it, namely when writing it. Not when showing it.

> Some things should not be word-wrapped. They may be some kind of quoted text - long compiler error messages, oops reports, whatever. Things that have a certain specific format.

> The tool displaying the thing can't know. The person writing the commit message can. End result: you'd better do word-wrapping at commit time, because that's the only time you know the difference.

[0] https://github.com/torvalds/linux/pull/17#issuecomment-56611...

edit I realise there's some irony in the malformed '>' quotation notation I'm using here. The alternative would be to use a paragraph per line to force the HackerNews formatting to present each quoted line on its own line (i.e. its own paragraph) but that would leave nothing to indicate the end of each paragraph.

I know 2015 wasn’t that long ago (I’m pretty old too :) ) but it wasn’t that long ago when language support for Unicode was patchy (Go is only 12 years old and it was a big thing that supporting Unicode out of the box). Even as late as 2015 some popular desktop applications either didn’t support Unicode or didn’t default to it. MySQL only supported utf8mb4 in 2010 and it took a few years for that version to become wide spread. Plenty of servers I managed back then didn’t even have Unicode locales installed.

To be clear, even in 2015 _I_ personally would have recommended Unicode (like yourself) because it was clear that it was, and is, the future. But I can forgive some people for being cautious about it even as late as 2015 if universal comparability was their concern.

My point is, if you’re only targeting English speakers _and_ you’re primary concern is portability then ASCII isn’t wasn’t unreasonable recommendation.

>beyond suggesting that the reader (as well as the writer) is illiterate?

It's about readability and recommended copy for "digital" or "new" media. The classic forms are as valid as they have ever been. However, new media involving screens and a UX beyond handling paper in various ways has driven changes to structure that do undermine the idea of suggesting literacy problems. Not sure that implication is warranted.

A bit of a rant and example for comparison: Two sentences being a paragraph (or even one!) is similar to the single space after period mess preventing us from parsing plain text properly enough to make auto capitalization work. ie: "This vs. That." I was on board with the move, until I started seriously inputting text via mobile touch keyboard. So many things get capitalized when they shouldn't, and the single space change broke it all. Worse, when using voice dictation, there are rando capitalized words because the hinting for those gets polluted as well. This is a total mess.

-----

A bit of a rant and example for comparison:

Two sentences being a paragraph (or even one!) is similar to the single space after period mess preventing us from parsing plain text properly enough to make auto capitalization work. ie: "This vs. That."

I was on board with the move, until I started seriously inputting text via mobile touch keyboard. So many things get capitalized when they shouldn't, and the single space change broke it all.

Worse, when using voice dictation, there are rando capitalized words because the hinting for those gets polluted as well.

Total mess.

-----

I find the second example reads quicker and easier for me, and the line breaks can leave room to omit or add some words too. Having A / B tested this with various people and online for a decade or so, I am confident a significant number of people prefer more line breaks, and it's about screens and the user experience dealing with them. My own comprehension, when reading on screens of various kinds, is better too.

Tall, narrow displays strongly favor the second example, and the edit and author window provided to us here on HN is a fine example. The user may well see single lines on a wider display and or one with more resolution. The same may be true for a browser or other software full screen. But, that's not the only way things happen. Mobile often forces the tall and narrow mode, and or people running many applications on a single display may prefer to size the application display into something small freeing room for them to have more applications and the data they are displaying available to them on their primary display.

Fact is, many paragraphs do appear as that wall of text, no breaks in those scenarios. That is really the answer to your question and there is little to do with literacy in all of that.

Here's an advance on that idea, and that's line breaks in a sentence itself, sort of like code. We do see this in poetry, and stories of various kinds, but it also can be used to highlight structure, conditionals, and other complexities allowable in a single sentence out for similar readability and comprehension reasons. I first saw this kind of thing in a legal document containing a fairly large, and for legal reasons, single sentence containing a number of words normally seen in a traditional paragraph. Looks something like this:

-----

In this matter it is time to choose one an option to continue:

take the easy option and ignore how it is likely to impact many people in a negative way

, or

there is a harder way too, and perhaps it does make more sense in the longer term due to a far less significant, negative impact on fewer people

, and

in either case, we do require fritzles; namely, those things included in our special processing units we do not talk about with people external to our organization.

-----

In this matter it is time to choose one an option to continue: take the easy option and ignore how it is likely to impact many people in a negative way, or there is a harder way too, and perhaps it does make more sense in the longer term due to a far less significant, negative impact on fewer people, and in either case, we do require fritzles; namely, those things included in our special processing units we do not talk about with people external to our organization.

These two do read very differently and contain the same text.

Hey, I did not know about EasyOrg. Well done, looks great!

Welcome to the non-Emacs org family :) apologies if it was just me not noticing before!

Consider adding EasyOrg to https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Tool...

Early on, when I found HN and began to participate beyond reading, this subject came up.

"why do you write like that?"

Saw that question a few times, and probably answered it a time or two with this kind of information. I would have most likely said something about readability and style preference. Both are true today.

And there is one other subtle observation that may be germane:

There is a difference between writing in the text input window directly and doing the same thing elsewhere, then copy pasting it into the text input window. In terms of your experience, nothing changes. Some rando and ideally, normie, or not nefarious at a minimum, person on the Internet input some text for you to potentially read.

On the writers end, and for me in particular, it's subtle but using the window directly seems more immediate, live, raw. Essentially, it feels a bit more like writing to you, even though it's really a public discussion where any passersby can and do read and optionally participate. Technically, it is all the same. Request input session or use one provided in advance, type on keyboard, use various controls to finalize and communicate the input, done, next.

Context really does seem to matter.

A similar thing happens when I fire up a very old computer. Sometimes I will choose to write on my old Apple //e and a bit different voice comes out, sometimes notably. That machine comes with decades of context, memories, it's own lean UX, monospaced font, keyboard very different from most I use today, and in my case writing in the character display mode I prefer on that machine rather than in the general graphics mode where more font options are available.

I'm including this largely to support the idea of the strong UX differences possible today having implications very large numbers of us will not just ignore, but will also adapt to. And, of course, as a curio for those passersby who may find that all thought provoking.