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!
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).
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.
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.
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.
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.
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.
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.
> 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.
> 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?
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.
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.
> 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).
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.
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!
