Hacker News Reader

Comment by throwaway892238 | Hacker News Reader

I'm tired of Markdown hacks to try to justify not using Microsoft Word or LibreOffice. Every kind of functionality you can imagine already exists in open formats with powerful programs designed to make it easy for you to compose rich documents. For the love of god, use them.

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!

View on HN

> Our tools should adapt to us, not the other way around!

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

> I'm tired of Markdown hacks to try to justify not using Microsoft Word or LibreOffice. Every kind of functionality you can imagine already exists in open formats with powerful programs designed to make it easy for you to compose rich documents. For the love of god, use them.

> 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.

Almost every time I open up a Word document in LibreOffice there is something missing or wrong. It's because the Word document files does not have an open standardized format. Having a standard format means that you can build on-top, it enables developers to build add-ons like real time collaboration, and version control, instead of having it built into the app like in Word. A standard format also allows other document viewers and conversions between different formats. Microsoft have spent a lot of money buying or bullying competitors to Word, and they keep the format incompatible with other software because the main selling advantage for Word is that it's compatible with Word itself which has become an enterprise standard. Even Microsoft engineers think the word format is shit. But it's kept like that because of business reasons. If you want quality tools you should choose an open format, then buy the best tools for that format. There are plenty of "what you see is what you get" editors for open formats. But many people prefer to edit human readable source code directly in order to get precision - so the document look exactly how they want it to look. And also use tools like Git or Mercurial to collaborate by sharing code diff. With an open standard you as the user are in control, especially if the source code is human readable. Not everyone wants to consume software like force fed broiler chickens.

I think you're right. In my very limited-need case, it worked fine in the opposite direction. Generating .docx files for customers who would not accept older word format files, pdf's, and certainly not odf's. But admittedly, this is not enough for most folks.

> Every kind of functionality you can imagine already exists in open formats with powerful programs designed to make it easy for you to compose rich documents.

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?

I just use HTML. Personally I detest Markdown, I cannot remember how many asterisks is bold, how many is underline, how many is italic, in HTML it's just <b>, <u>, <i>, much more human-friendly.

And HTML allows inserting SVG or image data URLs in-line as plain text which isn't far off from what this is.

And if you write "polyglot" html (html written as syntactically correct xml) then you can use xpath or other tools to extract data from it (i.e. from tables).

Isn't making your own tool to satisfy your own needs the most "Our tools should adapt to us" possible, though?

You’ve literally contradicted yourself between the two paragraphs. You’ve said that powerful tools exist, but for people who need or appreciate line-by-line diffing, they should adapt to the state of the tools as they exist today.

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.

Aren't these hacks the act of adapting our tools to us (at least in an experimental sense)?

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.

> 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.

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

Compare that to composing a multi-media file:

  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

Some multimedia document formats have a text form (ODF is zipped XML), but it still has different assumptions from the text-based diff. An intelligent program understands when the formatting has only changed slightly, without having line-by-line assumptions. Word & LibreOffice already have such version control/diffing built in. So the technology already exists, but we're not applying it in a way that makes it convenient to store these documents with our other versioned/diffed documents.

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.

I mean, there are plenty of plain text document formats that don't suck. Asciidoctor is my favorite. But there's a lot of middle ground between markdown, which sucks, and word, which also sucks.

Perhaps someone ought to make an Ask HN about source control that works with prose. What can give the best diffs for soft-wrapped paragraphs using solely the default command?

Reply on news.ycombinator.com