There are a lot of tradeoffs to using non-plaintext formats beyond not being able to edit them on old-school green CRTs:
- Have you ever tried using git on a docx file? The best you have is file history, but good luck trying to merge branches, create/apply patches, cherry-pick commits, rebase, or view line-by-line history.
- You lose the interoperability of plaintext. Any editor can open a plaintext file, and consuming a plaintext file is straightforward. Not so with binary.
- You lose a lot of choice about how you want to interact with the file. Syntax highlighting, TextMate bundles/snippets, and hundreds of editors and plugins are available to both create and consume Markdown (and many other text formats).
I agree that rich text editing is great, but may I suggest looking into another plaintext format besides Markdown if you can't find a wysiwyg markdown editor you like? There's RTF, TeX, and others -- each with a great ecosystem of tools around it.
More generally, if a particular plaintext format doesn't meet your needs, I'd argue the problem isn't necessarily that the format is plaintext as opposed to binary. Binary can be nice for serializing C/C++/etc. objects and for packaging resources, but there are tradeoffs.
You are begging the question. Git works well with plaintext because it is a product of the 1970s thinking that OP is bemoaning. If we built tools to do Git-like things on rich text file formats, they’d work just as well. (And Track Changes does a subset of those things surprisingly well inside Word, fwiw)
And OP didn’t specify binary output. The output format could be anything we standardised on, just so long as it supports rich editing environments. That is, we shouldn’t have to write in the output format; the two can (and probably should) be disconnected.
Markdown is both a terrible output format and editing experience, especially when you get complicated. It’s the worst of both worlds.
I've been using MS Word with a heavy reliance on Track Changes for years, and I'm converting my technical writing department to use Markdown as fast as I can. I have moved them to the WYSIWYG-on-Markdown editor Zettlr[1], and my non-technical writers have praised it for being "almost-not-techie at all".
I can't stand one more MS magic trick to auto-formatting on copy-paste (while mangling half of the styles) or figuring out why some objects simply disappeared or why Word rejects applying some format or layout.
When your job is to keep working on expanding the same hundred-pages-long document year after year, you learn every trick to fix the random MS Word bugs and protect your document from being destroyed by the software 20 times a day, and it ain't pretty.
* I would have preferred to use Asciidoc instead of Markdown, as it comes with the full Docbook feature set; unfortunately, native support on well-maintained editors is much worse with that format.
Why not try FrameMaker or something actually built for the job, instead of forcing your poor team into a “still-actually-techie” format written to get around the limitations of MovableType for formatting weblogs? You’ll get DocBook support and still be free of the undeniable horror that is Word
What you call question-begging is really just an assumption I'm making - that git's feature set isn't available (or practically feasible) for any binary format.
You might disagree with that assumption, but if so I'd challenge you to show me (or build) a piece of software that (a) uses a binary storage file format and (b) has a feature set comparable to that of git for files in that format.
I know an argument from lack of existence doesn't prove anything. It certainly is within the universe of the possible to implement git's feature set in MS Word. But I highly doubt MS will ever do that, as that wouldn't make sense from a business standpoint.
A great general version control system is most likely to be implemented on formats that are the most interoperable. Nothing is more interoperable than plaintext. Perhaps if someone designs a structured general-use binary format that becomes widely adopted, then version control will be implemented for it. But I bet if someone does try to build such a binary format, someone else will follow it up by building a similar or better plaintext format. Plaintext is more attractive for non-proprietary software, because you get a lot for free.
In fact, I believe the only long-term business benefit of a binary format is vendor lock-in.
You might say developers are spoiled -- we enjoy power and freedom in our workflows that others don't even know is possible. I for one prefer the power and freedom that plaintext formats (both data and code) afford. Although I do sometimes use MS Word, I almost never commit a non-plaintext file to a git repo when there's a plaintext-format alternative.
(Again, rich text doesn’t need a binary file format but you ignored that)
Word’s Track Changes literally does this - you can compare/merge/etc. Quark also had extensions in the 90s that allowed it. It’s entirely feasible for any binary format (assuming you understand the format); why wouldn’t it be?
And it makes a lot of sense from a business standpoint, eg for lawyers, which is why they implemented it. Is it as rich as git? No, the use-case is different. Could it be? Yes.
I’m going to leave “power and freedom” where they lie and go marvel at the awesome power of the “Italic” and “Table” buttons from Word 5.1.
> (Again, rich text doesn’t need a binary file format but you ignored that)
I'm not arguing against rich text. I think it's a great idea. (My earlier comment suggests using it, actually.)
> Word’s Track Changes literally does this - you can compare/merge/etc.
Nice, but it doesn't support cherry-picking, creating and applying patch files, or any distributed VCS features. I'd also venture that it likely doesn't have anything like the 4-pane merge UI that tools like kdiff3 have.
---
If Word covers your needs, great! I'm not sure why you're arguing against markdown in favor of it, though. The two solve different problems.
I'm not arguing against word, just pointing out the practical differences between binary and plaintext files. Use what suits your particular needs!
- Have you ever tried using git on a docx file? The best you have is file history, but good luck trying to merge branches, create/apply patches, cherry-pick commits, rebase, or view line-by-line history.
- You lose the interoperability of plaintext. Any editor can open a plaintext file, and consuming a plaintext file is straightforward. Not so with binary.
- You lose a lot of choice about how you want to interact with the file. Syntax highlighting, TextMate bundles/snippets, and hundreds of editors and plugins are available to both create and consume Markdown (and many other text formats).
I agree that rich text editing is great, but may I suggest looking into another plaintext format besides Markdown if you can't find a wysiwyg markdown editor you like? There's RTF, TeX, and others -- each with a great ecosystem of tools around it.
More generally, if a particular plaintext format doesn't meet your needs, I'd argue the problem isn't necessarily that the format is plaintext as opposed to binary. Binary can be nice for serializing C/C++/etc. objects and for packaging resources, but there are tradeoffs.