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.
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.
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 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.
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 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?
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.
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).
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.
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.
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 :)
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.
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
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.
> “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.
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.
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.
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.
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.
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?
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 :)
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.
> “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.
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?"
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 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).
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.
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.
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 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.
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.
"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 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.
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.
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!
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.
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.
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 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.
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?
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.
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.
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.
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.
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)
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.
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
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.
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).
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!
Plain text adoption often implies markdown for a richer experience, but we also have the wonderful https://orgmode.org markup.
There is no shortage of markdown-based tools on all platforms. Our org markup options, on the other hand, are very few outside of Emacs. Org markup itself is super versatile and can power lots of use-cases.
I've been intensively using Orgmode for a year and a half (wrote my thesis in it) and then abandoned it to switch to Markdown.
Orgmode quickly turns into not-quite-plaintext with humanly impossible to read and very distracting data structs stuck inside the text. I think these were called "Properties"?
For me the beauty of plain-text is that it can be read and written in any Editor without needing syntax highlighting. Here Orgmode fails for me, as I found it unreadable and unusable without an Emacs-esque toolkit.
Yeah, I agree. I use org, but if I'm writing a document I'm in Markdown, not the Org markup. It's just noisy.
Emacs partisans are often very, very sure that the emacs way is always the best way, sort of like evangelicals. (And I say this as a guy who has emacs and orgmode open all day, every day.)
That's a fair gripe, as an Org-mode+Emacs user. I certainly see the clunkiness you experience in its structure. But for me, I find it highly unlikely I'll ever use an editor other than Emacs for anything but basic and quick editing. For things as comprehensive as to necessitate writing in Org-mode, I'd rather do it in Emacs anyways. Need to port it to another editor? Two options: Org-export it to a more portable format, or get started on a comprehensive integration for Org-mode in the new editor.
I personally would be willing to put the time into developing Org-mode functionality on-par with Emacs, in a new editor, if the new editor were to have major advantages over Emacs. But I don't think I'll come across one for a very long time.
The kind of “data-rich” org file you don’t like would presumably be impossible in markdown. So what are you gaining at all? Just don’t write such data-rich org files. That’s totally under your own control.
I wouldn't call those plain text, if it doesn't keep your newlines by default, it's not plain text but a markup language like HTML
BBCode is nice and keeps newlines, but something that uses markdown's syntax for bold and titles, but doesn't remove newline characters, would be ideal
As someone who lives in a terminal, I find @junegunn’s “journal” markup format a lot more pleasing to the eyes than Markdown — holy kaleidoscopic colours, batman. Bonus: in a weird way, the colours of journal trained me to love lisp.
@xenodium
Wow - impressive reviews for your ‘plain org’ app.
When I grow up with my eMacs and org usage (I’m only playing now as org is new to me - but I know it’s what I have been missing!!!) I for sure must give your app a shot for iOS usage
>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.
I disagree with the whole "NEED VISUALS OR GRAPHICS?" section. I do need visuals! I do need graphics! I'm not a typewriter, why must my flow be interrupted with me having to leave my document to open some JPEG file whenever I need to show something that isn't text?
It's not like this is crazy difficult or requires proprietary apps either. Writing a modern browser may be an impossible feat but I'm certain that it would take just a day or two to get a very simple barebones HTML renderer which supports <img> and a couple of formatting options.
At this point I wish we had a tty which supports variable width and size text and inline images and video. Then I could be happy.
It's 2022 and people like the blog author are all "who needs screenshots? who needs audio? who needs colours? who needs fonts or styles? who wants to see their handwriting strokes? who needs metadata? I use text because it's 1970!".
Hello? 4K video in my pocket, structured data streaming out of every system around me, all I'm supposed to want to capture is plain text? What a paucity of information, of detail, what an absense of dreaming, what a position taken purely from fear - never have nice things because you might lose them one day!
So when you need to remember a user/password combo for a new device, offline doorbell maybe, or a parcel number, or the address of a friend, then you record a 4K video instead of writing it in a text file?
Some good points here. In defence of the original point, you could extend the "plain text everywhere" to "open formats, as text-based as possible" and keep the spirit. I'm personally in the "markdown for most things, with inline images" camp (with regards my own notes).
This one caught my eye tho:
> Try plain text sheet music vs actual sheet music.
Conceptually, "sheet music" *is* a plain text of music.
I accept that technically it would need to be implemented very differently as we haven't got ASCII or UNICODE for sheet music (AFAIK). You could probably do it with an XML language, or at a stretch YAML, and it'd be close human-readable and still vaguely plain text.
> No it doesn't. Try a plain text description of an electronic circuit vs a circuit diagram.
Maybe it's just me, but I do this at work all the time. I create build sheets out of just plain text before I fire up the circuit simulator, so I've got a good mind map of it and something to refer back to. Granted I'm not dealing with advanced circuits, it's usually industrial machinery and motor control, or at most a simple digital timer circuit, but I do just fine with plain text for something highly technical.
> No it doesn't. Try a plain text description of an electronic circuit vs a circuit diagram.
I'm not an EE, but there's SPICE for regular electronic circuits and SysVerilog et al for logic circuits. Math can be typeset in LaTeX, though its plain text readability depends on the formula. Category theory diagrams can be written in a simple language. Sheet music is some sort of XML, though I imagine there could be a more human writable/readable plain text format for this too. There was also a recent post about Markdown diagrams. And of course, code is still entirely text.
Much of what you mentioned can be described in a concise, portable text-based language. Though these documents are readable as text, they can be further rendered for best readability. Luckily, many can also be live previewed.
> there's SPICE for regular electronic circuits and SysVerilog et al for logic circuits
Both are inputs for programs, not actual representations for humans to work with and -understand. Try and design or better yet fix actual hardware with a SPICE netlist or Verilog program, good luck with that. Different use cases require different representations and the world doesn't just consist of software.
> Category theory diagrams can be written in a simple language
Category theory diagrams are not curves or function plots.
I get the feeling that you are confusing file formats with representation.
If I need external software to actually render the input (which can be binary or text for all I care) into a human-readable and -consumable format, what good is text?
What's the "readability" of an SVG, LaTex, or worse - MS DOCX - document?
How is this:
Example netlist
v1 1 0 dc 15
r1 1 0 2.2k
r2 1 2 3.3k
r3 2 0 150
.end
> Try a plain text description of an electronic circuit vs a circuit diagram.
It’s called a Hardware Description Language. According to my textbooks, they’re the industry standard. My personal experience certainly prefers them to unusable “diagram” drawing GUIs.
> Try a mathematical plot vs plain text tables.
You can do plots in unicode. And more importantly, the code that produces the plot is plain text.
Pretty much anything regular can be done better with a plain text source that subsequently compiles to more visual mediums.
> It’s called a Hardware Description Language. According to my textbooks, they’re the industry standard
So when confronted with a faulty circuit board with multimeter in hand and bench power supply on stand-by, you are looking at VHDL like this
Library ieee;
use ieee.std_logic_1164.all;
entity mux is
port(S1,S0,D0,D1,D2,D3:in bit; Y:out bit);
end mux;
architecture data of mux is
begin
Y<= (not S0 and not S1 and D0) or
(S0 and not S1 and D1) or
(not S0 and S1 and D2) or
(S0 and S1 and D3);
end data;
to figure out which components might be broken when there's a buck converter that gets no power or where the capacitor is located that should smooth out incoming voltage on a certain bus. Yeah, sure.
> You can do plots in unicode. And more importantly, the code that produces the plot is plain text.
So you're one of those people who don't listen to electronic music and prefers to read the parameters of the VCAs, LFOs and VCFs instead? After all it's just code that produces the sound waves in the end, no?
> Pretty much anything regular can be done better with a plain text source that subsequently compiles to more visual mediums.
And again we're back to data storage vs representation. I'm interested in the representation, not the storage format.
If you're one of those geniuses that can squint at a quintic formula and say - yep, there's a local maximum at about x=-9.7513, more power to you. The rest of us prefer a curve.
This is where Org-mode succeeds over Markdown. Inline image support adds a whole new level to plaintext markup.
Sure, you could implement an inline-image-viewing ability into your editor for Markdown, too, and I'm sure someone's done that for Emacs (maybe it's a default feature I haven't enabled), but that's the vanilla functionality for Org-mode. Not a secondary-layer afterthought.
Which makes you require software again, so what's the point exactly?
A cool idea for a logo stored as SVG cannot be visualised by a human, neither can text data rows of a CT scan or a stress visualisation from an FEM or FEA simulation.
What you call "merely a visualisation" in many cases is the data you (as a human being) are actually interested in; the storage format is an implementation detail and I'm very surprised how this clear distinction seems to be ignored by some.
I often see a serial number on a device and take a photo rather than typing on a phone keyboard. Or use software which blocks clipboard functionality and take a screenshot instead of typing it out, yes. OneNote does character recognition on all images and makes them searchable. If a doorbell or key safe has a keypad and I need my computer to look up the code, what difference does it make if the code is text or photo of scribble? Because one day my computer might forget how to open bitmap files? How likely is that? The safe will have turned to dust before all software which can read JPGs is lost to history).
> "Plain text just works, everywhere, all the time."
My point is not "text doesn't work", but it would be good if other things worked that well and there's no good reason why they can't. You don't eat plain oatmeal for every meal because it works, and shun restaurants because one day they might close. You don't plug your ears because you can read lyrics and sheet music and one day you might go deaf. This is like the "first class functions" of programming. Wanting first class functions is not saying that plain loops don't work, it's saying that more powerful things are desirable even if they aren't cross-language compatible.
I mean you could also just use Markdown. Put the image in the same folder, so you don’t loose it, and then use a relative link from your text file.
If you are using a markdown viewer it should render nicely, if you are using a text editor there is just a path where the image should be, so also no problem.
Some editors like Typora can be configured to automatically save images next to the markdown file, which is really helpful.
> but I'm certain that it would take just a day or two to get a very simple barebones HTML renderer which supports <img> and a couple of formatting options.
> For example the img tag allows you to, amongst other things, render an svg.
I don't think the GP meant "write an image renderer" when they said "get a very simple barebones HTML renderer". Most languages have libraries for encoding/decoding images in various formats, so aside from how it would fit into document layout, this is a non-issue.
What I said right before the part you quoted was "Writing a modern browser may be an impossible feat" and the part you quoted talks about a "barebones HTML renderer". What I'm describing is labels and images in a VStack. This is something any operating system UI toolkit (open source ones too!) can do.
> 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 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.
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 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.
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 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'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 came to this realization a few months ago as well. I had been using one note to keep notes and it got glitchy between devices, causing things to not appear. I’ve had multiple random losses of data like that.
Word documents and other special formats always break in different versions or operating systems. Or they get corrupted. Or they can’t do some basic feature like side by side comparison.
Apples note app deleted all my notes a couple years ago on some version update. It was apparently hidden somewhere in the terms of service. It’s impossible to get those back or rollback. Everyone on the internet says it’s my end user fault for not reading the apple TOS standard popup before pressing the default ok button one time.
There’s just an endless amount of problems. I put everything in text files in a set of folders now to sort it instead of tags that break, and nothing gets corrupted or loss. It also of course just syncs to google drive for version and backup.
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.
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 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.
As he shows at the end he is clearly writing some mixture of HTML and some custom language that he uses to parse title, tags, and date.
I do agree that unless absolutely needed you shouldn't tie yourself to proprietary formats, but unless you are writing simple notes you probably want more functionality out of your files than actual plain text file can provide at which point you should instead use markdown.
Code I write, be it python, php, HTML or JS is still plain text as a format. I can open any of these code documents in any dumb text editor.
The fact that some other tool can do more with these files, parse them, execute them, "extract" some logic from them isn't relevant to the fact that I can open, read and edit these files as a pure and plain text file.
Therefore adding parsable parts/logic to files like YAML headers (or any self created style) doesn't make these files 'non plaintext'.
Following your logic would mean that doing any markup in a text file would make it somehow 'non plaintext'. I remember old Readme files with headlines being underlined by adding a new line full of - - - - (dashes). And stuff like this. Because these could theoretically be used to parse the files and extract headlines from the text.
Then the whole article loses all of its meaning. If you find yourself writing Python in Word something has gone so horribly wrong there is no saving you.
Just use the good old file program and you'll see that in any coherent world we classify python, php, html, and js files as different from actual plain text files.
This very much feels like you are trying to argue tea is same as plain water.
Interesting interpretation of my words. Or should I say projection? Nothing to do with what I said. But if it pleases you. I am fine being an incoherent and unsavable something.
As said. There is no technical difference between a txt or a php file. I can both run through cat and grep stuff.
Are there special programs that interpret the contents differently? Sure. The same with the difference between a php and a py file. Different interpreters doing different things because of different definitions how to 'read' the content.
All pure text, just different languages.
To borrow from your metaphor:
One is Earl Grey. One Darjeeling. One might be Green Tea. One (God forbid) herbs as tea.
Open up a word document (.docx) in hex editor (head -80 foo.docx | xxd) and you'll see it's not a plain file on a binary level. Now do the same with any python, php, html, and js files and you'll see that they're plain files.
That's the difference that Derek is talking about.
That makes the article extremely silly, actually almost pointless.
If you don't see difference between plain text files and text files then that's pretty much it for this conversation.
EDIT: just to hammer this point home; if you gave me a task to write a report in plain text and I delivered a .txt file with some custom markup language, would you consider the task to be completed satisfactorily? I wouldn't. You can argue that the specification of the task didn't exclude custom markup language, but any sane person would understand what plain text file means.
Why not. If there is a tool like pandoc parsing and translating your text and markup to anything (html, pdf, word docx, etc). Why not. I did that quite often at a former job.
All version controlled in git.
A few markup headers. Text formatted in markdown. Later combined with a bit of templating logic to ensure different looks (one for client and one for agency) when translating it into the final designed report.
Actually more efficient than creating the two target documents with design from the beginning as the reports quite often changed in structure while being prepared due to changes in requirements.
Separating content from (re-)presentation was a time saver.
You can also version control Word files. That’s not an argument. Apparently plain text is anything and everything. What makes docx file not plain text? You can still edit and view it with your text editor it is just harder.
If you don't see the difference between proprietatory format like docx and you argue that just because I add double-asterisk with a word in-between then suddenly it's not plain-text file (since it's markdown markup at this point) then yeah, this conversation is over.
By transforming file Foo.docx into file Bar.b64 you get a plain-text file (Bar.b64) but Foo.docx still isn't plain-text. That's actually how email attachments work (transforming any file into b64 plain-text file), so I think your counter-argument is pointless.
I personally use literal plain text for note taking. Previously I used One Note and other stuff, but when I saw how I just store plain text there I grew suspicious that something isn't right and indeed couldn't find a reason why it can't be text files in my text editor. In addition to that my text editor already has best text rendering settings I spent time tuning, and text editing functionality I'm used to - that's the functionality I expect from note taking software.
I'm puzzled, how people use markdown? For what? Just to make text more formal?
Another advantage layers on the source control: many source code management services will render your markdown and give you a search interface. GitHub popularized it. But other hosts like Azure Devops and GitLab support this as well. You can make a relatively pleasant document management system on top of this.
You can even run this on your own computer without an internet connection. Working Copy on iOS supports. Gollum, originally created by Tom Preston-Werner, strives to be compatiable with GitHub's wiki feature [2]. For my part, I've been learning Rust by writing a clone of Gollum called Smeagol [3].
Though really the point of the original article is: all these tool don't matter. Your plain text files can live longer than any of particular tool and continue to be useful.
Use Markdown. There are zero disadvantages when compared to pure text files as it's plain text but with syntax and extra features on some text editors.
The main advantages of writing plain text files:
- source control
- view/edit anywhere
- doesn't get deprecated (Lindy effect)
- easy to share
- small size
There's no reason to use suites like MS Office and Google Drive unless your team is routinely using it or you need a WYSIWYG editor for publishing. Google Drive sometimes is bad for collaboration, user has to open link, login or install app compared to just sending the damn text. And, for the latter, just do all the creative writing in plain text and later format it or you will lose countless time fixing text formatting.
One issue with Markdown is that there's many flavors with subtle differences in parsing/interpretation. If you're looking to be able to parse the file in the future, you have to be careful to pick a flavor with wide support or to stick to the most common features of Markdown.
For several years I was an avid notepad.exe + plain text files practitioner for capturing any note but have switched to using https://notable.app for capturing any adhoc notes.
It has the same in spirit & benefits of maintaining plain-text .md files in a static directory but has all the niceties of rich markdown, embeds, attachments, search and metadata captured in .md frontmatter to organize and tag notes with categories + pinned notes in a minimal, focused UI. I've tried many note taking apps but it's been the only that's stuck & replaced notepade.exe for me.
notable seems a lot like zim. I see Notable has (or will have) a paid subscription plan, on-line features like sharing, cloud synchronization, and encryption, but I didn't see a privacy policy anywhere.
Privacy policy for what? it just writes static .md text files to your local folder.
The feature for built-in synchronization was proposed by its Author in 2019 [1], don't see any recent activity on when it will be available, it just says it will be opt-in via a paid subscription.
there are benefits of writing in the text files and still people keep going to these shiny editors/systems. Why?
Keeping the excitement of using these things aside, they do make things easier. After using backlinks now, I don't think I can go back.
I like how easily I can publish Notion docs.
I like how I can use mems[1]-- they have reduced the conginitive load of writing in a sublime doc.
So, maybe we should try to find a solution which gives all the benefits of these "innovation" happening in this domain-- I say innovation with a quote cause I know how gimmicky they could look as most of them are but some of the features are actually part of the evolution.
logseq, obsidian are the steps in that direction.
I wish all these companies start addressing these issues. And in general we start having the culture of "bring your own storage" i.e get all your data in usable way. Not some text/json files which need specific programs to get anything useful out of that. A graceful exportation should be the primary feature.
People keep coming back to shiny editors/systems because their employers demand it. Offices tend to like Word, as do book publishers. Yes, Pandoc, Scrivener, etc. will output your writing in Word format, but not all writers and office workers are tech people. They go with the simplest compatible/allowable option.
At my company, we create complex Word documents that are frequently edited. Using a different format (ie, a marked up text file run through Pandoc or LaTex) is far more trouble than its worth.
Same applies for bookkeeping. Though my .xls will probably outlive most applications, I'm certain that the csv version is readable decades from now. CSV is a poor format, so I'm using a plain text ledger [0] (specifically: the beancount[1] dialect).
I'm quite certain that no webbased SAAS accounting tool will be around in decades. But I'm certain my (git sourced) foo.ledger files are readable and parseable for ages. And if worst comes, they are human readable, so I could even just copy it over, or parse it, manually.
Yes! I came here to specifically mention plaintext accounting
I'm also a beancount user. Having all of my data in plain text allowed me to write extra tooling so that I can generate higher-level reports than what beancount has built-in. (budgeting, cash flow, planning/savings, etc)
That tooling also has much faster parsing than beancount. Not a knock against beancount, just proving out the point about not being locked in to a particular binary implementation.
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 don't think it's necessarily ironic. I'd argue that the "success" of the mobile and web app paradigms are in large part driving the plain text movement. It's almost as if a tipping point has been reached, where the complexity thicket of siloed everything, hidden everything, subscription everything has pushed people in the other direction, more so than proprietary formats just by themselves would have been able to do.
GitHub flavored markdown will be around indefinitely as will SQLite and HTML.
ODT probably will be too.
It sucks that storing files isn't really solved yet. Plain text needs some external means of sync. SyncThing is finally getting good again with new Android 11 features, but for a while it was limited to internal storage.
And there is, unfortunately, no SyncThing cloud providers(First person to extend SyncThing with messaging, make it embeddable in other apps, and make a cloud service will have basically a universal backend for FOSS apps and solve a lot of issues).
There also hasn't been good tools to actually work with the text files till recently, because android always seems to be 10 years behind desktop. You were pretty much stuck just using text editors, sans indexed search.
Plain text is wonderful, but the ecosystem to actually take notes with it is just now catching up.
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.
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.
My single tool is a homemade tiny wiki, lambdatank, usable from any web browser and storing pages as text files. Instead of Markdown I structure pages using a homemade language, lambdatalk, a dialect of lambda-calculus, inspired by Lisp, a single syntax built on HTML, CSS, JAVASCRIPT, DOM, ... With which I can boldify "Hello World" writing {b Hello World}, I can compute the diagonal of a square rectangle writing {sqrt {+ {* 3 3} {* 4 4}}}, create functions, draw graphics, play with the Mandelbrot set, as it can be seen here: http://lambdaway.free.fr
So I totally agree with you, and my datas will be free forever.
Alain Marty
Yep. Plain text. Offline first. I pretty much consider markdown a form of plain text, whether or not that point of view is orthodox.
The only two other doc tools I regularly use are
a) completely human-readable plain-text hierarchical notebook with almost no markup in its stored format,
b) an html notebook, whose file format is largely human-readable w/markup referencing images -- png and jpg.
a) is gjots2. File format close enough to plain text to be indistinguishable. I sometimes write entries in gjots2 in markdown. I mean, why not?
b) is Zim. Nuff said.
I've played with recutils, and it's nicely done. But I don't want to think that hard, or be that organized.
If I know I want to organize my text and massage it a bit more, I sometimes use an old text database program by Carlo Strozzi called nosql (no, not the nosql the web crowd thinks I'm referring to -- it predates that. It's relational, plain text, but not SQL, and it just uses standard nix utilities).
If I need version control for plain text, the now ancient RCS program is something I seem to be able to re-familiarize myself with much quicker than I can with git.
Now having said all that, if someone asks me to write/format a Christmas letter for them, well, out comes Libre Office Writer and it gets saved in docx. Why fight the universe?
I was also looking for a way to better visualize text as a set of notes while still using markdown and .txt, then I came up with the idea "Sticky notes + Markdown + Tabs, All in one .txt file"[1].
It's nothing fancy, just a prototype using electron and vanilla javascript, but it might be useful.
I like to write text-files whose content is wrapped into <pre> -tag.
After the pre-section I add:
<style>
pre
{ font-family: Verdana;
}
</style>
Pre looks great in Verdana, in the default font not so great.
You might choose to add the style-definition inline into the pre-tag directly. But I like a very simple start for my text-files which is just the <pre> opening tag.
You can wrap parts of the content into other tags like <h2> for headers.
I think plain files are great but really I take notes from far too many places and I want to take notes alongside my browsing. Most of what I write is always in response to something but its a response I don't want public. It's a weird zone to be in.
If anyone is looking for a note taking app that's pretty brain dead simple, I made one. This is really more about note taking on websites rather than general note taking. I also like to think by focusing on just the notes and making it feature complete at this point means that it will last for a long time.
One thing I tried to do was make sure everything is exportable and that backups are on you to maintain. This way the data is always in your hands even when its in mine.
Maybe because I'm in the echo chamber but it feels like everyone's looking for some sort of knowledge base system to use. Is this something only devs care about or is everyone on the planet trying to keep their thoughts on hand.
I keep all my txt file notes in GitHub repos, works great for me. One thing I’m still trying to solve, taking new notes while I’m mobile. I haven’t found a good easy way to create/edit notes and commit them to git while I’m on my iPhone. The GitHub mobile app does not allow editing. The GitHub website does but it’s clumsy to use on a mobile device.
I have been using Working Copy[0] for this. It is super full-featured and the developer is super cool for making everything free for students through the
GitHub Student Developer Pack.
I'm a big believer in this, but I use https://bear.app/. It supports the Markdown format and can export to .md files, but it uses SQLite under the hood, I believe.
What's amazing about this is that your thought archive is now searchable (which is fast in bear).
https://fsnot.es - FSNotes is a native (~100% Swift) FOSS app which I believe is modelled after Bear.app.
I have been looking at it for sometime now, from a distance.
Very active development. Lots of options. But it still doesn’t seem as stable as I would like it to be.
Though sometimes it seems kinda all over. For example - it lets you set a storage and then another storage for “git” handling id you’d like to use it. Adding external folder doesn’t import the notes, it just shows a folder there. Sometimes restarting the app does the trick, or just removing or adding again.
So there’s sync option (iCloud only), there’s storage location, there’s external folder addition, then there’s git as well. I am sharing it here because many of you might like these many features.
I still believe it has huge potential and I’ll give it a more full fledged try once it has a more reliable and transparent sync option unlike what iCloud sync is (my biggest gripe with iCloud sync is it doesn’t let me choose where I want to see/keep the raw files and there’s no versioning and if there is I’m not. It fails not in silence but radio silence).
I'd never heard of fsnot.es. It looks great. I bought Ulysses ages ago on Mac because I wanted a performant, native-app markdown app that supported external folders. Unfortunately, shortly after purchasing it Ulysses went subscription only. I had no alternative, so I kept paying. However, I don't used any of the advanced features, and I'm really overpaying when I have no iPhone, don't use iCloud, and just do simple markdown. I'll check out fsnotes to see if it can replace Ulysses for me.
I have considered switching from Android to iPhone, but I don't know how I'd do notes on it. For work I can't use iCloud. I can only use my company's backup solution. Then for my personal notes I have Android and Linux (desktop), so I can't use iCloud, so I use syncthing or Google Drive. If I went to iOS, I don't know how I'd get my personal notes on Linux syncing with iOS. All the native iOS apps only support iCloud.
I use nvAlt for Simplenote on Mac where I chose to keep the file in text format in a Dropbox folder and it also sync to Simplenote server which easily makes the data available to mobile app. So Simplenote server does the sync between apps and since I keep the data in Dropbox folder the data is synced/backed up (I separately backup that folder as well) there as well.
(To be honest that works better for me than FSNotes' complicated way of doing this. I wish they had a way to do that in Mac app while still utilising invisible iCloud Sync; but without me having to specify a dozen places for storage, sync, external folder etc etc)
I've been in finance, consulting and private equity for 15 years before starting my own software shop.
Moving from proprietary, WYSIWYG formats (mainly MS Office) to markdown / code as a way of working has been a game changer. Traceability, scalability and productivity is an order of magnitude better.
One of the ultimate plaintext champions is (unsurprisingly) John Gruber, the "inventor" of Markdown.
One of my favorite facts about his site, daringfireball.com: You can add the extension .text to any permalink and it will render that page as markdown:
Not quite plain text files, but... I've used them all - Notion, Roam, [insert any hyped app of the past 10 years here] - but then in the end, when a random thought pops up that I want to write down I always land back in Apple Notes..
Whenever I need to write something longer than a small forum list I write it in Notepad++. I then copy the text into whatever editor I'm using to stylize it. It just seems way cleaner to write things in the editor that ignores style.
I also use sc (spreadsheet calculator), a terminal-based spreadsheet program which uses a plain text file format. Very convenient for dealing with tabular or numerical data, which would be cumbersome to work with on a textual file.
I've been using simplenote and kinda wanted to transition to plain text, the only thing stopping me is the mobile <-> desktop sync workflow which simplenote handles really nicely. Does anyone have any good ideas?
Glad to see another simplenote user in the wild! I’ve been using it for years, absolutely love it.
For me it’s not just the automatic syncing, but having a good app on all platforms that I really like using.
On my Mac, I also run a script that commits the simplenote db to git every hour or so and pushes it to Github. It's basically like a JSON file. So I don’t worry about simplenote getting shut down.
Obsidian.md stores your notes in normal folders and plaintext files on disc, all attachments as standalone normal files. The company offers a mobile app and an end to end encrypted sync service (paid).
The basic app is simple, but has a good extensions API which means people can and have gone nuts with it.
I was a big fan of zim, but I have to admit it's falling behind the times (search is poor, graph view not useful, no collaboration, no mobile, tags are second class etc) so I reluctantly moved away from zim to amplenote.
That's the thing though, I'm only interested in offline first free software. I see no point in paying someone for my notes and I'm not collaborating with anyone on them.
With zim everything it just text and folders, easily done manually if I wanted it on mobile, but for that I just use markor.
I’d say that it’s not necessarily plain text files, but some text based formats, preferably open. Easy to parse, read and improve.
I follow something similar here, but with a difference that I don’t do anything in closed or binary formats, except for images and such binary only things, that I use only open formats. It’s being working fine - I also have everything in a source control (moved to git, currently).
As someone suggested here, there’s no better way to see changes over time when you need to see a previous version.
--There will always be plenty of free, non-commercial software in the public domain for reading and editing text files
--Whether future virtual reality, or a chip you can implant in your earlobe, plain text will be there
--Maybe it’s just another distraction, focusing on the tools instead of your thinking
--They offer some convenience or features, but at the cost of flexibility, portability, and independence
This is why I still love my AlphaSmart Dana running CardTXT. I have done a lot of writing with that machine, and it has never let me down. Even if it did, I could just swap out the SD card.
I've lost some old documents due to missing support of old file formats. I guess it would be possible to find some converters, but then again I'm too lazy to perform research on this topic, it is just like I'd like to look in one of those old documents from time to time (more personal history than actually important). So I tend to agreee with the approach of keeping things simple.
However using a note taking app that operates on plaintext (markdown) files like Joplin could be a good middle ground.
Agreed ownership of your notes is imperative. You do need some structure though. Try Logseq. I adopted Obsidian after Roam, but missed the low friction structure that Roam offered. But Roam was not secure and was proprietary. Logseq is the best of both worlds, is plain text based with minimal structure (markdown-ish) and is Git friendly. It's a work in progress, and needs a few files adding to .gitignore to minimise merge conflicts (pages-metadata.edn for one).
I think the easiest thing to write in is markdown. It allows you to define chapters, sections, subsections, lists, italic, bold, ... so all the basic things most of us would like to have anyways. It's very easy to read without a markdown renderer as plaintext for yourself and for others. You can automatically convert it to HTML, create a presentation, create a book, all quiet easy.
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.
Considering that every browser, OS and printer has a reader implementation, and there is a spec defined, surely this makes it on par with plain text?
You could use any document editor (Word, Pages, Apple Notes etc), and as long as it can export to PDF you are no longer tied to the note taking companies proprietary software for reading and writing. Future indexing systems will surely support PDF.
PDF is explicitly designed as a final output format (and PDF/A is explicitly designed for archival purposes). They're good for that purpose, but it's literally like storing the digital version of a printed copy of a document rather than the source. That's fine if your only goal is preservation for reading, but preservation in a format that can be edited, converted, transformed, etc., lets out PDF as a target.
I was just thinking about this at the weekend. One approach is to use a tool that supports [[Wiki-style Linking]], and have a kind of index/table of contents/home page for your notes.
That's what I do today in my own app. I have a "table of contents" file in each folder. Ideally the file system would support that out of the box, but maybe a first step could be to standardize such a TOC file...?
In the system's file explorer (Finder/Windows File Explorer).
This would give me a visual outline and the ability to open any file with its corresponding app.
Imagine writing a book and using folders as chapters. You could then write individual pages with different apps, say some plain text, some Word documents, a few spreadsheets, images, videos, etc.
Perhaps I’m too young, but I don’t find most of my writing relevant years later. Amusing maybe. So I don’t worry too much about the current platform I’m using being obsolete. I do want the ability to back up to plaintext with a single click though. And I do stick close to plaintext for its focus. Bear is the best compromise so far.
As you age, your memory deteriorates and you have more experiences to store in it.
I have been keeping daily notes on my work for about 8 years. It's really really really nice for cases where someone asks me something about a customer or technology or solution to a problem and I'm able to pull it up with a quick search.
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.
Any advice on syncing with iOS? I use iA Writer, but the syncing experience is awful because iA Writer is waiting for some sync provider (e.g. Dropbox) to implement the full iOS Files API, which it appears no one has done. That leaves iCloud as the only option.
I like plain text for the simplicity. It's easier to find my thoughts and focus on writing when the editor is as simple as a rock, otherwise I'll spend hours fiddling with the settings. Typically I use GNU Nano for its lack of features.
Real question: what is the use case for viewing notes from 30 years ago?
Things that come to mind are evidence in a court of law and having fun looking back on old memories, neither of which seems worth the sometimes incredible amount of trouble.
Funny, I'm about to release my note-taking app which is plain text (xml) under the hood, handles heirarchy easily, and plays well with both version control (backups) and dropbox. Its windows tho... wanna try it?
Hijacking this article. But can someone reference me a "how to make Markdown look nice tutorial" I just have zero aesthetic intuition and would love some simple guidelines to follow.
> I’ve brought my text files with me since 1990, from Mac to Windows to Linux to BSD
> But plain text? Always. Everywhere.
Quite obviously you have your files in ASCII. Anyone who needs more than 26 letters (or god forbid non-latin ones) are fucked. Sometimes quite literally.
> Your writing should outlive you. Depending on companies is not an option.
ASCII? Sure. EBCDIC? Ughh. UTF... 8? 16? 32?
> 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
And you are absolutely helpless if you can't access your ASCII/EBCDIC/UTF8whatever plain-text files.
> Plain text can be converted into anything else.
Date: 2022.02.03
Is this March 3rd or February 3rd?
> NEED HIERARCHY
Sure. But in the year 2022 I want not only a hierarchy but crosslinks too.
> CONCLUSION
> Reliable
If you know the encoding. IF.
> flexible
See #date
> portable
See #date
> independent
Sure, but what about dates and encoding?
> and long-lasting
If on the suitable media. Good luck accessing your precious files on Google Drive when the mighty AI decided you aren't worthy to access them. Or your CD-ROM isn't readable because the last machine with working [0] CD-ROM compatible drive were thrown out 5 years ago because it can't run any modern OS[1]
> Plain text files will be readable by future generations, hundreds of years from now.
[x] Doubt
Real conclusion:
Sure, plain-text files are way better than binary blobs with unknown structure, but they are not a silver bullet. You still need to think about how, where and in what format to store them.
5/10, would not recommend.
[0] The last machine in my house with CD-ROM drive is X301 which is .. somewhere. My desktop's NEC-45xx was dead last time (6 years ago) I tried.
[1] CentOS8 performance with Gnome on ThinkPad X301 is abysmal to say the least. Even Windows 10 (!) runs better on it.
PS: to the kind person who bothered to downvote this comment: do you prefer your UTF encoded files with BOM or not? And your preferred editing software?
I didn't downvote you but your tone is overly dramatic for some simple heuristics. Specifically you're just repeating two things over and over. Here's some simple answers:
1) you're right that ASCII was English only, but now utf-8 is the defacto standard, backwards compatible with ASCII, and good for every language. Use that, no BOM needed and the BOM is discouraged by the standard anyway.
2) dates can be YYYY-MM-DD as per the ISO standard. Also they're sortable as a string too as a nice side effect.
Why can a vapid blog post from a famous person make the front page, but a serious, if slightly aggressive, response to it gets downvoted? Did everyone just want to circle jerk about how they too are just like famous person?
I think "vapid" is generous. The author seems to have no grasp of concepts like encoding, representation, and medium. And the other responses to the critical comment (not troll) quite miss the point.
I have a large amount of digitized data, including programs I first hand wrote on paper and then transferred to punch cards, poems written on paper and later typed in, photographs I've scanned, photographs I've taken digital photos of, scanned books and articles that contain text in various languages along with images, digitized music and videos, etc. Some of these consist of "plain" (whatever that means) text and some don't. I've been accumulating this data since the 1960s. When I think about my collection and the ways I manage it, and my knowledge of encodings, representations, and media, and then read this article, my most polite response is ... smh.
That said, I think there is a valid point in all that confusion, and it is stated by several of the comments on the article: use Markdown or something similar (but MD is usually the best choice) when you can rather than Word or other proprietary binary formats. But MD is not "plain" text.
Even if you don't want to use utf8, you can use any other text encoding, it's your files, nobody cares how you use them, do whatever works best for you.
Am I the only person who likes writing documents that are easy to read, easy to skim, and provide complex sets of data in a concise manner, including multi-media and hyperlinks?
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...
In French, there are various conventions around quotation marks ("guillemets") that may involve inserting non-breaking spaces (ideally, a NARROW NO-BREAK SPACE), depending on your workflow.
I agree. Google Docs is mediocre at WYSIWYG and interoperability, but boy does it solve long term storage. I don't have to worry about paying for Dropbox or having local files that I can't search quickly unless I am on a Mac with Spotlight or have full indexing on Windows or the Linux equivalent. I don't have to worry about the folder structure and the files can't vanish with an SSD failure.
And, unlike text files, it's easy to insert images and tables in a Doc file.
funny, I almost agree with using text - except my goto is Excel. All my thoughts, todo lists, etc always in Excel. I guess I like compounding numbers too much =)
> HTML, Markdown, JSON, LaTeX, and many other standard formats, are just plain text.
On this definition, Word and Excel are just (zipped) plain text files.
> Every device, including ones long gone, and ones not invented yet, can read and edit plain text.
This definitely isn't true, and it kind of misses the point that there's no such thing as "plain text". It's still encoded in ascii, or utf-8, and still potentially has problems being read on other machines.
It's reasonable to say that ascii has become so ubiquitous as to be universal, but it definitely wasn't always so, and won't definitely always be.
You can't be pedantic and then say Word and Excel are files. They're applications.
On a more serious note, ascii and nowadays utf8 are customarily considered plain text, the fact that a specific charset is used doesn't mean it's not text.
If anyone in this thread has a talent for writing that compares to either Homer or Shakespeare, then we're in excellent company!
The rest of us, who can't necessarily achieve the desired effect through words alone, need typographic assistance — much like how I would need a bicycle to keep up with Haile Gebrselassie.
Why not just use letters and avoid punctuation ... that's all Markdown is: punctuation.
> Homer was able to write the fall of troy and Shakespeare Hamlet without bold text.
Oh really? Have you ever seen a manuscript?
Unlike handwritten text, plain text doesn't provide a means to underline, use italics, subscripts and superscripts, etc. Things like Markdown provide conventions for denoting such things in plain text.
I'll just quote my own answer from elsewhere in this thread:
Even if such a device needs to be used, decoding ascii is a trivial lookup operation,
not remotely comparable to decoding some arcane binary format, or a convoluted XML-
derived format such as they are used in WYSIWYG editor formats.
Even if such a device needs to be used, decoding ascii is a trivial lookup operation, not remotely comparable to decoding some arcane binary format, or a convoluted XML-derived format such as they are used in WYSIWYG editor formats.
Yes, text relies on an encoding standard. So do numbers btw. (big/little endian, 2s/1s complement, sign/magnitude, floating-point representations), element enumeration (0 vs 1 based indexing) and even boolean logic (eg.: 0 is true in bash, everything else is false)
At the end of the day, computers represent only 2 states: On and Off. Everything beyond that, needs an encoding.
And some of these encodings are, at this point, both so universal and simple, that they can be considered as much a standard of the IT world, as 0 and 1. ASCII is one of those.
A Commodore 64 can certainly read ASCII out of the box since ASCII is just data ... I'm not sure that person purportedly building a Commodore 64 understands how computers work. And the Commodore 64 display hardware expects PETSCII, which is based on ASCII-1963 ... a few characters will be displayed incorrectly, but alphanumerics will be fine.
ASCII text is just byte data ... nothing has to be done to "teach" a Commodore 64 to read ASCII. Displaying it on the screen is slightly problematic because the Commodore 64 uses PETSCII, which is an older version of ASCII, so some characters will be displayed differently, but it's not a terribly big deal.
> that doesn’t mean that these standards have always existed, or will always exist
These are irrelevant "points". ASCII will still be in use when human civilization ends soon (possibly next week due to nuclear war, or else in a few hundred years due to global warming).
When plain text is zipped, it is no longer plain text and as such it does not take advantage of all the things that can be done with simple text files, unless there is additional tooling, which again unzips the zipped files. This creates some friction of course. General tools do not bother with implementing a knowledge about every format on the planet, so those zips stay zips and are treated as bninary data by version control, which makes them not too useful.
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.
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.
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.
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.
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.