Code I write, be it python, php, HTML or JS is still plain text as a format. I can open any of these code documents in any dumb text editor.
The fact that some other tool can do more with these files, parse them, execute them, "extract" some logic from them isn't relevant to the fact that I can open, read and edit these files as a pure and plain text file.
Therefore adding parsable parts/logic to files like YAML headers (or any self created style) doesn't make these files 'non plaintext'.
Following your logic would mean that doing any markup in a text file would make it somehow 'non plaintext'. I remember old Readme files with headlines being underlined by adding a new line full of - - - - (dashes). And stuff like this. Because these could theoretically be used to parse the files and extract headlines from the text.
Then the whole article loses all of its meaning. If you find yourself writing Python in Word something has gone so horribly wrong there is no saving you.
Just use the good old file program and you'll see that in any coherent world we classify python, php, html, and js files as different from actual plain text files.
This very much feels like you are trying to argue tea is same as plain water.
Interesting interpretation of my words. Or should I say projection? Nothing to do with what I said. But if it pleases you. I am fine being an incoherent and unsavable something.
As said. There is no technical difference between a txt or a php file. I can both run through cat and grep stuff.
Are there special programs that interpret the contents differently? Sure. The same with the difference between a php and a py file. Different interpreters doing different things because of different definitions how to 'read' the content.
All pure text, just different languages.
To borrow from your metaphor:
One is Earl Grey. One Darjeeling. One might be Green Tea. One (God forbid) herbs as tea.
Open up a word document (.docx) in hex editor (head -80 foo.docx | xxd) and you'll see it's not a plain file on a binary level. Now do the same with any python, php, html, and js files and you'll see that they're plain files.
That's the difference that Derek is talking about.
That makes the article extremely silly, actually almost pointless.
If you don't see difference between plain text files and text files then that's pretty much it for this conversation.
EDIT: just to hammer this point home; if you gave me a task to write a report in plain text and I delivered a .txt file with some custom markup language, would you consider the task to be completed satisfactorily? I wouldn't. You can argue that the specification of the task didn't exclude custom markup language, but any sane person would understand what plain text file means.
Why not. If there is a tool like pandoc parsing and translating your text and markup to anything (html, pdf, word docx, etc). Why not. I did that quite often at a former job.
All version controlled in git.
A few markup headers. Text formatted in markdown. Later combined with a bit of templating logic to ensure different looks (one for client and one for agency) when translating it into the final designed report.
Actually more efficient than creating the two target documents with design from the beginning as the reports quite often changed in structure while being prepared due to changes in requirements.
Separating content from (re-)presentation was a time saver.
You can also version control Word files. That’s not an argument. Apparently plain text is anything and everything. What makes docx file not plain text? You can still edit and view it with your text editor it is just harder.
If you don't see the difference between proprietatory format like docx and you argue that just because I add double-asterisk with a word in-between then suddenly it's not plain-text file (since it's markdown markup at this point) then yeah, this conversation is over.
By transforming file Foo.docx into file Bar.b64 you get a plain-text file (Bar.b64) but Foo.docx still isn't plain-text. That's actually how email attachments work (transforming any file into b64 plain-text file), so I think your counter-argument is pointless.
The fact that some other tool can do more with these files, parse them, execute them, "extract" some logic from them isn't relevant to the fact that I can open, read and edit these files as a pure and plain text file.
Therefore adding parsable parts/logic to files like YAML headers (or any self created style) doesn't make these files 'non plaintext'.
Following your logic would mean that doing any markup in a text file would make it somehow 'non plaintext'. I remember old Readme files with headlines being underlined by adding a new line full of - - - - (dashes). And stuff like this. Because these could theoretically be used to parse the files and extract headlines from the text.