The Art of Plain Text (2015)
netmeister.org
netmeister.org
Not all languages lend themselves to the ASCII character set.
and
"If you are unable to distill the concepts or thoughts into language, then you have likely not fully understood the problem."
Oh, that must be why IC datasheets have those pesky timing diagrams and pinouts, the designers didn't fully understand the problem.
It is strange to see the author put so much weight on readability and comprehension in one paragraph, and then a few later, suggest that we chose deliberately NOT to use the right symbols (letters, mathematical notation, etc) and NOT to images to explain things that lend themselves to images.
Restraining the textual representation of English to ASCII due to imaginary technical limitations is ridiculous.
This is really hard to agree with. There are some things text just isn’t good for, like sheet music or color theory. There are also many readers and authors for whom big chunks of text are hard to digest.
> Use illustrations as supplementary, not instead of information.
If anything, the author’s argument explicitly allows meme images and emoji.
As a physicist, yes, I wouldn't necessarily disagree that it is important to be able to distil concepts into language, but the language of mathematics happens to be very poorly supported by the computer-specific idea of 'plain text'. I have had too many times in the past when sending plain text emails meant filling emails with pseudo-latex equations and hoping that the recipients would be able to understand them, or needing to attach a PDF with the actual content. Translating the concepts entirely into a foreign language like English prose wouldn't help in understanding, it would just be ridiculous and inefficient. Similarly, if I'm showing experimental data, or any sort of graph, again, the language is not feasibly translatable into plain text. Markdown and well-formatted HTML and MathML emails with modern email clients allow me to communicate in the languages I actually need to write in, and express the concepts I actually need to express, in the forms they are most efficiently expressed in. Communications systems that support mathematics and images well are extremely useful for these other languages as well. As you point out, music has a similar problem: yes, it's probably reasonable to say that concepts should be able to expressed in language, but the language to express the concepts isn't supported by plain text.
And these different fields and languages do intersect, but that segment remains stubborn. For example, expecting all discussion of what a function in a maths library does to be entirely in plain text just to satisfy the affectations of a fanatical few would be unreasonable. Yet they do their best to impose. We see statements like these. We see services that might otherwise be useful needlessly enforce and evangelize their particular views on plain text. If anything, the fanatics become increasingly fanatical and unwilling to compromise: it becomes not just HTML and images that are decried, but any non-plaintext rendering of Markdown, or anything that isn't ASCII, or text that isn't hard-broken to 72 characters (or, in the case of this particular message, demands even on the particular style of English). It becomes not just a preference, but that non-plaintext messages should be attacked, or their authors aggressively educated on proper communication and etiquette, or non-plaintext messages be rejected entirely. I prefer chalkboards to whiteboards, but I am not going to storm out of a talk as soon as the speaker picks up a dry erase marker. Non intret Cato...
The rest of the world moves on, of course, and that segment likely wonder why they are disliked.
What if I speak Chinese?
I agree with most of this article but, as a Spanish, German and Italian speaker, you can bet I'll refuse to write in an unnecessarily crippled and incorrect version of these languages; I'm very grateful for Unicode.
However, I also think that contexts such as system log messages should be in English.
If you want an easy international language, that's why we (humans) invented many years ago the concept of international auxiliary languages, Esperanto as the oldest/most known but various others exists. That's the SOLE way to have their own mother language and a secondary language for "any nation" that does not give advantages to any nation (so far English is the global language just because they were the winner of the last big world war, before was French etc) and so can be accepted by anyone.
Remember the principle of communicating vessels, no matter the present global situation, if it's not egalitarian than sooner or later will be weaponized and things change. If really neutral and useful it might survive. The Swiss choose Latin as a symbolical neutral language, we might do something better for something less symbolic but much more important in practice...
1. Works with everyone’s language. Which ASCII does not
2. Works on pretty much every machine. Which ASCII does very well.
I’m not defending the use of pure ASCII but if you’re concern is that the text is rendered universally then ASCII wasn’t the worst suggestion a few years back.
What you’re arguing is a different requirement and that’s support for peoples languages. If that’s a concern then ASCII isn’t the right choice.
Those two requirements are not mutually inclusive.
If the article had been written 20 years before it actually was, maybe. You're making me feel old here, 2015 really was not very long ago and little of relevance to this discussion has changed between then and now.
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.
I speak Greek but all my notes, text, etc are in English, which also helps if i want to share them at some point with others.
Of course, it very much depends on the context - technical documents may not need images as much as a travelling blog would. That's why it's important to use plain text as necessary, rather than always. The same applies to any format, including images and even videos. It's about balancing the usage of different formats, plain text included.
With this in mind, it's certainly recommended to start with plain text, but if plain text doesn't cut it, it's much more practical (and beneficial for the information) to just add an image. Ideally, one should always diversify how they store and present a piece of information, if they can afford to do so.
There is a tragic irony in sacrificing the potential fidelity of information in hopes of making it universally accessible.
I built two org-powered apps for iOS myself:
There are other great ones out there:
Shoutout to Karl Voit who's been driving org markup awareness outside of Emacs with Orgdown https://gitlab.com/publicvoit/orgdown. He's also discussed org markup's strengths at https://karl-voit.at/2017/09/23/orgmode-as-markup-only
I could see users using EasyOrg in combination with BrainTool in the same manner as currently works with LogSeq[0]. How would you compare the two?
https://braintool.org/2022/01/28/Browser-based-Productivity-...
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...
Not to diminish a great point, but there is no shame in a simple table or diagram, either.
Indeed, given the ambiguities of written language, doubling down on an important point with a graphic or chart reinforces that point and can help broaden the audience.
> If you are unable to distill the concepts or thoughts into language, then you have likely not fully understood the problem.
Or maybe I have understood it, and I believe that a diagram would help my reader understand it too.
This definitely depends on the situation. Whenever we do QA tests, it's much more effective to just take a screenshot or video of the problem rather than wasting time trying to explain it in text.
As a developer, I find video repros to be particularly bad, since there's a lot of irrelevant stuff in the video that you have to skip over to get to the actual issue. If I get a ticket with a video repro, I always end up having to add a textual description for future reference (and to make life easier for other people who have to handle the ticket). By creating a video repro, you may be saving time for yourself, but wasting time for everyone else who has to understand what the issue is.
Seven years ago? I would have felt the same way but the arguments against it would have been persuasive. Now? No, please allow the entire planet to use their native languages, using the One True Encoding, utf-8.
There are also circumstances where a prose line width of 78 is appropriate, we're not all contributing to email chains and a single level of quote-indentation is probably fine.
[1]: https://www.rockpapershotgun.com/remember-how-great-ascii-ar...
> 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.
In the contexts where it matters, the display software can mark each linebreak it inserts with a special symbol that's not found in plain text (possible even in terminal apps, e.g. by using inverted color) to indicate it wasn't found in the original text. Unlike pre-formatting text, this does not lose information.
Take it as an unintended complement: if all they can find wrong is little niggles then you core idea must be good & interesting.
> End your lines at between 60 and 75 characters, or so. (There's a reason[3] that newspapers and magazines do not use the whole width of their page and instead create much shorter columns.)
The author forgot that the reason is that newspapers and magazines control the medium on which their text will be read, and know how wide the reader's page is.
There's nothing more annoying in the programmer's world than the assumption that the reader will prefer to read prose in monospaced font, in an area that's 80 characters wide.
view-source:https://www.netmeister.org/blog/the-art-of-plain-text.html
[1] https://daringfireball.net
[2] https://daringfireball.net/2022/02/on_the_origin_of_the_ipho...
> Wrapping everything in a pre block isn't necessary.
I'm not saying it has to be all or nothing... but I don't see the point in not wrapping in a pre block or equivalent, having a mix is fine, i.e using an anchor or some <b> and <i> tags if you want sure, but if you are going to insert a bunch of LFs in there anyway for your column width, why not also use them for paragraphs separation, it just seems odd to me to use <p> instead and to clutter the source.
You can have HTML inside pre, and you can have as much or little as you want.
No one ever seems to acknowledge that plain text is the easiest to convert to any other format, while that is generally not the case for other formats. Maybe this is what is meant by "lowest common denominator". Perhaps a term like "most interchangeable format" would put plain text in a better light.
I heard that a lot, but I feel like there are some very narrow assumptions involved. Could you give me some examples so I can better understand what people even mean by that? I am not even sure which other formats people think about in that context.
PDF by a mile. Copy / paste is usually an option, but not always. Sometimes I see embedded font tricks to prevent this. The copy goes well, but the paste is garbage due to the glyphs being indexed differently in the embedded font. For anything more than a trivial copy paste, the pasted text will include various extras that require some additional massage before the whole thing could be considered plain text.
Text contained in images. Early in computing I had a neighbor who would use low bit depth bitmaps to communicate with their family living in Asia. That solved all the common encoding problems from that time nicely. Thought it was clever.
These days, scanned documents and or people using images for more control over presentation are two common sources for plain text that just isn't.
For that matter, text on paper comes up a lot too. One has to run a program on it to recognize the text optically, or just type it in again.
These cases generally happen on a GUI too. Command line may be possible, but considerable skill and experience are required to make it happen without also investing more time and effort than the task seems worth.
All that said, my two preferred "general purpose" formats are plain text, like we are using here, and simple bitmap images.
Markdown is a format that can transport via plain text and that's great, but can get in the way depending. Same goes for CSV and the like. Normally, those are high value however. It all more or less survives a trip through, say Notepad or vi.
Same goes for the bitmaps making it through something like paint and it all being useful and displayable in a human readable form on most devices.
The moment it ends up in some application, the use value in that context may go way up because more things can be done and or done more quickly. The requirement for other parties to have the same software can and often does end up being a reason to render whatever it is into these two things.
For me, it boils down to whether it's read only, reference material, or if there is a need to extract parts of it, or process any of it in some fashion.
I personally like well structured data over plain text, but plain text is preferable over extracting information from a pdf.
The problem and benefit of plaintext is that it lets the user have a lot of power, and with power comes footguns.
That said, I have 2 long term issues:
1. I've never quite found a satisfactory bulleting / indenting experience with plaintext. Markdown helps, and isn't bad. But I'm still looking for inspiration on bulleting / indenting.
2. How to intersperse the console "prompt" (e.g. >, or $, or ~), and code, and comments and commentary... such that everything is easily human readable, and also code can be easily copy pasted into the console.
It also has good literate programming support so that you can run code from a plaintext file, which may also contain comments and capture the code output. I don't use this much, though. I prefer the usual model of programs split into files.
I got addicted to outliners by using OmniOutliner, which used to ship with Mac OS X Tiger, if I recall correctly. It supports rich text format, but also works great if you stick to plain text. It is still very well maintained and has a great design, just like everything from OmniGroup. I prefer Emacs, but OmniOutliner is also very nice and much friendlier. It is also very flexible and scriptable. It was very popular when GTD began to take off in the late 2000s, so bulleting and indenting are really well covered too.
However, while org-babel is feature-rich in obscure ways that I constantly discover, it's still missing some out-of-the-box convenience like automated figure management and running multiple code blocks (like running code blocks to the middle of the page - not all the way through).
I don't approach a computational problem nowadays without considering how it may be done in emacs. I'm spoiled rotten, it's an emacsystem, the utility is a learning experience.
Text is a poor approximation for understanding other people's rigour, org-mode is a communicative superpower
There’s md (of different flavours; which wasn’t even needed because the conventions md is directly copied from were already sufficient - and yes, let’s argue about it!), then there’s text bundle and there are more, propriety apps have their own plaintext.
So while there actually a plaintext - the plaintext - nobody does the plaintext.
Whenever I need plaintext I just do plaintext using “-“ and tabs+- for lists etc. In case you missed almost everything is there in plaintext - line breaks, paragraph, punctuations, special characters etc. And just too many plaintext apps as well to keep you happy.
To just use pure text for everything is extreme. To resist the use of images, absolutely, but we cannot do without.
2. Org mode in Emacs is a game changer for me. The pdf output via Latex is quite good. One thing I really used to hate was typing in beamer presentations by hand. Nowadays, I can make a org mode file super-quick and export via beamer to produce a basic PDF presentation.
Where does this so broadly embraced idea, that two sentences qualify as a ``paragraph'', come from; and is there any evidence that writing in this way achieves anything beyond suggesting that the reader (as well as the writer) is illiterate?
"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.
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.
https://www.netmeister.org/blog/debugging-certificate-errors...
Not saying that is wrong. Just maybe their views have evolved since 2015.
I thought he was making a bad joke but apparently there's all this pop science that says you're a psycho if you end your texts with a period and forget to use your exclamation marks, lols, and emojis. So if you use ASCII or UCS-2, there's no way you're not a stone cold killer. I think the idea originates from a 2012 paper https://www.onlineprivacyfoundation.org/research_/Sumner_Pre... which oddly enough doesn't mention the period or question mark at all.
> Psychopathic traits were significantly positively correlated with swear words (r(2,614) = 0.187, p = < 0.001), anger (r(2,614) = 0.151, p = < .001), death (r(2,614) = 0.094, p = < 0.001) and negative emotion (negemo) (r(2,614) = 0.084, p = < 0.001). We also saw significantly positive correlations between psychopathic traits and filler words (r(2,614) = 0.073, p = < 0.001).
Which suggests people who are foul, angry, and negative have a higher probability of being on the dark triad. However if you look at the correlations table, the dataset the researchers used suggested that psychopaths are much less likely to use exclamation marks. That's very interesting! Because I've always wondered why every corporate email since then has lots of them!
Most of us have encountered the "please enter a valid name" after filling in a form.
* https://en.wikipedia.org/wiki/List_of_Korean_surnames
And most given names are 1-2 Hangul characters:
* https://en.wikipedia.org/wiki/List_of_Korean_given_names
Why would ever need more? /s
My pet peeve is sites not accepting e-mail addresses with sub-addressing, i.e., the "tag" in foo+tag@example.com.
This is incredibly Anglo-centric and just plain wrong. It works fine as long as your colleagues are all named James, John, or Mike, but breaks down immediately once you meet a Françoise, Rémi, Cláudio, etc.
Even the IETF's RFCs, arguably the most popular plain-text documents on the internet, explicitly allows non-ASCII characters. Because the internet is global and unicode exists.