Agreed! I actually provided some concrete critique of Google docs in OP. Do my criticisms also apply to Microsoft Word and LibreOffice?
More broadly, I'd like to persuade you that your software choices have unanticipated secondary consequences for you. The software world today is not a tame, urban place where you can afford to select tools based just on the features they offer. It's a jungle out there. You need to take into account the entities providing the tools, their goals and incentives. It's not a choice between hacks and no hacks, there's hacks everywhere. And hacks aren't even the most important lens to view your situation through. What matters is the intention behind the hacks. Are they working for you?
The key design constraint for me lately is to depend as much as possible on software that is easy to build. Open source is necessary but not sufficient.
Back in 1973 Ivan Illich had some useful things to say about the relationship between a society and its tools: http://akkartik.name/illich.pdf
> Yeah, those large documents don't work well with Git and other line-by-line diff systems. That doesn't mean line-by-line is better, it means we're too lazy to build a better version control system. Our tools should adapt to us, not the other way around!
I've used (and still use) all those tools. Our tools shouldn't adapt to Office applications, because Office applications can't even adapt to themselves! Anyone who has ever tried to copy/paste even between Microsoft applications knows the pain and headaches involved. There is no way you'd be able to offer clean diffs for all that garbage. The reason pure text editors are popular is because we've known this for a long time.
Not only that, but this kind of thing has existed for ~30 years now. I remember MS Word 6.0 on Windows 3.1, 16 bits and 4MB of RAM, with large documents with significant styling, embedded Powerpoint and Excel documents, MS Draw vector art, etc.
I concur that the line-based approach most Git tooling uses is not good enough. At the very least, even for code, it should be integrated with Tree-Sitter etc. by now and be comparing changes at the AST level, not just the raw text; and when it comes to documents, we should get side-by-side diffs showing the rendered document.
But is there a market for this, besides just you and me?
And HTML allows inserting SVG or image data URLs in-line as plain text which isn't far off from what this is.
I would argue that we’ve been too lazy to create powerful programs with open formats that do work well with Git and other line-by-line diff systems. Version control as functionality is a solved problem (yes, it’s got lots of usability problems and should probably make it impossible for a user to lose work, but those are separate from this discussion). Creating a hack that does in fact adapt the text tools to us (defining us as, like the author, someone who wants to use plain text) is exactly what they’ve done.
Actually, I'm not clear on the context of your complaint. If it's about Word and LibreOffice not playing well with text-based diff typically used by version control systems, then maybe the problem is with the file formats used by Word and LibreOffice.
I don't write many large documents, but I'll use MS Office at work for such things. They don't seem to care about version control for presentations and documentation.
For personal notes, I use Obsidian and Fossil SCM. For blog posts (which I'd like to get back to doing) I used Markdown, Hugo, and GitHub.
Text-based diff requires you to make a number of assumptions:
1. I'm writing a plain text file
2. The text file is broken up into multiple lines, each with distinct statements/expressions
1. I'm writing a document with plain text, graphics, possibly video, possibly sound, together on one page
2. The text may not be distinct statements/expressions on different lines
3. The media may change incrementally or wholly
4. The layout on the page may change incrementally or wholly
What we need is a way to combine different methods of diffing/versioning different kinds of files within one contextual view. The one view would allow you to view code diffs/Word diffs/image diffs/etc from one interface, and push/pull/share them to some kind of remote repository. Like Artifactory, but less terrible.
Yeah, those large documents don't work well with Git and other line-by-line diff systems. That doesn't mean line-by-line is better, it means we're too lazy to build a better version control system. Our tools should adapt to us, not the other way around!