A Love Letter to Plain Text(blog.afoolishmanifesto.com)
blog.afoolishmanifesto.com
A Love Letter to Plain Text
https://blog.afoolishmanifesto.com/posts/a-love-letter-to-plain-text/
38 comments
Without subtracting anything from the main point on plain text, it sounds like this person is in many senses reinventing the Org file format!
org-mode is one of my favorite discoveries in recent years.
I'm now only using Markdown when I absolutely have to and live in org-mode for everything else. And I've only just began scratching the surface of org's features!
I'm now only using Markdown when I absolutely have to and live in org-mode for everything else. And I've only just began scratching the surface of org's features!
This is not just Plain Text. Hugo is not that good for a bunch of text/markdown files. My advice is to look more into mkdocs which is a bunch of markdown files in a directory structure presented nicely (even implements js search).
A love letter to plain text would be a bit more lovely without so much unnecessary formatting (colors, borders, and other embellishments).
Ageed! It was too painful to read on my phone. Dark red on black is a questionable design choice. I appreciate the desire to standout, but usability should trump style.
[deleted]
Your browser should have a 'no style' option tucked away somewhere. Presentation is - according to the original web spec, not the present monstrosity - mostly the job of the client.
Isn't "reader mode" available on some browsers almost a "no style" option? I use it exactly for that reason. I admit not every page is reader-mode-enabled but I just don't bother with those.
In Firefox, you can select View > Page Style > None.
Of course there is also the reader mode.
Of course there is also the reader mode.
I think it looks beautiful.
And what's more, what an absolute joy to find something published on the web where the text has both good contrast, weight and width.
I'm totally fed up having to use the browser's developer tools or firefox reader mode because the text has font-weight 200/300, slightly darker grey on light grey text and uses less than 30% of my screen width.
It's so sad that this is such a rare treat on the web these days.
And what's more, what an absolute joy to find something published on the web where the text has both good contrast, weight and width.
I'm totally fed up having to use the browser's developer tools or firefox reader mode because the text has font-weight 200/300, slightly darker grey on light grey text and uses less than 30% of my screen width.
It's so sad that this is such a rare treat on the web these days.
"Find A Way To Call TFA Author A Hypocrite" seems to be a whole genre of news aggregator comment
I came in expecting the article to be pretty light on formatting, yet this one was one of the most oddly formatted articles I've read in a while. It's quite strange.
I suspect it's a cheap way to gain karma/rep/internet points.
What is 'plain text' ? Is it ASCII ? 7 or 8 bit ? EBCDIC ? UTF-8 ?
The distinction you are missing is what is generally meant by (and is actually valuable about) plain text is, "simultaneously human and machine readable data".
Many "plain text" formats, like markdown or INI files or json, actually have very strict formatting requirements and character set constraints, but the value-add comes from a human's ability to examine the on-file-system object, examine it with well-known and reliable tools (grep, awk, text editor, etc.), figure out what it's supposed to mean, then feed it to the machine, and compare the machine's behavior with their expectations.
With non-human-readable data, this is much harder, you pretty much need a tool to convert the binary data to readable text to distinguish between "my program is broken" and "my program works but is getting bad input."
Note that even structured ASCII can still make this hard, XML is nominally human-readable, but as a practical matter this can be difficult.
Many "plain text" formats, like markdown or INI files or json, actually have very strict formatting requirements and character set constraints, but the value-add comes from a human's ability to examine the on-file-system object, examine it with well-known and reliable tools (grep, awk, text editor, etc.), figure out what it's supposed to mean, then feed it to the machine, and compare the machine's behavior with their expectations.
With non-human-readable data, this is much harder, you pretty much need a tool to convert the binary data to readable text to distinguish between "my program is broken" and "my program works but is getting bad input."
Note that even structured ASCII can still make this hard, XML is nominally human-readable, but as a practical matter this can be difficult.
Encodings do not make text a binary format. This pedantry is uncalled for.
I’m not sure the text/binary distinction is that useful.
ASCII is much simpler than Unicode encodings, to the point where text can even become an attack vector. A fully featured UTF-8 parsing and rendering engine is a sophisticated thing.
Does it matter whether one or the other is classified as text or binary? Not as much as it matters which requires the more complex code to process.
ASCII is much simpler than Unicode encodings, to the point where text can even become an attack vector. A fully featured UTF-8 parsing and rendering engine is a sophisticated thing.
Does it matter whether one or the other is classified as text or binary? Not as much as it matters which requires the more complex code to process.
> A fully featured UTF-8 parsing and rendering engine is a sophisticated thing.
No, UTF8 decoding is trivial, you can do it in a few dozen lines in just about any language. It's Unicode that is a complex and moving target. But you can also just choose to implement a sane subset of Unicode for your application.
Recommended reading: http://cat-v.org/, https://github.com/cls/libutf
No, UTF8 decoding is trivial, you can do it in a few dozen lines in just about any language. It's Unicode that is a complex and moving target. But you can also just choose to implement a sane subset of Unicode for your application.
Recommended reading: http://cat-v.org/, https://github.com/cls/libutf
> I’m not sure the text/binary distinction is that useful.
Encoding a number in binary takes 4 or 8 bytes. Encoding it in plain text (ASCII or Unicode) takes as many bytes as there are digits, plus one for the sign / decimal separator. If you're talking about ASCII/Unicode, you're not talking about text/binary.
> ASCII is much simpler than Unicode encodings
I don't disagree with you, but Unicode is not binary.
> Does it matter whether one or the other is classified as text or binary?
They're both text.
Encoding a number in binary takes 4 or 8 bytes. Encoding it in plain text (ASCII or Unicode) takes as many bytes as there are digits, plus one for the sign / decimal separator. If you're talking about ASCII/Unicode, you're not talking about text/binary.
> ASCII is much simpler than Unicode encodings
I don't disagree with you, but Unicode is not binary.
> Does it matter whether one or the other is classified as text or binary?
They're both text.
I'm just saying there is no such thing as 'plain text'.
I also think that plain text is a bad idea, binary files are much easier to parse.
I also think that plain text is a bad idea, binary files are much easier to parse.
>I'm just saying there is no such thing as 'plain text'.
And yet, everyone agrees there is, and has no problem telling its case from other formats, even if they're all 0s and 1s underneath.
And yet, everyone agrees there is, and has no problem telling its case from other formats, even if they're all 0s and 1s underneath.
American programmers with little exposure to the world beyond their personal milieu agree that there is. The rest of the world stringently disagrees.
I'm not an american programmer, and we used to have 2-3 of our own encodings in my country (or "codepages" as it was referred to back in the day) before utf-8 took care of that. Because of that having to handle international text was the default from since I started professionally programming. So, nope.
Still, missing the point.
The difference between plain text formats and binary formats is not that plain text files do no consist of bytes or don't need an encoding to read them.
It's being able to work on them with a plain text editor, and being based on actual written text -- as opposed to packed bytes and custom (proprietary or not) formats.
Still, missing the point.
The difference between plain text formats and binary formats is not that plain text files do no consist of bytes or don't need an encoding to read them.
It's being able to work on them with a plain text editor, and being based on actual written text -- as opposed to packed bytes and custom (proprietary or not) formats.
That is not true. Guessing encoding is really, really difficult, and you can easily end up reading a file with an uncommon Japanese encoding as an Chinese encoding and end up with subtitle errors.
Plain text is anything but plain.
Plain text is anything but plain.
> I'm just saying there is no such thing as 'plain text'.
And I'm just saying it's pedantry. 'plain text' is an umbrella term for 'not binary'.
> I also think that plain text is a bad idea, binary files are much easier to parse.
Binary files are definitely faster and more compact. And tools such as google protocol buffers makes passing information very convenient and efficient. Unfortunately, most APIs out there use JSON, so we just have to live with it.
Maybe the widespread adoption of JSON and plain text APIs is a reflection of how we, as developers, have become more likely to optimize for our own development process rather than the actual hardware (see all the electron craze).
And I'm just saying it's pedantry. 'plain text' is an umbrella term for 'not binary'.
> I also think that plain text is a bad idea, binary files are much easier to parse.
Binary files are definitely faster and more compact. And tools such as google protocol buffers makes passing information very convenient and efficient. Unfortunately, most APIs out there use JSON, so we just have to live with it.
Maybe the widespread adoption of JSON and plain text APIs is a reflection of how we, as developers, have become more likely to optimize for our own development process rather than the actual hardware (see all the electron craze).
I think I understand where you may be coming from. You are correct in that it is quite possible to get into a situation where the "plain text" editor that you are using would not understand the binary encoding of (all or some of) the characters present in the what otherwise would be expected to be a text file and display some "binary noise" character instead. So, in this sense the definition of "plain text" becomes tied to the definition (or, rather, implementation) of a "plain text editor". But I think this is wrong. For example, is an XML file in ASCII plain text? The definition of the plain text file format is simply that the file must contain no control/meta data other than what is provided by the encoding itself (such as the new line character).
Nice that I see this article just while I'm working on a theme for Hugo.
I like TOML and YAML for their simple approaches.
You'll usually need some kind of structure, though.
As a side note: I find it amazing how many private pictures the author is sharing on his public Flickr album, which is linked on the website.
By definition the author doesn't consider them private so why is it amazing. What's more amazing is someone would go and even look at them let alone comment on their content!
Why is this trending?