I've tried a lot of different things over decades. And, after countless experimentation, I'm still at the same place...
I store data all over the place.
I have Evernote for long book notes and tracking financial data.
I'm using notion right now as my base of notes for learning how to build a cabin (toggles and embedding videos is wonderful).
I tried to really use roam and its off-shots for a while but could never really get into it.
And i use a new txt file all the time. Anytime I don't know what I need or going to do. And 90% of the time, I never look at them again but they're all in my one synced folder.
At the end of the day, I keep thinking I'll settle on one solution but I'm doubtful that's ever going to be true.
So, you’re a note squirrel. So am I. I’ve stopped caring or stressing out about it. I just accept that I’m never going to be overly organized or systematic.
I do keep all of my notes in a /notes folder or sub folder so that fuzzy find works nicely. That’s the extent of my organization.
I'm a Joplin user but I've been slowly learning Obsidian too. Level1Techs [0] did a fantastic primer on Obsidian and gave a thoughtful reflection on the zettelkastan method [1]. Josh Duffney's youtube channel [2] on Obsidian is also worth the watch too.
The faithful are still on Roam. Others have moved to:
1. Obsidian: has bidirectional linking and knowledge graphs, is faster and better supported, but doesn't have the outlining structure that Roam is based on.
2. Logseq: basically an open source Roam with 90-95% feature parity and some cool stuff that is its own.
I don't think Dendron is a Roam clone. All notetaking apps of the new generation have certain similarities, but Dendron has a pretty different philosophy for how you should organize your notes.
Roam's about the block within an outline, interlinking and transclusion.
Dendron's core schtick is making traditional hierarchies easier to work with.
Like, with Roam a feelings of power scenario would be queries getting you subtrees from disparate outlines from which you pick out relevant trains of thought to synthesize your own writing, or just an outliner's ease in manipulating your text.
With Dendron it's more like, "oh, I've been thinking about this all wrong" and restructuring your notes so your new hierarchies reflect your new understanding.
Yeah, the app's built around a tree hierarchy like normal folders, but using dot namespacing (music.memes.ohno.rickroll.md) to make working with it more doable than with a file manager. I don't know if it's better, per se, but they have definite philosophy to their design, and it's explicitly against graphs and wikilinks as the be all end all solution to knowledge base organization.
I like it, it was fun to see the plain version at the end too.
Outliving formats is an interesting angle. I'm sure some of us know people who still use proprietary formats and software from the 1990s or earlier. They keep backups, but they keep using what worked for them.
Some years back I wrote a modernizing-controller for a Dreamweaver site behind a traditional craftsman's business that is doing pretty well, especially with the help of the web. The modernizations I needed to plan for were so many that they had to think long and hard about years remaining until retirement. The scope changes I received were super awkward because I could feel their frustration with new ways of doing things. It was strange to see things like the .dwt Dreamweaver formats still in use. They also used other proprietary software & formats.
But I do find it hard to imagine that text files (in the sense of the article) would have run the site at any point. Text files do take a bit of a stoic philosophy to really grok at some level IMO, and this has been true since maybe the '70s? The thing about text is, first of all the information is the expression framework. This is backwards for a lot of psychologies out there. The emotional components show up as decoration. Font color schemes, etc.
The article also mentions mind mapping and other tools. Those can be really important as a way to express what is inside the mind as a completely different type of process. Mind maps in particular address a problem of categorical expression, in a breadth-first context. This makes the visual itself a very useful format-as-framework. I find that I use them just enough (I have my own variant) that I keep a semi-yearly Freeplane file at hand even though I mostly use text.
Anyhoo. :-) Lots of good points in there. Thanks for sharing the article.
I tend to go for (simple) markdown rather than pure text files. It can be rendered into some fancy format, but the source code is also readable to humans. With chat apps like Slack and Discord taking it up, even non-technical people tend to understand what it means to put emphasis on something. You get the benefits of plain text with the ability to empathise, without fancy formats. Such a format also enforces paragraphs and lists to be consistent, which is great for easy of reading.
There are other, similar slightly-more-than-plain-text formats (RST is common among some communities, for example) with the same benefits, and everyone can pick their favourites and use them freely because in the end these formats are easy to parse as a human.
This is my experience as well. I admire anyone that goes full .txt but I missed how easily markdown allows me to hierarchically organize my thoughts via headings and sub-headings.
Maybe, but there's no reason to use an ASCII-only text editor. (Almost) all modern text editors use UTF-8. And UTF-8 stores all the characters in the 7 bit ASCII table the same way ASCII does.
The result of that is, so long as you don't add any emoji or anything to your documents, a 2022 version of VS Code will store your text files in the same format as vi did in 1976.
Most of them should have an ANSI setting. It might be stashed as an option in the save dialog. If space is really an issue, zip them. Plain text always compresses wonderfully.
One nice alternative is a clipboard widget for your OS that strips formatting and other stuff out. I use "PureText" on windows to remove formatting and it works great for me for many things, though it only strips rich text formatting.
Even if your editor "supports" other encodings than ASCII -- i e. it can save text in other formats -- many (most?) of them can be set to save in some particular encoding by default (so set it to save as ASCII), and usually they save previously-existing files in the same encoding the files already had.
And, as someone already mentioned, all the first 127 characters of the UTF-8 encoding are the same as the ASCII ones, so a UTF-8-encoded file containing only those characters is identical to -- is -- an ASCII-encoded file.
Numerous modern editors support ASCII. There's no reason to want one to only support ASCII, and it certainly isn't required to deal with plain text notes.
Where do you store them now?
And 2 KB is 2 thousand characters ... "pages and pages" of notes sounds like more than that.
This is good advice, but (as he notes halfway through the post) "plain text" comes in a lot of forms.
I would also add that for life-long storage of "whatever" you do probably also need attachments. (I guess we could say “plain files”. And for those, more JPEG/PDF than .doc/.cwk (Hi mom! :) )
For a couple decades I used my IMAP mail server's "Drafts" mailbox as a kind of poor man's Notion|OneNote|Evernote|Blahblahnote. It supported plain text, and attachments. It was enough, and more importantly, not too much.
Today, I do use things like Notion and other locked-in products, just to know the landscape (sure has gotten better since the 1990s! wow!), but if it is anything more important than a grocery list (such as, say... scraps of my novel, baby name lists, pet name lists, boat name lists...) I make sure to use something like Logseq, Marktext, Obsidian, or yeah, just .txt.
I use plain text because there is no multimedia equivalent that is universal and end-user controlled, and there are no multimedia equivalents to Vim, Grep, regex, etc. Text is great, but an image, table, or diagram are sometimes irreplaceable.
We think we are great innovators, but we are stuck in 1990. Notice also that there are no Vim-equivalents for phones, even though that platform has been widely used for 15+ years.
Sorry Bill Joy; sorry Bell Labs; sorry (many more); we let you down, and we let down the public, which now has no integrated multimedia format beyond WordPress or Instagram.
There are plenty of text editors for phones; many of them cost very little. I don't find iVim very useful on a touch screen, but that's probably just me.
I think we're right on the precipice of this changing. PDF has long been the preferred format for dead-tree-like documents. It isn't quite as open, cleanly designed or navigable as we'd like but it has the inertial force to continue staying in use for decades.
Lately I've been working with Inkscape and realized that SVG also has the capacity to be a freeform document tool, and one with a different default context than HTML(scrolling document) or PDF(paginated document). The default setup involves a canvas, it has a notion of object hierarchies that lets you browse content from an outline, it lets you embed assets and layout in a more-or-less arbitrary fashion, it can be coded with JS, and there's some (under-explored) possibility for structured accessibility. It just needs a viewer that approaches the format in a way that makes sense as a target for content creation, beyond its existing role of small vector icons and simple animations.
None of the existing formats have to work exactly right, they just have to be the starting point for a streamlined source; then make a direct viewer for the source and you have the integrated multimedia format.
Is SVG too complex to be portable across systems and preserved across time?
It does remind me that EPUB, the ebook format, has potential: It's essentially, as I understand, HTML, CSS, and some metadata files, structured according to the specification, all in a zip file. It's already a standard, though AFAICT not quite stable.
If you've tried opening up lots of epub files (I have), you'll soon learn that there are a huge range of layouts and ugliness under the hood. Yes it's HTML, and therefore you can preserve a good portion of the knowledge even if you didn't have an ereader (though you need zip), but it would still be a pain to extract and reformat at scale.
Disclaimer: I probably spend too much time thinking about this from a 'long now' perspective.
> Disclaimer: I probably spend too much time thinking about this from a 'long now' perspective.
That's great! What have you come up with?
AFAICT, PDF - or PDF/A - is currently the only good format for long-term text document (e.g., books) preservation. It's the only format that's stable over the long-term (at least PDF/A is), it's the only universally supported format, and it's the only option with stable annotations (which is essential to me).
The major downside is that the actual text is hard to extract and integrate with other functions. That's why I have hopes for epub.
I don't mean actual Vim. Vim was designed for efficiency on the desktop hardware/software UI; I'm suggesting something designed with the same goal for the phone UI, but obviously it would work very differently. For example, perhaps it would rely heavily on gestures.
I use Tiddlywiki. It's end-user controlled, and works in any browser. I think it usually flies under the radar in these discussions, but it's really surprisingly powerful, I've found. It's the data and tools in a single HTML file, which makes it uniquely resistant to bitrot. There's a bit of a learning curve, though.
> Every few years a new company says you should use their special format. You have to pay them a monthly fee to use it — or keep all of your documents in their care. [...] When you store your writing in one company’s unique format, then you need that program to access it. Then the economy takes a turn, they go out of business, and your work is trapped in an unusable format.
This is something I've been dealing with lately. I have over a decade's worth of important personal and work files in proprietary formats, since I used Windows and Adobe's stuff for a long time. These days I'm using Linux exclusively, so my only option to read many of those formats is to hope that things like GIMP and Inkscape are able to open them somewhat accurately. All the documents I created in InDesign are as good as gone. I still have the files, but they're locked behind proprietary software that I couldn't use even if I wanted to. Oh, well...
For creating documents I've been learning LaTeX, and for note-taking I quite like Vimwiki[1]. I don't do nearly as much graphics work as I used to, though I appreciate things like the fact that Inkscape uses plain SVG by default. I'd rather not be locked out of my own files again in the future.
I think of it as "content and presentation should be as independent as possible". This is the content side: don't bother with fancy unreadable formats.
I've been thinking about this as I try to think about my own personal website. I'd like to have my content versioned, but, was really not loving the idea of tying myself to even a static website generator.
This is where I still ponder an approach more like antora (https://antora.org), where you can have a "doc repo" vs a "site repository". Thus, the concept of a version is really obvious.
I've also recently reorganized my professional notes into... a git repo that is only structured markdown files, one file per day, organized by year/month. And... it just works great.
My personal mantra is to use software/formats/etc that have been around at least as long as what you intend your content to last. Been there, been burned before...
This is one of the main strengths of Obsidian, which I have been using lately and I’m extremely happy with: everything is just Markdown files in some folder on disk. Zero danger of lock in.
You can have a disk hierarchy if you desire, or trust that search will find you what you are looking for. For me search works fairly well and if I need something extra I can just grep/sed/awk.
Plus it has the features that a simple text editor will not have: displaying images, live preview, relationships between topics, etc. It even has a Vim mode!
Been using obsidian for two weeks and the tagging / linking to documents is top notch, saving it to my internet drive at work brings out the best of all worlds
I use org-mode the same way. I have a flat directory with many small files, inspired by Zettelkasten and by simple wikis. No server, no dependencies.
This also works well for small organizations. Both GitHub and GitLab are able to render org files, with some minor limitations. Hence, a simple repository full of org files is already a wiki. Even local links just work, with zero dependencies.
It's possible to transform org files into HTML with some CI task to get support for all org features. But I have found this a bit of an overkill. I don't need most org features. The basics are already great: outlines, timestamps, hyperlinks, tables and footnotes.
You can achieve more or less the same things with Markdown as well.
The only problem with org (which may not be a problem for some folks) is that if you want to be able to edit org files with the least friction you need to use Emacs. I tried the org extension for VS Code and vim in the past and they just weren't quite the same as editing org via emacs.
It's faster now, I haven't been bothered by speed yet.
But yes, realtime collaboration is a critical feature for documents that can be used during meetings (and IMO ~no meetings should be held without documents).
The other critical feature is comments, which I assume Obsidian does not have support for (they would be very nontrivial to represent in markdown).
Serious question: how do you square your third paragraph with your first? That is, if you're using Obsidian's features like [[square bracket link syntax]], or #tags, or inline images, aren't you effectively locked in to editors that support the same set of features?
Best practice for tags is just include them in the plain text file, and inline images in Obsidian is like Derek said — just keep them in your folder structures just like your text.
Not really -- you're only locked in to the extent that Obsidian makes those things easy
If Obsidian went away, I'd still have a bunch of text files that I understood, and I'd know that I could find things tagged with #foo by using grep, that the [[links]] just mean to open links.md, that an image should be opened in a browser, etc.
Additionally, it’s pretty to extend most Markdown parsers with extended syntax. The worst thing that happens is you have to fork a parser to add extended syntax…which isn’t so bad.
square bracket syntax is fairly well used in wikis. While there are varying degrees of user experience if you step away from Obsidian, it's still readable. You can go and convert the links to []() either inside Obsidian with a plugin or later with a script.
You'll be able to get access to it in 20 years, even if not in a shiny UX friendly way. Which is more than can be said for some of the really old notes I took in proprietary pieces of software.
Obsidian is great. I use Syncthing to share my "database" between all my devices. I can do some quick edits/take notes on the go and when I get home the changes are already mirrored to my desktop.
This is exactly why I switched to Obsidian after trying a few others like Bear, Notion, and Craft. Let me see the files on disk! Don't abstract it away or hide it from me.
It's just unfortunate that the proprietary apps have IMHO much nicer UI/UX. Why can't we have both!
On Mac I use Ulysses. I get the benefits described here while still having a fast, native app with excellent UX.
I have Mac for work, and Linux for personal and an Android phone. That means Ulysses on Mac, ThiefMD on Linux, and Markor on Android, all synced with syncthings. Native apps on different OSes is the best solution I've been able to come across.
A single cross platform app would be preferable, but the last time I used Obsidian it was slow, heavy, bloated, with a pretty ugly UI, likely in part due to running on electron.
I use Ulysses too, but I it could be faster. I haven’t tried them in the latest versions, but in the past I’ve had issues with even medium-sized files with lots of formatting.
The look of Obsidian put me off too but after I got into it I realised the whole theme is totally css-able. It's really easy to make it your own.
I do agree though, they do themselves no favours with that ugly black / purple website. They need a much better, much prettier default.
All that aside, I'm delighted with my switch to Obsidian. Just an amazing tool, and total reassurance that it's just markdown with all the benefits that brings. So glad to be rid of Evernote...!
I do wish they had a cheaper commercial tier that maybe didn’t offer priority support or something.
$50/year puts you next to some good developer tools, that already do markdown pretty well, and I just don’t see the point of writing notes if they’re not also for work.
I’m sure it’s worth it once you have 100s or 1000s of notes by i somehow feel like it’s a bit of a too big pill to swallow in the beginning.
You can use it free, mate. Just sync your markdown files via your favourite provider, or your own WebDAV, e.g. Nextcloud, or use a free sync plugin. There's even git plugins if you're a fellow nerd that wants version control.
According to the license, you can't use it commercially without the commercial license, and I think the license is very clear that work related notes are included in commercial definition:
> You need to pay for Obsidian if and only if you use it for revenue-generating, work-related activities in a company that has two or more people. Get a commercial license for each user if that's the case. Non-profit organizations do not need commercial licenses.
But then I consider $50 not that much for a software that helps you earning your salary. And it becomes tax deductable this way.
If it doesn't help your work or a free markdown editor provides you the same value, you have your answer.
As I use it for my job I consider it worth the 50 bucks. I still would prefer it to bee FOSS, though (and be willing to pay, anyway) - as then I knew even the software might be still around when the company behind it is gone.
A lot of utility with obsidian comes from the plugins from the community (e.g. excalidraw) and even though they might store their stuff also on your disk as text files, the utility of that eco system is gone as soon as one switches (or changes, or requires a different file format for the text files or whatnot)
yeah, likewise, I have been using markdown and folders of files for ages, started to use Obsidian and it provides a nice editor for that, and yes, it even has a vim mode!
And easy linking and bi-directional linking. Once you experience these two features it’s very hard to imagine notes without it. That’s the main reason I couldn’t go with the authors workflow of just plain text files.
Obsidian looks interesting, but how do you sync between devices? Their sync service seems really expensive. On desktop I guess you can use git/Dropbox plugin, but what about mobile? I take a lot of notes on my Android phone.
My amusing anecdote is that I've pretty much settled on Markdown, but I'm still struggling to completely wean myself of the habit of constantly looking at the rendered output alongside the text source. My entire work group is OK with Markdown now, and even the managers don't care any more. I wonder if the lockdown has resulted in communication being less formal overall.
The nice thing about .docx is that it's a zip file full of xml. I'd be willing to bet that zip and xml are both readable in a hundred years, even if the specific version of .docx can't be loaded into a word processor.
I personally use emacs with writeroom-mode and markdown-mode plus some tweaks, but it's not realistic to expect everyone to go learn lisp and build their own text editor.
Yeah, proprietary formats are fine if they're easy to pry open and manipulate. Applications that store data in sqlite databases are also nice. The main issue is just getting locked into a single application because nothing else can read its bespoke binary file format.
I think that this can be expanded beyond just "only use plain text for important documents". I think the heart of it is really, "use only proven, open (preferably standardised) formats for important files." E.g. Markdown is a proven format (plain-text-readable but not strictly plain text), so it is likely to stay readable for a long time, and it is an open format, so you can use it right now without paying for proprietary software - so it would be suitable to use for an important file. HTML also fits the bill, so it would be suitable to store documents. (It seems that the "plain text" of this article actually uses HTML heavily.) Or, if you are making vector graphics, save them as SVG files instead of Adobe Illustrator files. And so on.
You've got it exactly right. Years ago, I wrote "Any sufficiently important information must be indistinguishable from plain text", and your point is what I was trying to get at: if it's that important, make sure the format you use has tools that are as helpful, flexible, and degradation-resistant as those available for plain text.
>If you rely on Word, Evernote or Notion, for example, then you can’t work unless you have Word, Evernote, or Notion. You are helpless without them. You are dependent.
Although I deliberately avoid Evernote and Notion for those stated reasons, I'm fine with Microsoft Word. I've been using it for 20 years. It even opens my proprietary DOS WordPerfect ("*.wp") files from 1980s!
Sometimes I need more flexible layout of fonts and graphics and MS Word is the tool I use for that. Markdown isn't an alternative. (EDIT add: Markdown isn't powerful enough for the style of documents I write. E.g. MS Word has tools to overlay graphic elements like arrows and callouts floating as editable layers on top of screenshots. Markdown can't do that.)
I'm confident I can still use it as a tool decades into the future. Even if Microsoft became more user hostile and eliminated local install in future versions and required a cloud-only Office 365 account, I'll just keep using Word 2019. LibreOffice may also be a Plan B option to open docx files. Not nervous about MS Word files at all.
---
^ orig comment above, edits below (I was interrupted when 1st commenting; apologies to anyone who responded to the short version)
---
See eg Obsidian (https://obsidian.md) for a great example. It's astonishing how feature-rich it's become. WYSIWYG editor, Excalidraw integration, Slid.es, etc etc etc.
And if you have any webdev chops at all, you have access to HTML, CSS and JavaScript. It's not even close.
Markdown is actually awful. There's at least 3 different dialects that are all called Markdown, so if you want your text rendered it's a toss-up as to whether or not it'll look how you intend.
I think that Markdown's success is due to a lack of a widely-used, simple alternative that's well-specified.
Org is easily and objectively the best markup but of course it's only very very recently that there was a non-emacs implement worth a damn.
Then pick a standardized dialect. Commonmark is the lowest common denominator; GFM is useful for when you need some extra features. Markdown also allows HTML for whenever you need something fancy.
The advantage of markdown isn't robustness, it's simplicity. Preteens can get a handle on it in minutes when using Reddit.
The main benefit that all these markup-shorthands serve IMO is getting people to add meaning semantically rather than with presentation. Word processor users typically adjust font size and color to make headings, even when given a list of headings right in the ribbon. Markdown is just an HTML shorthand: you can only work with semantic meaning.
While I broadly agree, particularly because it feels so fuzzy about when it starts interpreting it as raw HTML and when it goes back to markdown... I'm not sure how you can really claim Org is unambiguously better (best!) when Org mode has multiple flavors of almost exactly the same kind of feature. E.g. inline HTML in Org is: https://orgmode.org/manual/Quoting-HTML-tags.html#Quoting-HT...
>To avoid conflicts with currency specifications, single ‘$’ characters are only recognized as math delimiters if the enclosed text contains at most two line breaks, is directly attached to the ‘$’ characters with no whitespace in between, and if the closing ‘$’ is followed by whitespace, punctuation or a dash.
If I understand that correctly, it means this is LaTeX:
> Sometimes I need more flexible layout of fonts and graphics
That’s the key. For much of my writing, all I need is text with a little formatting, and markdown is great for that as a user. (It’s less nice if you’re writing a parser, but that hasn’t come up for me yet :) )
For some of my writing I need professional-grade layout. There I either use LaTeX directly, or I use pandoc then LaTeX.
But sometimes I need to:
- Include images that don’t have a public URL
- Use more than one font
- Have a recipient be able to edit the document
- And the recipient isn’t a developer
Markdown doesn’t check all of those boxes. Word files do (as do Google Docs links, ODF files, and some others).
Markdown is great, but it’s not enough all of the time.
Another advantage to plain text files: source control. You can check your writing into git and get a history of all your edits.
It’s something programmers take for granted, but it would be amazing if this got more widely adopted outside of tech. The number of files with names like “Report Final Final draft v3.docx” is truly staggering.
“Git for everything“ would be a multi-billion dollar startup easily.
> “Git for everything“ would be a multi-billion dollar startup easily.
In addition to plaintext documents, I have found that a simple JSON diff is also a very effective way to demonstrate changes between 2 complex biz objects. Non-developers can cope with this as long as the differences are visually obvious (red=removed, green=new, etc) and the object graph is reasonably flat. Everything can be trivially serialized to a JSON document, so this scales super well in my experience. We use a port of Google's DiffMatchPatch to generate human-friendly HTML reports of object diffs in our latest administration tools.
Git would be a byzantine disaster for 'everyone else'.
The graph and abstractions involved introduce enormous unnecessary complexity.
Now, 'historical changes for everyone' - yes.
But not Git. Git is very powerful, but ultimately a questionably valuable product in many cases overall. And we've now settled on it, so it's a bit difficult to displace.
Yeah, in high school I and another student did our essay peer reviews using annotated diffs once. It was so much easier than Google Docs, since we didn't have to leave our editors.
Wrapping version control with a non-tech-friendly porcelain could help a lot of people escape user domestication from vendor lock-in.
I don't care how much porcelain you add. Using git effectively beyond add and commit requires undestanding quite a few concepts. Mass adoption of git in the consumer space ain't happening anytime soon.
It cracks me up that this many years later, you put five people in a room to establish a git branch/merge/release strategy, and you get five very different opinions, and such strong opinions they are.
Luckily, that responsibility is not in my wheelhouse, I just have to live with whatever decisions are made.
So yeah, mass adoption in the consumer space, I don't see that happening.
A revert or a rebase gone wrong and wails of "what happened to my file?"
I was actually surprised : last time I used Git Bash on Windows it did work quite well with .docx files.
Then I switched jobs to avoid touching .docx files ...
The best alternative I've found to generate .docx output is R markdown, which uses pandoc under the hood and let's you program the whole document the way LaTeX would.
I've heard somewhere that docx is actually gzipped xml. But I never really confirmed that myself. But it's binary once gzipped, so your point still stands.
>I've heard somewhere that docx is actually gzipped xml. But I never really confirmed that myself.
docx and epub are zip files, you can rename them with a .zip at the end and open to see what is inside. It might not be as simple to zip them back, at least for epub is very important to zip the files in a certain order but I forgot the details, but is easy to do from command line.
Or use Vim; it has built in support for zip files, so you can just type something like `vim my_file.docx` and it will open the files in netrw (the built in file explorer). Move to the file you want and hit enter. "word/document.xml" has the main document contents in it.
The xml will probably need to be run through a formatter to be readable. You can type `:%!xmllint --format -` if you have xmllint installed.
Now prepare to spend several hours trying to make sense of the xml. :-p
Vim is not for me, I unzip the epub/docx and then open the xml/html files in Kate, I had to do this to examine what is saved or how it saved or if my custom epub exported worked correctly. For epub I think you need to make sure the metadata file is the first one in the archive for it to work(so not sure if editing stuff directly in vim will preserve the order)
Docx (and pptx, and xlsx) is a zipped (not gzipped) composite of several XML files plus any other attached resources. It extracts out to a whole folder structure.
Definitely binary once compressed, though, and even when extracted not an easy format to parse. It might be XML, but it’s still representing the full complexity of an MS Office document.
Pre LaTeX (I am old...) I wrote a huge command definition document for an embedded telecom product in nroff/troff. The whole thing was text files, with all the common parameters documented once, and the whole thing was assembled using a Makefile. So a typical page would be the command name, a descriptive paragraph, an include list of the parameters it used, and an include list of the possible return errors. Very little writing for a new command that mostly used existing parameters and errors.
And all tracked under CVS with a management/tracking layer on top.
# make command_doc
and the pile of text became a lovely 250 page postcript ready for the laser printer.
> "Git for everything“ would be a multi-billion dollar startup easily.
AIUI, git is already prepared to be that, it just needs diff programs that can handle whatever format. I mean, other than git's interface being its own impediment to non-technical users.
"Report Final Final draft v3.docx" is in a proprietary format format controlled by a single company. The spec may be open in some sense, but it's far from a level playing field.
Right, but if that company released a diff tool for docx (or someone reverse engineered one), git would work with it. I don't expect that to happen, I'm just saying git isn't the limiting factor.
The original pitch was "throw away your usb drive", I don't think file history came about until after 2010, but I'm not too sure and modern Google makes it impossible to find anything older than 2 years ago...
It's not that hard to search for old content on google. Just limit the year in the search filter. Anyway, I found mentions of this feature up to 2008 back. I guess it was there since mostly the beginning.
I switched from dropbox to mega years ago when the former removed Linux support. TIL mega have version support so I need to enable that and try it out.
First thing I do on a new device is setup my mega shared drives - and there is a lot of plaintext files there!
Dropbox never removed linux-support at all, or sync specifically. They removed support for some esoteric filesystems which lacked certain features. For most people dropbox on linux did not stopped working.
"Git for everything" is the first thought I had when I opened this article. I am trying to keep all my notes in Google docs and it's all good as long as you stick to their format. I can't edit text files in Google docs ! I mean, how absurd is this.
I feel like building a Google docs clone for simple text files. Just one feature - versioning (A Time machine like interface) and perhaps add collaborative editing later. I just want to write and store a text document without having to create multiple files. Automatic versioning of snapshots so I can go back in time and refer to any timestamp.
I once thought git for humans would be a great idea but never got around to speccing it out. Later on, a lawyer friend showed me the software they used 'for backup' (that they paid thousands per month for) and it turned out everything about it was just exactly like SVN. The terminology was different, the UX was laser focused to the intended users, but at the end of the day it was commits, syncs, merging, pretty much everything but branches, just laid out with domain specific language instead, professional office UI and simple UX.
Enterprise Content Management like EMC Documentum has this sort of thing baked in (it's been a long time, but they're definitely on top of it). But that's for big companies.
I tried to git my resume once upon a time. It's still something I'd love to finish doing, it just makes sense to have a git repository as a timeline of your life:
I eventually settled on LaTeX - although I considered dropping all the way down to groff/troff and having TeX be an intermediate step in the process.
Custom LaTeX classes made this more trouble than I was willing to deal with, so I decided to not pursue it further. I suspect Markdown might have similar challenges dealing with this, although given that the "verbose mode" is just HTML, I might be able to make it work.[1]
The print media type has been around for eons, but the @page rules don't support everything I need and are generally absent in WebKit browsers.
I had a similar thought some time ago and concluded it's an impossible task. The problem is that it would need to understand every file format its users care about and be able to represent changes in a useful way.
How do you merge destructive edits to image files?
Please explain, in 0's and 1's how to combine the change to add a dark splotch over here and a patch of blue over there so that the image you get out of the merge has both the dark splotch and the patch of blue... without teaching git how to comprehend image file formats (and assuming you're not using a bitmap which is sort of a free win).
Many version control systems aimed more toward digital assets do some sort of locking, so only one user edits a file at a time. Advisory or mandatory, with support for breaking locks, etc.
What was the tool called? We're currently looking to solve a problem for a client to better manage contract negotiation between his lawyers and the purchaser's lawyer (apartment units). ATM it's all done via email but I imagine there'd be heaps of tools out there.
I love some of the collaborative nature of Microsoft Teams and CRDT editing Word/Excel, but I'm usually pretty remote. Text over a tenuous WAN connection is ideal.
I work at a government agency and I was /just today/ getting them to review and approve Git and VS Code for our staff use - and pandoc. A couple years ago we never would have gotten open-source software approved. I wish I knew of an equivalent to SELinux or AppArmor for Windows so they could lock down things a semi-trusted application can do. VS Code will be used in a few different departments, but I mostly want it to help those unfamiliar with Git and its CLI (Git Graph is nice).
Pandoc can only do so much. I'm trying to convince my part of the gov to put policy documents we disseminate to staff in a git repo, so we can track who did what and why (based on commit messages). This will be a big step, but thankfully one part of our org is already moving toward version control for IT and data analytics so I'm proposing this and suggesting we hop on their bandwagon. Momentum.
There's a Word template that we commonly use for legal purposes where it gives you line numbers and you write text to align with the numbers. When reviewing it's easy to say "change line 23 to read ....". This - for example - will not translate well through pandoc because the numbers and the text are separate text elements.
There's a market for making pandoc better. Visually translating how elements "flow" from 1 format to another, instead of simply transpiling XML to Markdown.
I'm still excited thinking in a year I might be able to git-blame the legal department for things. Or see a diff from 1 administration to the next.
I love pandoc and git and writing text files, but oh my, unless the users in your organization are tech savvy, your scenario sounds like a recipe for disaster.
Admittedly, if there's any chance to this I think it will start with tech-savvy assistants helping to preserve documents on the backend of things. When a process takes hold budgets usually get restructured and a dedicated application is contracted around the existing process or data. I'm at minimum trying to prove the value of strict version control in my space :)
1. Policy makers think they write policy in English (or other human language). But more and more it is the software.
2. "policy engines" aren't going to cut it - we need to introspect code to decide what the code does - and translate that back to policy.
3. at my work the best solution i have got is using unit tests to explain what the policy is based on test comments - and again that's using english and again it's terrible ("best")
I think the real solution is both wider software literacy so that discussion happen "in code" and code that is more like policy (composable functional languages are thus likely to be useful here)
But great to hear you are taking any steps at all - would an HN letter writing campaign to your ministers help?
At least for LaTeX there are packages like lineno that will add line numbers to the compiled document which can then be referenced with a label automatically similar to equation or figure captions. So if somebody tells you to change line 23 you can reply with "Please see line \lineref{whatever} for change." and it will automatically fill where that change is to "Please see line 25" or whatever in case it's been moved by other changes.
You can, but .docx is binary (it's .zip, and the Word document itself is OpenXML)
So you won't have a neat revision history, unless you implement something in the pipelines to also convert .docx to something human readable, because .docx and OpenXML isn't.
Honestly I think modern Sharepoint/OneDrive based .docx files have already leapfrogged git for the average user.
In an office environment, modern MS Word gives you a really nice version history, with automatic or manual/named versions, plus multi-user simultaneous editing, with a slick and fast UI. It’s even cross platform - I send a coworker a link to a document, and they can open it and work on Word for Windows while I edit the same doc on Word for Mac or even on the web-based Word.
After not using Word for years we've been using it for a few months now for a project, expecting it would be decent.
While some of the ideas are great, the overall experience was pretty bad. Leaving autosave on often slowed down Word to an unworkable pace and after a few other issues (I'm not exactly sure what, wasn't involved) we just made sure only one person at a time works on the document.
Some other annoying small issues I experienced:
when working together sometimes your undo history is gone. I guess that's because someone else edited too and correctly undoing something someone else edited in between is not simple. IMO it's impossible and any system doing merges automatically will fall apart at some point.
Track edits cannot track deleting rows of a table
Wed based word works actually pretty fine, but it misses random features. Adding captions seems not to be supported.
I agree, I also expected the whole office365 ecosystem to do what's supposed to, but I also found it useless due to the slowness and errors the whole team kept getting while working on the same file. That and the fact that it somehow feels like the Mac version of their products always comes with a bonus bug. Don't event get me started on their web versions.
Were you using it on Linux or something? Or maybe with very large documents?
I use it every day and really haven’t had slowness issues, even when running via Parallels on the Mac side. Of course, typically my docs are <100 pages and light on images.
I have seen undo history go away when edits collide with multiple users, but that’s really the only way it could work. And you can still view old versions of the doc if you need to retrieve/restore something.
MS Word as a whole is definitely very far from flawless, but it’s still better than the alternatives I’ve seen, and it’s extremely entrenched. That’s why it’s hard to see “git for office docs”succeeding.
>Were you using it on Linux or something? Or maybe with very large documents
~250 pages, ~100 images, not something I expect a modern computer to struggle with. We used the web version on Linux sometimes, but I think it also happened when we didn't.
>I have seen undo history go away when edits collide with multiple users, but that’s really the only way it could work. And you can still view old versions of the doc if you need to retrieve/restore something.
The other way is like git does it, manual merging and conflict resolving. I don't think there's a way around that once you work with enough people together on a file.
That makes sense, although obviously the downside to a manual check-in/merge process is that it greatly slows down the editing flow.
Personally for the kinds of documents I work on, I'd rather risk losing my undo history than have to deal with manually merging changes from multiple users.
Plus, without real-time concurrent editing, the changes are much more likely to conflict.
Word also includes a nice GUI diffing tool for docx files. It's possible to make git diff use it using something like https://github.com/ForNeVeR/ExtDiff
Thank you for sharing this. I had no idea it existed! I was getting pandoc cleared at my work, but for the Windows environment that it is, this is another solution :)
Hmm. Sometimes I step back and I look at the version history in modern Office documents and it does feel convenient. I like the CRDT editing a lot. It still feels too loose and prone to issues, but I recognize its value to the average person.
Most of what bothers me is trying to view, read-only a previous version. Usually I have several Word or Excel documents up on my screen, and it's easy to begin modifying a past version that then becomes the latest. It's not reflex to open a previous version and untoggle autosave. It bites me all the time.. In Office's pursuit to help people avoid losing data, I wind up overwriting what I need to preserve. A lot..
I have not seen manual version names in Word doc history. Maybe I'm sheltered :s
It's great, until it isnt. For small and simple documents (sub 20 pages), there's no better option.
In my experience it starts to creak on large documents with multiple editors. I did a project many years ago where the key deliverable was a large report, worked upon by 3-4 contributors over 12 weeks.
That last week was absolute madness. Document got corrupted, and we tried all sorts of things. We ended up importing the corrupt document into Google Docs, which, oddly enough, did a better job of working with a corrupt Word document than MS Word did.
I've seen online Word become extremely slow even for small documents with a few editors.
It doesn't help that there are lots of versions of online Word - there's the one that lives in Sharepoint, the one I get to via Outlook, the one in Teams, and (maybe? somehow?) the desktop Word when editing an online file.
I dont use word, but I do know people that do use it (the modern version) and they still have files called "...final 3 copy(4) really final.docx".
These features are nice and all, but the thing is, most users not only don't care about using them, but don't care about even the idea of them to know they exist, so they continue with the old workflow.
Most of the time its better to get out of the users way, but in cases like this, if you truly do want to get rid of the infinite finals, they need a bit of a nudge
We use SharePoint for revisions for casual documents and another CM system for tracking releases of official documents. The CM system is meant really for CAD models but it lets you upload Word docs that it displays as PDFs with watermarked revision information so you have to have a revision table at the front of the document for listing changes. The SharePoint system is a lot easier to use but you don't get the same sort of change approval system since anyone can edit. Instead we use multiple folders for WIP, waiting for QA approval, and final versions. We have to follow ISO 9001 but anything developmental or that is just derivate of documents in the CM system can live on much more casual systems like git, SVN, or SharePoint.
Interesting, as much as I admire Evernote, I want something that is open source and can be installed locally. Of course, Git integration is another plus point.
> “Git for everything“ would be a multi-billion dollar startup easily.
Worked on a “Git for Word” project [1], which is currently on hold.
The diff part was manageable, though not trivial to get diffs that make sense for prose/regular text.
The hard parts are UX/UI (making Git concepts transparent to “normal” users) and merging. Yet without automatic merging, branching is not very convenient.
Would love to collaborate on this in the future again. Reach out if you are working in this space, happy to share.
I’ve had better than expected success with diffing word files by converting them to markdown via pan doc. It’s nowhere near perfect as you lose nearly all formatting, but if only the actual text content is changing it allows you to automate the display of those changes.
I don't think merging will ever be fully solved by software. It's a problem created and solved by process. How annoying merges are is entirely dictated by process.
Sourcetree is the best git GUI I've used. That could be used as a model.
I think an old-style solution to merging would be fine: output a word file that uses a unique font style to indicate which user made what conflicting changes, have the user edit the document and remove all of the "merge styles", then continue.
The idea is pleasing, but when you specifically look at Git, its UX is rather disappointing. I'm not even talking about the CLI (after a while you can get used to it). I'm talking about resolving conflicts. If I have a sequence of changes A -> B -> C, then I change A and rebase B on top of A resolving any conflicts, then rebasing C on top of B will most of the time mean that Git will most likely ask me to resolve the same conflicts all over again and more. The kind of conflicts is also staggering. Each time I look at the conflicts it generated, I cannot explain how it could come up with that craziness. And all the while it also merged some changes without signalling conflicts, but instead breaking something in significant ways, without notifying me in any way, i.e. silently breaking something potentially important.
From what I've read, Pijul should fix at least the problem of needing to resolve the same conflicts multiple times over and over again. However, I feel that version control focused on text breaks, because the merging algorithm doesn't know anything about the semantics of what's represented in text. So yes, I'd say that version control in more areas would be nice, but one based on binary formats understood by version control. One glimpse of that may be KeePassXC, which can merge password databases and has never done it wrong in my experience.
While I agree in that Git’s UX is abysmal for the beginner or casual user, no one should have to endure resolving the same conflicts over and over again.
In my opinion, the following configuration should have been the default with Git:
The `enabled` part means: transparently record all resolutions in a database, and re-apply them whenever bumping into the same conflict with the same pair of files in the future.
The `autoUpdate` part means: every time you finish re-applying a recorded resolution, please `git add` the result automatically for me so I don’t have to look for a "conflict" that’s actually no longer there.
I had no idea these options were a thing. Thank you for pointing them out, adding them to my config immediately and hoping it makes some merges and whatnot easier going forward.
Hint: rerere doesn't always work. It's still guesswork, like the rest of merges/rebases/cherry-picking in Git. This is because looking only at the tips of branches doesn't work, and that's the only thing Git can do (with or without diff3 as the merge algorithm).
The rerere database is content-addressed, and rerere will apply a resolution only if the pair of conflicting files is a bit-exact déjà-vu of a conflict it has seen before.
I don’t see how that is guesswork. My impression is that rerere is perfectly deterministic, and only repeat things the user has done before.
The downside is: once the user has manually created a faulty resolution, then rerere will possibly replay that faulty resolution.
That’s how things can go wrong, and I see how one might blame that failure on rerere itself. And I think the blame not entirely unjustified, because rerere could do a much better job in explaining how it interacts with certain scenarios. For example, let’s say I’m aborting a rebase. Will rerere roll back the resolutions it recorded? I honestly don’t know. The manpage vaguely claims that it will, but I’ve been unable to reproduce it.
I wish rerere made more transparent how it interacts with `--abort`. Just printing an informational line would already go a long way. I also feel a command like `git rerere log`, which would print the recent activity of the `rerere` database, might help with that.
The git diff process and conflict process really goes off the rails at times, and I have never figured that out. Modify one line in a file, and add one new line two lines after that modification, and the git diff is two 40 line chunks with some common lines, a bunch of additions, and a bunch of deletions.
Really? One new added line, and one delete/add two lines above it.
it usually works fine, it really does, but when it messes up, it really messes up big time. As long as it doesn't create a conflict, you just shrug and move on, but when it does create a conflict, holy-moley!
The biggest UX sin of Git is that rebasing is featured so prominently. If you had just done a normal merge commit then Git could have realized the common history, done a three-way merge, and resolved the conflict automatically.
But no, people always seem to insist on that linear history is the only concern that matters, explicitly delete the history, and then wonder why Git is so annoying and easy to screw up.
Maybe Git should have locked rebase behind a feature flag of some kind. `git pull --rebase` should certainly never have been added.
When I have a chain of commits pending review on Gerrit, and I fixed some flaws in the first commit in chain and need to rebase the dependent commits, merging is not an option. And rightly so: when I look at the master branch, I don't want to see random corrections someone made during review, they're just irrelevant once the reviewed changes are merged.
There are many reasons why linear history is important. Rather than saying that "you shouldn't want to do that", I'd prefer it if the tools people use were fixed to better serve the things people actually want to do.
A merge would only make sure that I don't need to resolve the same conflict multiple times. It wouldn't result in the conflicts not being generated in the first place, or them being saner. The only difference in conflict resolution between rebasing and merging is that the sides are flipped (what's shown on left in rebase, is on the right in merge, and vice-versa). Which doesn't address the second issue I listed: conflicts are not only repeated, but the conflicts themselves are pretty crazy. In my example, often-times C would never even touch files which were detected as having conflicting changes with A or B. It was pretty absurd that I would have a 3-line change in C, several hundred-line changes in A and B, yet the biggest conflicts would be triggered when rebasing C on top of B, and those would be in files C did not touch. Other times diffs in conflicts would have most of the lines added and removed actually identical, with only a couple in the middle different. Why would git mark them as conflicting, is beyond me. And then there was the issue of git not detecting conflicts, when it should have, instead merging changes in a way that broke source code. None of those issues is better handled by merging than by rebasing. Most of them however have pretty good solutions in a patch-based version control system, as opposed to snapshot-based like git (conflicts in files which weren't changed? not going to happen). An even better solution would be binary formats with domain-specific merge logic, like the one in KeePassXC.
> When I have a chain of commits pending review on Gerrit, and I fixed some flaws in the first commit in chain and need to rebase the dependent commits, merging is not an option.
No, you just add it at the end of the commit chain?
> And rightly so: when I look at the master branch, I don't want to see random corrections someone made during review, they're just irrelevant once the reviewed changes are merged.
git log actually has the --first-parent for this, which hides all of the commits that were merged into the branch, without destroying the history when you try to go back and try to understand why the choices were made. The idealized version of history created by constant rebasing serves neither purpose.
> Rather than saying that "you shouldn't want to do that", I'd prefer it if the tools people use were fixed to better serve the things people actually want to do.
Agreed, tools that cope poorly with merges should be fixed, rather than forcing people to hack around it by rebasing.
> None of those issues is better handled by merging than by rebasing.
Not quite, rebasing generates more false positives, since it tries to merge every intermediate commit instead of only looking at the end states and the common ancestor.
> However, I feel that version control focused on text breaks,
Pijul doesn't, by the way, the diff algorithm is customisable. I wrote one industrial application of Pijul that uses spaces as breaks, and semantics-aware breaking is totally doable.
Which is the next thing. Git works just local and uses servers to sync. The purpose of servers is syncing and not depending on them. From this everything else comes, autonomous usage, speed, reliability, recovery.
I wound up writing dupver https://github.com/akbarnes/dupver after getting frustrated with the lack of versioning tools for binary files. One neat thing about .docx files and their ilk is that they are "just" zip files so it isn't hard to add special handling to pull out their contents and run deduplication over that.
I mourn that StackEdit [1] got abandoned. It's online markdown editor that can use git as a backend. Fully cross platform editing (in browser) with synced all text. I used it with GitHub private repository for all my notes but editing on mobile was really buggy. So I moved to notion (unfortunately).
I feel like this is a solution without a problem. Or a problem without pain.
Most people have no issues navigating a full folder of revisions to get to “Report Final Final draft v3.docx” but anything resembling version control would simply be unused. At corporate level, the version features of box.net, egnyte, and others are rarely used. I'd say most people don't even know they can navigate the revisions until they are in a data loss situation and asking about how to recover a corrupted file (which occurs most frequently with Excel files in my experience)
I'm a fan of text files. But many times you just want to capture the image and store it. For e.g. a bills/receipts. Secondly, the article doesn't talk about syncing - may be onedrive/dropbox? what are some good solutions here? Third, how do you do this (writing/editing notes) on a mobile phone?
Proper notetaking app, can show images inline (but stores the note and image as a plaintext file and a normal image file, the text file just has a line for what image to show like:
/Notebook/Attachments/Bill.png
/Notebook/Notes/Bill.md
Bill.md contents:
Went to restaurant and got this for the trouble:
![[Bill.png]]
They have a full features mobile app and sell an end to end encrypted sync service for the app. It's as good as it gets, IMO.
424 comments
[ 5.8 ms ] story [ 349 ms ] threadI store data all over the place.
I have Evernote for long book notes and tracking financial data.
I'm using notion right now as my base of notes for learning how to build a cabin (toggles and embedding videos is wonderful).
I tried to really use roam and its off-shots for a while but could never really get into it.
And i use a new txt file all the time. Anytime I don't know what I need or going to do. And 90% of the time, I never look at them again but they're all in my one synced folder.
At the end of the day, I keep thinking I'll settle on one solution but I'm doubtful that's ever going to be true.
So, you’re a note squirrel. So am I. I’ve stopped caring or stressing out about it. I just accept that I’m never going to be overly organized or systematic.
I do keep all of my notes in a /notes folder or sub folder so that fuzzy find works nicely. That’s the extent of my organization.
[0] https://www.youtube.com/watch?v=H69tRdemJiM
[1] https://en.wikipedia.org/wiki/Zettelkasten
[2] https://www.youtube.com/channel/UCCV1T7JbfzbE2O7P3kydmKw/vid...
1. Obsidian: has bidirectional linking and knowledge graphs, is faster and better supported, but doesn't have the outlining structure that Roam is based on.
2. Logseq: basically an open source Roam with 90-95% feature parity and some cool stuff that is its own.
3. Foam/Dendron/Athens etc: Roam clones.
4. Notion/Evernote/something else entirely.
Roam's about the block within an outline, interlinking and transclusion.
Dendron's core schtick is making traditional hierarchies easier to work with.
Like, with Roam a feelings of power scenario would be queries getting you subtrees from disparate outlines from which you pick out relevant trains of thought to synthesize your own writing, or just an outliner's ease in manipulating your text.
With Dendron it's more like, "oh, I've been thinking about this all wrong" and restructuring your notes so your new hierarchies reflect your new understanding.
Outliving formats is an interesting angle. I'm sure some of us know people who still use proprietary formats and software from the 1990s or earlier. They keep backups, but they keep using what worked for them.
Some years back I wrote a modernizing-controller for a Dreamweaver site behind a traditional craftsman's business that is doing pretty well, especially with the help of the web. The modernizations I needed to plan for were so many that they had to think long and hard about years remaining until retirement. The scope changes I received were super awkward because I could feel their frustration with new ways of doing things. It was strange to see things like the .dwt Dreamweaver formats still in use. They also used other proprietary software & formats.
But I do find it hard to imagine that text files (in the sense of the article) would have run the site at any point. Text files do take a bit of a stoic philosophy to really grok at some level IMO, and this has been true since maybe the '70s? The thing about text is, first of all the information is the expression framework. This is backwards for a lot of psychologies out there. The emotional components show up as decoration. Font color schemes, etc.
The article also mentions mind mapping and other tools. Those can be really important as a way to express what is inside the mind as a completely different type of process. Mind maps in particular address a problem of categorical expression, in a breadth-first context. This makes the visual itself a very useful format-as-framework. I find that I use them just enough (I have my own variant) that I keep a semi-yearly Freeplane file at hand even though I mostly use text.
Anyhoo. :-) Lots of good points in there. Thanks for sharing the article.
https://ia.net/writer
There are other, similar slightly-more-than-plain-text formats (RST is common among some communities, for example) with the same benefits, and everyone can pick their favourites and use them freely because in the end these formats are easy to parse as a human.
The result of that is, so long as you don't add any emoji or anything to your documents, a 2022 version of VS Code will store your text files in the same format as vi did in 1976.
And, as someone already mentioned, all the first 127 characters of the UTF-8 encoding are the same as the ASCII ones, so a UTF-8-encoded file containing only those characters is identical to -- is -- an ASCII-encoded file.
Where do you store them now?
And 2 KB is 2 thousand characters ... "pages and pages" of notes sounds like more than that.
I would also add that for life-long storage of "whatever" you do probably also need attachments. (I guess we could say “plain files”. And for those, more JPEG/PDF than .doc/.cwk (Hi mom! :) )
For a couple decades I used my IMAP mail server's "Drafts" mailbox as a kind of poor man's Notion|OneNote|Evernote|Blahblahnote. It supported plain text, and attachments. It was enough, and more importantly, not too much.
Today, I do use things like Notion and other locked-in products, just to know the landscape (sure has gotten better since the 1990s! wow!), but if it is anything more important than a grocery list (such as, say... scraps of my novel, baby name lists, pet name lists, boat name lists...) I make sure to use something like Logseq, Marktext, Obsidian, or yeah, just .txt.
We think we are great innovators, but we are stuck in 1990. Notice also that there are no Vim-equivalents for phones, even though that platform has been widely used for 15+ years.
Sorry Bill Joy; sorry Bell Labs; sorry (many more); we let you down, and we let down the public, which now has no integrated multimedia format beyond WordPress or Instagram.
Lately I've been working with Inkscape and realized that SVG also has the capacity to be a freeform document tool, and one with a different default context than HTML(scrolling document) or PDF(paginated document). The default setup involves a canvas, it has a notion of object hierarchies that lets you browse content from an outline, it lets you embed assets and layout in a more-or-less arbitrary fashion, it can be coded with JS, and there's some (under-explored) possibility for structured accessibility. It just needs a viewer that approaches the format in a way that makes sense as a target for content creation, beyond its existing role of small vector icons and simple animations.
None of the existing formats have to work exactly right, they just have to be the starting point for a streamlined source; then make a direct viewer for the source and you have the integrated multimedia format.
It does remind me that EPUB, the ebook format, has potential: It's essentially, as I understand, HTML, CSS, and some metadata files, structured according to the specification, all in a zip file. It's already a standard, though AFAICT not quite stable.
https://www.w3.org/publishing/groups/epub-wg/
Disclaimer: I probably spend too much time thinking about this from a 'long now' perspective.
That's great! What have you come up with?
AFAICT, PDF - or PDF/A - is currently the only good format for long-term text document (e.g., books) preservation. It's the only format that's stable over the long-term (at least PDF/A is), it's the only universally supported format, and it's the only option with stable annotations (which is essential to me).
The major downside is that the actual text is hard to extract and integrate with other functions. That's why I have hopes for epub.
This is something I've been dealing with lately. I have over a decade's worth of important personal and work files in proprietary formats, since I used Windows and Adobe's stuff for a long time. These days I'm using Linux exclusively, so my only option to read many of those formats is to hope that things like GIMP and Inkscape are able to open them somewhat accurately. All the documents I created in InDesign are as good as gone. I still have the files, but they're locked behind proprietary software that I couldn't use even if I wanted to. Oh, well...
For creating documents I've been learning LaTeX, and for note-taking I quite like Vimwiki[1]. I don't do nearly as much graphics work as I used to, though I appreciate things like the fact that Inkscape uses plain SVG by default. I'd rather not be locked out of my own files again in the future.
[1] https://vimwiki.github.io/
Hum, yes you could. The formats aren't dead.
It's like putting on a blindfold and saying you couldn't see even if you wanted. Just remove the blindfold.
Just install Windows or Mac.
I've been thinking about this as I try to think about my own personal website. I'd like to have my content versioned, but, was really not loving the idea of tying myself to even a static website generator.
This is where I still ponder an approach more like antora (https://antora.org), where you can have a "doc repo" vs a "site repository". Thus, the concept of a version is really obvious.
I've also recently reorganized my professional notes into... a git repo that is only structured markdown files, one file per day, organized by year/month. And... it just works great.
You can have a disk hierarchy if you desire, or trust that search will find you what you are looking for. For me search works fairly well and if I need something extra I can just grep/sed/awk.
Plus it has the features that a simple text editor will not have: displaying images, live preview, relationships between topics, etc. It even has a Vim mode!
This also works well for small organizations. Both GitHub and GitLab are able to render org files, with some minor limitations. Hence, a simple repository full of org files is already a wiki. Even local links just work, with zero dependencies.
It's possible to transform org files into HTML with some CI task to get support for all org features. But I have found this a bit of an overkill. I don't need most org features. The basics are already great: outlines, timestamps, hyperlinks, tables and footnotes.
You can achieve more or less the same things with Markdown as well.
This is truly the era of the memex.
I really wish Obsidian, or something like it, worked well for teams. Maybe it's on their roadmap, I'm not sure.
Also, is real time collaboration a game changer or a gimmick?
I used to think the former, but was questioning it recently.
What would be lost with syncthing + obsidian for your team or maybe something that does autocommit like fossil for probable conflicts?
But yes, realtime collaboration is a critical feature for documents that can be used during meetings (and IMO ~no meetings should be held without documents).
The other critical feature is comments, which I assume Obsidian does not have support for (they would be very nontrivial to represent in markdown).
https://gist.github.com/rattrayalex/2e4f934045aabc4caeeab249...
The real time is not as real time as, say, Google Docs. There's a lot of lag.
It is open source and everything is stored locally but not in markdown files. You can self-host the desktop app to share notes.
[0]: https://github.com/athensresearch/athens
Best practice for tags is just include them in the plain text file, and inline images in Obsidian is like Derek said — just keep them in your folder structures just like your text.
If Obsidian went away, I'd still have a bunch of text files that I understood, and I'd know that I could find things tagged with #foo by using grep, that the [[links]] just mean to open links.md, that an image should be opened in a browser, etc.
You'll be able to get access to it in 20 years, even if not in a shiny UX friendly way. Which is more than can be said for some of the really old notes I took in proprietary pieces of software.
On Mac I use Ulysses. I get the benefits described here while still having a fast, native app with excellent UX.
I have Mac for work, and Linux for personal and an Android phone. That means Ulysses on Mac, ThiefMD on Linux, and Markor on Android, all synced with syncthings. Native apps on different OSes is the best solution I've been able to come across.
A single cross platform app would be preferable, but the last time I used Obsidian it was slow, heavy, bloated, with a pretty ugly UI, likely in part due to running on electron.
I do agree though, they do themselves no favours with that ugly black / purple website. They need a much better, much prettier default.
All that aside, I'm delighted with my switch to Obsidian. Just an amazing tool, and total reassurance that it's just markdown with all the benefits that brings. So glad to be rid of Evernote...!
$50/year puts you next to some good developer tools, that already do markdown pretty well, and I just don’t see the point of writing notes if they’re not also for work.
I’m sure it’s worth it once you have 100s or 1000s of notes by i somehow feel like it’s a bit of a too big pill to swallow in the beginning.
> You need to pay for Obsidian if and only if you use it for revenue-generating, work-related activities in a company that has two or more people. Get a commercial license for each user if that's the case. Non-profit organizations do not need commercial licenses.
https://obsidian.md/eula
If it doesn't help your work or a free markdown editor provides you the same value, you have your answer.
As I use it for my job I consider it worth the 50 bucks. I still would prefer it to bee FOSS, though (and be willing to pay, anyway) - as then I knew even the software might be still around when the company behind it is gone.
A lot of utility with obsidian comes from the plugins from the community (e.g. excalidraw) and even though they might store their stuff also on your disk as text files, the utility of that eco system is gone as soon as one switches (or changes, or requires a different file format for the text files or whatnot)
Prose are Powerful
Writes HTML tags
:shrug:
I personally use emacs with writeroom-mode and markdown-mode plus some tweaks, but it's not realistic to expect everyone to go learn lisp and build their own text editor.
Although I deliberately avoid Evernote and Notion for those stated reasons, I'm fine with Microsoft Word. I've been using it for 20 years. It even opens my proprietary DOS WordPerfect ("*.wp") files from 1980s!
Sometimes I need more flexible layout of fonts and graphics and MS Word is the tool I use for that. Markdown isn't an alternative. (EDIT add: Markdown isn't powerful enough for the style of documents I write. E.g. MS Word has tools to overlay graphic elements like arrows and callouts floating as editable layers on top of screenshots. Markdown can't do that.)
I'm confident I can still use it as a tool decades into the future. Even if Microsoft became more user hostile and eliminated local install in future versions and required a cloud-only Office 365 account, I'll just keep using Word 2019. LibreOffice may also be a Plan B option to open docx files. Not nervous about MS Word files at all.
Strongest possible respectful disagreement.
--- ^ orig comment above, edits below (I was interrupted when 1st commenting; apologies to anyone who responded to the short version) ---
See eg Obsidian (https://obsidian.md) for a great example. It's astonishing how feature-rich it's become. WYSIWYG editor, Excalidraw integration, Slid.es, etc etc etc.
And if you have any webdev chops at all, you have access to HTML, CSS and JavaScript. It's not even close.
I think that Markdown's success is due to a lack of a widely-used, simple alternative that's well-specified.
Org is easily and objectively the best markup but of course it's only very very recently that there was a non-emacs implement worth a damn.
The advantage of markdown isn't robustness, it's simplicity. Preteens can get a handle on it in minutes when using Reddit.
The main benefit that all these markup-shorthands serve IMO is getting people to add meaning semantically rather than with presentation. Word processor users typically adjust font size and color to make headings, even when given a list of headings right in the ribbon. Markdown is just an HTML shorthand: you can only work with semantic meaning.
Indeed and therein lies what I view is Markdown's worst feature.
>To avoid conflicts with currency specifications, single ‘$’ characters are only recognized as math delimiters if the enclosed text contains at most two line breaks, is directly attached to the ‘$’ characters with no whitespace in between, and if the closing ‘$’ is followed by whitespace, punctuation or a dash.
If I understand that correctly, it means this is LaTeX:
But this is not: Similarly, this is apparently an inline chunk of LaTeX: https://travel.stackexchange.com/questions/39527/which-count...I laughed.
That’s the key. For much of my writing, all I need is text with a little formatting, and markdown is great for that as a user. (It’s less nice if you’re writing a parser, but that hasn’t come up for me yet :) )
For some of my writing I need professional-grade layout. There I either use LaTeX directly, or I use pandoc then LaTeX.
But sometimes I need to:
- Include images that don’t have a public URL
- Use more than one font
- Have a recipient be able to edit the document
- And the recipient isn’t a developer
Markdown doesn’t check all of those boxes. Word files do (as do Google Docs links, ODF files, and some others).
Markdown is great, but it’s not enough all of the time.
Word isn't bad, so long as you keep paying your subscription.
Web Word is free, like Google Docs is. (Meaning, it costs your credentials and data rather than your money).
https://www.techradar.com/uk/how-to/how-to-download-and-use-...
https://www.microsoft.com/en-us/microsoft-365/free-office-on...
For now. You don't know if and when Microsoft's business model is going to change.
It’s something programmers take for granted, but it would be amazing if this got more widely adopted outside of tech. The number of files with names like “Report Final Final draft v3.docx” is truly staggering.
“Git for everything“ would be a multi-billion dollar startup easily.
In addition to plaintext documents, I have found that a simple JSON diff is also a very effective way to demonstrate changes between 2 complex biz objects. Non-developers can cope with this as long as the differences are visually obvious (red=removed, green=new, etc) and the object graph is reasonably flat. Everything can be trivially serialized to a JSON document, so this scales super well in my experience. We use a port of Google's DiffMatchPatch to generate human-friendly HTML reports of object diffs in our latest administration tools.
Git would be a byzantine disaster for 'everyone else'.
The graph and abstractions involved introduce enormous unnecessary complexity.
Now, 'historical changes for everyone' - yes.
But not Git. Git is very powerful, but ultimately a questionably valuable product in many cases overall. And we've now settled on it, so it's a bit difficult to displace.
Wrapping version control with a non-tech-friendly porcelain could help a lot of people escape user domestication from vendor lock-in.
Luckily, that responsibility is not in my wheelhouse, I just have to live with whatever decisions are made.
So yeah, mass adoption in the consumer space, I don't see that happening.
A revert or a rebase gone wrong and wails of "what happened to my file?"
Then I switched jobs to avoid touching .docx files ...
The best alternative I've found to generate .docx output is R markdown, which uses pandoc under the hood and let's you program the whole document the way LaTeX would.
docx and epub are zip files, you can rename them with a .zip at the end and open to see what is inside. It might not be as simple to zip them back, at least for epub is very important to zip the files in a certain order but I forgot the details, but is easy to do from command line.
The xml will probably need to be run through a formatter to be readable. You can type `:%!xmllint --format -` if you have xmllint installed.
Now prepare to spend several hours trying to make sense of the xml. :-p
Definitely binary once compressed, though, and even when extracted not an easy format to parse. It might be XML, but it’s still representing the full complexity of an MS Office document.
I do the same with markdown in Zettlr, which has a nice inline-preview format and can be used by my non-tech partners.
The generated .docx has a limited range of styles, but we see that as an advantage.
And all tracked under CVS with a management/tracking layer on top.
# make command_doc
and the pile of text became a lovely 250 page postcript ready for the laser printer.
AIUI, git is already prepared to be that, it just needs diff programs that can handle whatever format. I mean, other than git's interface being its own impediment to non-technical users.
It's not proprietary by definition. A nightmare to implement? Yes.
But definitely not proprietary.
And there you go, a human readable diff.
[0]https://github.com/benbalter/word-to-markdown
iirc this was the original pitch for Dropbox
> “Git for everything“ would be a multi-billion dollar startup easily.
Dropbox is valued at 8.5 billion
I like Dropbox, but for documents, 30 days worth of version history is not fantastic.
[1]: https://help.dropbox.com/files-folders/restore-delete/versio...
https://news.ycombinator.com/item?id=8863
From Sep 15, 2008: https://www.maketecheasier.com/dropbox-backs-up-and-syncs-fi...
Version control with online MS Office and Google Docs seems to be going pretty strong.
Google docs has a similar feature built in too I think.
First thing I do on a new device is setup my mega shared drives - and there is a lot of plaintext files there!
https://news.ycombinator.com/item?id=17732912
I feel like building a Google docs clone for simple text files. Just one feature - versioning (A Time machine like interface) and perhaps add collaborative editing later. I just want to write and store a text document without having to create multiple files. Automatic versioning of snapshots so I can go back in time and refer to any timestamp.
So, uh, yeah I agree absolutely with you.
https://github.com/ben174/bugben
Custom LaTeX classes made this more trouble than I was willing to deal with, so I decided to not pursue it further. I suspect Markdown might have similar challenges dealing with this, although given that the "verbose mode" is just HTML, I might be able to make it work.[1]
The print media type has been around for eons, but the @page rules don't support everything I need and are generally absent in WebKit browsers.
[1]: https://github.com/chrisfinazzo/resume
How do you merge destructive edits to image files?
I love some of the collaborative nature of Microsoft Teams and CRDT editing Word/Excel, but I'm usually pretty remote. Text over a tenuous WAN connection is ideal.
I work at a government agency and I was /just today/ getting them to review and approve Git and VS Code for our staff use - and pandoc. A couple years ago we never would have gotten open-source software approved. I wish I knew of an equivalent to SELinux or AppArmor for Windows so they could lock down things a semi-trusted application can do. VS Code will be used in a few different departments, but I mostly want it to help those unfamiliar with Git and its CLI (Git Graph is nice).
There's a trick out there to first convert things like Word documents to Markdown, and then do a diff of that intermediate output: https://hrishioa.github.io/tracking-word-documents-with-git/
Pandoc can only do so much. I'm trying to convince my part of the gov to put policy documents we disseminate to staff in a git repo, so we can track who did what and why (based on commit messages). This will be a big step, but thankfully one part of our org is already moving toward version control for IT and data analytics so I'm proposing this and suggesting we hop on their bandwagon. Momentum.
There's a Word template that we commonly use for legal purposes where it gives you line numbers and you write text to align with the numbers. When reviewing it's easy to say "change line 23 to read ....". This - for example - will not translate well through pandoc because the numbers and the text are separate text elements.
There's a market for making pandoc better. Visually translating how elements "flow" from 1 format to another, instead of simply transpiling XML to Markdown.
I'm still excited thinking in a year I might be able to git-blame the legal department for things. Or see a diff from 1 administration to the next.
Some thoughts:
1. Policy makers think they write policy in English (or other human language). But more and more it is the software.
2. "policy engines" aren't going to cut it - we need to introspect code to decide what the code does - and translate that back to policy.
3. at my work the best solution i have got is using unit tests to explain what the policy is based on test comments - and again that's using english and again it's terrible ("best")
I think the real solution is both wider software literacy so that discussion happen "in code" and code that is more like policy (composable functional languages are thus likely to be useful here)
But great to hear you are taking any steps at all - would an HN letter writing campaign to your ministers help?
So you won't have a neat revision history, unless you implement something in the pipelines to also convert .docx to something human readable, because .docx and OpenXML isn't.
In an office environment, modern MS Word gives you a really nice version history, with automatic or manual/named versions, plus multi-user simultaneous editing, with a slick and fast UI. It’s even cross platform - I send a coworker a link to a document, and they can open it and work on Word for Windows while I edit the same doc on Word for Mac or even on the web-based Word.
It’s shockingly good.
While some of the ideas are great, the overall experience was pretty bad. Leaving autosave on often slowed down Word to an unworkable pace and after a few other issues (I'm not exactly sure what, wasn't involved) we just made sure only one person at a time works on the document.
Some other annoying small issues I experienced: when working together sometimes your undo history is gone. I guess that's because someone else edited too and correctly undoing something someone else edited in between is not simple. IMO it's impossible and any system doing merges automatically will fall apart at some point.
Track edits cannot track deleting rows of a table
Wed based word works actually pretty fine, but it misses random features. Adding captions seems not to be supported.
It's the little things...
I use it every day and really haven’t had slowness issues, even when running via Parallels on the Mac side. Of course, typically my docs are <100 pages and light on images.
I have seen undo history go away when edits collide with multiple users, but that’s really the only way it could work. And you can still view old versions of the doc if you need to retrieve/restore something.
MS Word as a whole is definitely very far from flawless, but it’s still better than the alternatives I’ve seen, and it’s extremely entrenched. That’s why it’s hard to see “git for office docs”succeeding.
~250 pages, ~100 images, not something I expect a modern computer to struggle with. We used the web version on Linux sometimes, but I think it also happened when we didn't.
>I have seen undo history go away when edits collide with multiple users, but that’s really the only way it could work. And you can still view old versions of the doc if you need to retrieve/restore something.
The other way is like git does it, manual merging and conflict resolving. I don't think there's a way around that once you work with enough people together on a file.
Personally for the kinds of documents I work on, I'd rather risk losing my undo history than have to deal with manually merging changes from multiple users.
Plus, without real-time concurrent editing, the changes are much more likely to conflict.
Most of what bothers me is trying to view, read-only a previous version. Usually I have several Word or Excel documents up on my screen, and it's easy to begin modifying a past version that then becomes the latest. It's not reflex to open a previous version and untoggle autosave. It bites me all the time.. In Office's pursuit to help people avoid losing data, I wind up overwriting what I need to preserve. A lot..
I have not seen manual version names in Word doc history. Maybe I'm sheltered :s
In my experience it starts to creak on large documents with multiple editors. I did a project many years ago where the key deliverable was a large report, worked upon by 3-4 contributors over 12 weeks.
That last week was absolute madness. Document got corrupted, and we tried all sorts of things. We ended up importing the corrupt document into Google Docs, which, oddly enough, did a better job of working with a corrupt Word document than MS Word did.
It doesn't help that there are lots of versions of online Word - there's the one that lives in Sharepoint, the one I get to via Outlook, the one in Teams, and (maybe? somehow?) the desktop Word when editing an online file.
These features are nice and all, but the thing is, most users not only don't care about using them, but don't care about even the idea of them to know they exist, so they continue with the old workflow.
Most of the time its better to get out of the users way, but in cases like this, if you truly do want to get rid of the infinite finals, they need a bit of a nudge
Microsoft word can't even open files from old version of the same software.
None of these word document will be readable in 50 years from now, a text file though.
macOS Time Machine and Windows Shadow Copy aren't perfect git-based versioning systems, but it's nice something in the general direction exists.
https://en.wikipedia.org/wiki/Time_Machine_(macOS)
https://en.wikipedia.org/wiki/Shadow_Copy
When they introduces this they changed the standard file operations and replaced "Save as…" with "Save a copy" - this was not universally welcomed.
Worked on a “Git for Word” project [1], which is currently on hold.
The diff part was manageable, though not trivial to get diffs that make sense for prose/regular text.
The hard parts are UX/UI (making Git concepts transparent to “normal” users) and merging. Yet without automatic merging, branching is not very convenient.
Would love to collaborate on this in the future again. Reach out if you are working in this space, happy to share.
[1] https://julesdocs.com
Sourcetree is the best git GUI I've used. That could be used as a model.
I think an old-style solution to merging would be fine: output a word file that uses a unique font style to indicate which user made what conflicting changes, have the user edit the document and remove all of the "merge styles", then continue.
Just to show how useful this is here’s Indian Constitution with amendments as commits:
https://github.com/anoopdixith/TheConstitutionOfIndia
From what I've read, Pijul should fix at least the problem of needing to resolve the same conflicts multiple times over and over again. However, I feel that version control focused on text breaks, because the merging algorithm doesn't know anything about the semantics of what's represented in text. So yes, I'd say that version control in more areas would be nice, but one based on binary formats understood by version control. One glimpse of that may be KeePassXC, which can merge password databases and has never done it wrong in my experience.
In my opinion, the following configuration should have been the default with Git:
The `enabled` part means: transparently record all resolutions in a database, and re-apply them whenever bumping into the same conflict with the same pair of files in the future.The `autoUpdate` part means: every time you finish re-applying a recorded resolution, please `git add` the result automatically for me so I don’t have to look for a "conflict" that’s actually no longer there.
I don’t see how that is guesswork. My impression is that rerere is perfectly deterministic, and only repeat things the user has done before.
The downside is: once the user has manually created a faulty resolution, then rerere will possibly replay that faulty resolution.
That’s how things can go wrong, and I see how one might blame that failure on rerere itself. And I think the blame not entirely unjustified, because rerere could do a much better job in explaining how it interacts with certain scenarios. For example, let’s say I’m aborting a rebase. Will rerere roll back the resolutions it recorded? I honestly don’t know. The manpage vaguely claims that it will, but I’ve been unable to reproduce it.
I wish rerere made more transparent how it interacts with `--abort`. Just printing an informational line would already go a long way. I also feel a command like `git rerere log`, which would print the recent activity of the `rerere` database, might help with that.
Really? One new added line, and one delete/add two lines above it.
it usually works fine, it really does, but when it messes up, it really messes up big time. As long as it doesn't create a conflict, you just shrug and move on, but when it does create a conflict, holy-moley!
But no, people always seem to insist on that linear history is the only concern that matters, explicitly delete the history, and then wonder why Git is so annoying and easy to screw up.
Maybe Git should have locked rebase behind a feature flag of some kind. `git pull --rebase` should certainly never have been added.
There are many reasons why linear history is important. Rather than saying that "you shouldn't want to do that", I'd prefer it if the tools people use were fixed to better serve the things people actually want to do.
A merge would only make sure that I don't need to resolve the same conflict multiple times. It wouldn't result in the conflicts not being generated in the first place, or them being saner. The only difference in conflict resolution between rebasing and merging is that the sides are flipped (what's shown on left in rebase, is on the right in merge, and vice-versa). Which doesn't address the second issue I listed: conflicts are not only repeated, but the conflicts themselves are pretty crazy. In my example, often-times C would never even touch files which were detected as having conflicting changes with A or B. It was pretty absurd that I would have a 3-line change in C, several hundred-line changes in A and B, yet the biggest conflicts would be triggered when rebasing C on top of B, and those would be in files C did not touch. Other times diffs in conflicts would have most of the lines added and removed actually identical, with only a couple in the middle different. Why would git mark them as conflicting, is beyond me. And then there was the issue of git not detecting conflicts, when it should have, instead merging changes in a way that broke source code. None of those issues is better handled by merging than by rebasing. Most of them however have pretty good solutions in a patch-based version control system, as opposed to snapshot-based like git (conflicts in files which weren't changed? not going to happen). An even better solution would be binary formats with domain-specific merge logic, like the one in KeePassXC.
No, you just add it at the end of the commit chain?
> And rightly so: when I look at the master branch, I don't want to see random corrections someone made during review, they're just irrelevant once the reviewed changes are merged.
git log actually has the --first-parent for this, which hides all of the commits that were merged into the branch, without destroying the history when you try to go back and try to understand why the choices were made. The idealized version of history created by constant rebasing serves neither purpose.
> Rather than saying that "you shouldn't want to do that", I'd prefer it if the tools people use were fixed to better serve the things people actually want to do.
Agreed, tools that cope poorly with merges should be fixed, rather than forcing people to hack around it by rebasing.
> None of those issues is better handled by merging than by rebasing.
Not quite, rebasing generates more false positives, since it tries to merge every intermediate commit instead of only looking at the end states and the common ancestor.
Pijul doesn't, by the way, the diff algorithm is customisable. I wrote one industrial application of Pijul that uses spaces as breaks, and semantics-aware breaking is totally doable.
Which is the next thing. Git works just local and uses servers to sync. The purpose of servers is syncing and not depending on them. From this everything else comes, autonomous usage, speed, reliability, recovery.
Didgets (recently surfaced here on HN) seems like a sane approach to this, from the file system up. Pretty incredible performance too.
https://didgets.substack.com/p/where-did-i-put-that-file
Sadly not (yet) open source, though the developer is considering it.
[1]: https://github.com/benweet/stackedit
http://www.oilshell.org/blog/2022/02/diagrams.html#text-narr...
https://news.ycombinator.com/item?id=30483914
It's generally not something you want to reimplement ...
Most people have no issues navigating a full folder of revisions to get to “Report Final Final draft v3.docx” but anything resembling version control would simply be unused. At corporate level, the version features of box.net, egnyte, and others are rarely used. I'd say most people don't even know they can navigate the revisions until they are in a data loss situation and asking about how to recover a corrupted file (which occurs most frequently with Excel files in my experience)
Proper notetaking app, can show images inline (but stores the note and image as a plaintext file and a normal image file, the text file just has a line for what image to show like:
/Notebook/Attachments/Bill.png
/Notebook/Notes/Bill.md
Bill.md contents:
Went to restaurant and got this for the trouble:
![[Bill.png]]
They have a full features mobile app and sell an end to end encrypted sync service for the app. It's as good as it gets, IMO.