The Art of Plain Text (2015)(netmeister.org)
netmeister.org
The Art of Plain Text (2015)
https://www.netmeister.org/blog/the-art-of-plain-text.html
87 comments
Even English doesn't fit in ASCII! English is often used as the justification for ASCII—by technical types anyway. To use “only plain ASCII text” would mean constraining oneself (no dashes or paired quotation marks, for example). Many English loanwords are accented (outré or soupçon) as are some personal names (Zoë). Some uses of italics are considered mandatory even beyond emphasis, such as when writing the title of a work (The Art of Plain Text).
Restraining the textual representation of English to ASCII due to imaginary technical limitations is ridiculous.
Restraining the textual representation of English to ASCII due to imaginary technical limitations is ridiculous.
In the corporate world, native or advanced English speakers who might use such loanwords may sometimes be told to knock it off and stick to using a restricted list of very basic English words, about a thousand of them. Rather than getting ESL speakers up to speed, get everybody else to use this 'LCD English'. It's all very demeaning, but if you're adhering to this you'll find that ASCII has you covered.
What if you want to write the name of an ESL speaker, who might well come from a country where names often don't only consist of ASCII characters? Or do they tell you to knock that off too?
Don't get me wrong, I'm not defending this "ASCII is good enough" mentality. But in the sort of environment where management is telling people not to write words like 'naïve', it's likely that somebody named Jìng is going by 'Jing' or 'John' in the office, if for no other reason than because their boss can't be bothered to figure out how to type ì without copy-pasting it. This has been my experience anyway. This sort of corporate international accessibility seems to expect concessions from everybody.
> Resist the temptation to use images. If you are unable to distill the concepts or thoughts into language, then you have likely not fully understood the problem.
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.
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.
I think the idea is Uti, non abuti (use, but don't abuse). Counter-counter (sic) examples are not-so-funny meme pictures and emojis. Emojis have gotten so ridiculous in terms of illusion of communication that we have entire websites about their supposed meaning [1].
[1] https://emojitips.com/emoji-meanings/
[1] https://emojitips.com/emoji-meanings/
I don’t believe that is what the author is saying:
> Use illustrations as supplementary, not instead of information.
If anything, the author’s argument explicitly allows meme images and emoji.
> Use illustrations as supplementary, not instead of information.
If anything, the author’s argument explicitly allows meme images and emoji.
A picture is worth a thousand words and all that. I guess we need more schematics and images to communicate disambiguously. What if you are writing 1000 words of plain text to explain a workflow but has zero images? That is just bending backwards to fit in with the plain text rule
I agree with you, that claim also gave me pause. And image can be worth more than a thousand words; taking that proverb at face value, it's hard to argue that you should spend the thousand words when an image would convey the same information much more efficiently.
There is an enormously frustrating segment of the software development community who seemingly refuse to imagine that there might be others with different language and communication needs than their own, and their particular formulation of plain text may be particularly unsuitable for those needs.
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.
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.
... or teaching people to cut hair.
>Use only plain ASCII text. You don't know how the text will be processed or what systems will be used to display it. The lowest common denominator -- i.e. ASCII -- will do just fine. Use a simple text editor.
What if I speak Chinese?
What if I speak Chinese?
The age of the article should be taken into consideration here because back then Unicode support was still patchy in places. Not saying I agree with their statement though because even in 2015 it was obvious Unicode was here to stay. But I can at least understand their sentiment. If that were written now I’d wager it would say Unicode rather than ASCII. Or at least I’d really hope it would.
I disagree. Even in 2015, pretending ASCII was a workable universal format involved either pretending non-occidental languages didn't exist, or, as I darkly suspect is the case with many US-based computer scientists, forgetting their existence entirely.
“Universal” has two meaning here:
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.
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.
> The age of the article should be taken into consideration here because back then Unicode support was still patchy in places
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.
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.
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.
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.
The way I interpreted it was, “if ASCII will suffice, then use that.” In other words, use --- instead of —, " instead of “/”, and so forth. If you’re writing in a different language then obviously (at least to me) this advice doesn’t apply.
Quite so. Much of what the article says is interesting, but nowadays, I'd say using UTF-8 would be more reasonable.
Assuming you know the language (otherwise you wouldn't be able to read the article :-P) you can still write in English.
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.
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.
Or even languages that use the Latin alphabet, but with various accent marks, such as German, French, Spanish, etc.
These languages have developed ways to cope because of SMS.
German somewhat has (e.g., you write "ue" instead of "ü", "ss" for "ß", as in "suess"), but Spanish certainly hasn't. Saying that Spanish can be written in us-ascii is about the same as saying that English could cope if you removed the h and the y — it would still be understandable, right? Us-ascii Spanish "?d'onde est'a la biblioteca?" is as pleasant as, uh, "w^ere is t^e librarv?"
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.
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.
The work arounds in German exist, but they are rarely used and look extremely inelegant. Even before smartphones with virtual keyboards became common many people preferred to press a few extra keys in their SMS to get the correct Umlaut than to write ue, ae, oe, ..
Don't get me wrong, I think these languages shouldn't be crippled too.
However, I also think that contexts such as system log messages should be in English.
However, I also think that contexts such as system log messages should be in English.
Why not in Greek? Why not in Serbian (with Cyrillic alphabet)? Why not in Hangul (South Korea)? Why not in Japanese (in all their three alphabets)?
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...
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...
Today, plain text adoption often implies markdown for a richer experience. There are loads of markdown apps on the app stores, but the lesser-known org markup continues to fly under the radar. Quite possibly because of its Emacs origin (and many folks moving to other editors), but org is still plain text (and super powerful). We can all benefit from wider adoption beyond Emacs.
I built two org-powered apps for iOS myself:
https://plainorg.com
https://flathabits.com
There are other great ones out there:
https://beorg.app
https://braintool.org
https://logseq.com
https://organice.200ok.ch
https://orgro.org
http://orgzly.com
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 built two org-powered apps for iOS myself:
https://plainorg.com
https://flathabits.com
There are other great ones out there:
https://beorg.app
https://braintool.org
https://logseq.com
https://organice.200ok.ch
https://orgro.org
http://orgzly.com
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
Nice list! For using org-mode on desktop we made EasyOrg, https://easyorgmode.com. With a focus on managing todos for projects and with easy to use agenda and calendar views. More features and improvements being worked on.
EasyOrg looks interesting. I'm the developer of BrainTool, a browser bookmarking tool using an accessible org-mode file as backing store. I've long thought that org-mode needs an easy onramp. The copyright and blog entries ended in 2020, is it still under active development? (BTW the Twitter and Medium links point back to the homepage)
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-...
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-...
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...
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...
I agree with every point in this article, if we do a global search-replace s/ASCII/utf-8/g.
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.
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.
I think that GameFAQs needs to be mentioned. The walkthroughs there used ASCII in creative ways to represent tables, maps, headers, title art[1], etc.
[1]: https://www.rockpapershotgun.com/remember-how-great-ascii-ar...
[1]: https://www.rockpapershotgun.com/remember-how-great-ascii-ar...
Author is NetBSD developer. It is still favourite OS of mine when it comes to command line, text-only computer use.
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.
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.
> easiest to convert to any other format
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.
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.
The most common cases I run into are:
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.
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.
Resist the use of images? A picture says more than a 1000 words. Humans are visual beings. We see patterns everywhere, a good illustration is often very necessary in order to fully comprehend text. Each letter is really an illustration. The composition of the article and form of the text is very visual.
To just use pure text for everything is extreme. To resist the use of images, absolutely, but we cannot do without.
To just use pure text for everything is extreme. To resist the use of images, absolutely, but we cannot do without.
> The two most important ways to make your text easy to read are a short line-length and the copious use of paragraphs.
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?
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?
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.
"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.
>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.
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.
Blog author’s latest post makes copious use of formatting and colors:
https://www.netmeister.org/blog/debugging-certificate-errors...
Not saying that is wrong. Just maybe their views have evolved since 2015.
https://www.netmeister.org/blog/debugging-certificate-errors...
Not saying that is wrong. Just maybe their views have evolved since 2015.
This is all well and good, but I need resources. What apps should I use to make plaintext a comfortable experience? Any help with formatting, other than this. Should I use markdown or just stick with plaintext? How do I organise my plaintext?
The problem and benefit of plaintext is that it lets the user have a lot of power, and with power comes footguns.
The problem and benefit of plaintext is that it lets the user have a lot of power, and with power comes footguns.
There is no alternative to Plaintext for me.
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.
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.
org-mode has very nice bulleting and indenting facilities, as it descends from outline-mode. I imagine other plain text outliners might have equivalent features.
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.
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.
Org mode also let's you tangle your code chunks into separate files. And you can specify different files (or the same) for different chunks so you can kinda have programs split into files while doing everything in org. I really like this feature, I used to use Knitr but I don't think it's possible to tangle different chunks to different files.
Org-babel is a treasure and I much prefer it to Jupyter.
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).
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).
There is org-babel-excute-subtree but that only helps if what you want to run is in a subtree I guess.
I know, but I have not found this very helpful (yet?) in my workflows.
Does OmniOutliner work with plaintext?
It has some import/export facilities, but it's not really a plain text application.
Kind of ironic how an article that praises plaintext shows up as absolute garbage on my iPhone with or without reader mode.
It's because the article isn't plain text; it's pre-formatted text. Real plain text is great because your browser can re-flow it. Here the author has added hard linebreaks to disable this useful feature. I can't think of any good reason to do this.
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.
> 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.
>They may be some kind of quoted text - long compiler error messages, oops reports, whatever. Things that have a certain specific format.
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.
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.
What you've described isn't plain text.
It's a method of displaying plain text that distinguishes between original linebreaks and linebreaks inserted by the display software. The text itself is 100% plain.
Page scores a 100 on lighthouse. https://pagespeed.web.dev/report?url=https%3A%2F%2Fwww.netme... Although search engines probably won't show this page to mobile users because it doesn't have that meta viewport tag. Also I'm not a mod but welcome to the community https://news.ycombinator.com/newsguidelines.html I doubt the author is reading but I've had people analyze and talk about every detail of my html when submitting hobby projects I spent years working on and it always makes me sad when it happens.
> but I've had people analyze and talk about every detail of my html when submitting hobby projects
Take it as an unintended complement: if all they can find wrong is little niggles then you core idea must be good & interesting.
Take it as an unintended complement: if all they can find wrong is little niggles then you core idea must be good & interesting.
From the article:
> 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.
> 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.
Read the source for plain text mode, not HTML:
view-source:https://www.netmeister.org/blog/the-art-of-plain-text.html
Wrapping everything in a pre block isn't necessary. For example, look at Daring Fireball: [1][2] which is nicely rendered in a web browser, and very simple when you do a View Source.
[1] https://daringfireball.net
[2] https://daringfireball.net/2022/02/on_the_origin_of_the_ipho...
[1] https://daringfireball.net
[2] https://daringfireball.net/2022/02/on_the_origin_of_the_ipho...
It's not bad, but I prefer netmeister's.
> 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.
> 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.
You can use <p> without cluttering. Put </p><p> on its own line and at a different indentation level. I saw someone do this recently, and the plain HTML read just as well as any plaintext doc I ever saw while also rendering perfectly on the phone (which this article doesn’t do thanks to its use of pre).
what exactly is happening on phones with pre?
Or mobile browsers just set a viewport width of 960px if no viewport settings are specified. This is a sane assumption since if a viewport width isn't explicitly set the page was probably designed for desktops.
> Resist the temptation to use images. If you are unable to distill the concepts or thoughts into language, then you have likely not fully understood the problem.
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.
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.
I agree.
> 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.
> 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.
> If you are unable to distill the concepts or thoughts into language, then you have likely not fully understood the problem.
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.
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.
But unless you add enough text to adequately describe the problem, nobody will be able to search for that issue later.
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.
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.
It's a parochial viewpoint. You can only believe that written language is the presumptive best way to communicate if you only participate in a narrow range of activities.
Plaintext mania these days is like the minimal fad (that raged few years ago). Where for minimalism one does every sort of stuff, each of those, at every step defeats the very purpose of minimalism one by one.
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.
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.
128 character US-ASCII is indeed fundamental. It is an almost verbatim translation from the teletypewriter command set: https://en.wikipedia.org/wiki/ASCII
In the United States, maybe. In most places requiring ASCII is an arbitrary middle finger.
Most of us have encountered the "please enter a valid name" after filling in a form.
Most of us have encountered the "please enter a valid name" after filling in a form.
Plenty of cultures are myopic: I know some folks who lived in Korea for a while who would complain about web sites that only allowed four characters. Most family names are 1-2 Hangul characters:
* 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 [email protected].
* 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 [email protected].
US-ASCII predates the internet, UNIX, WWW and almost anything else you currently use. While seminal, it was certainly not prescient. Now it is little more than a fun artifact to play around with: https://every.sdf.org/
US-ASCII predates those things in the US. In most other places, different alphabets predated ASCII, and indeed the US. Sort-of-old is no argument for quality or fitness for every purpose.
This is not about alphabets or character sets. It is about the first standardized computer-to-computer textual protocol. And that is US-ASCII. That it is all skewed to US characters is a derivative of where it was initially developed. But not to worry, zillions of other code pages for every language on the planet soon appeared, and yours probably included...
I don't disagree that it was the first computer text protocol, I disagree that "128 character US-ASCII is fundamental" nowadays, or (from article) "ASCII text remains the universal interface", or "Use only plain ASCII text. (...) The lowest common denominator -- i.e. ASCII -- will do just fine."
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.
https://www.rfc-editor.org/rfc/rfc7997.txt
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.
https://www.rfc-editor.org/rfc/rfc7997.txt
Somebody write the art of org-mode!
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
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
> And please, do use a question mark at the end of a question. "Can you send me those TPS reports." is a clear sign of psychopathy.
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!
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!
Complexity of storage/presentation formats can indeed compromise accessibility and longevity. However, trying to enforce plain text on everything can be detrimental to the quality and fidelity of information.
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.
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 agree. I prefer html or md formatted "plain text" files. There is a reason books have different looking text and picture back hundreds and thousands of years. Plain text might be sufficient in a lot of cases but it's certainly not preferable in a lot of case. I do prefer html/md to any sort of binary format or proprietary one though for portability and universality.
1. That was a pleasure to read. The limited width of the text columns was really a refreshing change. The link [3] in the page recommends a text width of 4 inches for easy readability. This is quite a useful thing to know, and hardly followed anywhere on the web.
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.
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.
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.