Write plain text files
sive.rs
sive.rs
It’s something programmers take for granted, but it would be amazing if this got more widely adopted outside of tech. The number of files with names like “Report Final Final draft v3.docx” is truly staggering.
“Git for everything“ would be a multi-billion dollar startup easily.
In addition to plaintext documents, I have found that a simple JSON diff is also a very effective way to demonstrate changes between 2 complex biz objects. Non-developers can cope with this as long as the differences are visually obvious (red=removed, green=new, etc) and the object graph is reasonably flat. Everything can be trivially serialized to a JSON document, so this scales super well in my experience. We use a port of Google's DiffMatchPatch to generate human-friendly HTML reports of object diffs in our latest administration tools.
Git would be a byzantine disaster for 'everyone else'.
The graph and abstractions involved introduce enormous unnecessary complexity.
Now, 'historical changes for everyone' - yes.
But not Git. Git is very powerful, but ultimately a questionably valuable product in many cases overall. And we've now settled on it, so it's a bit difficult to displace.
Wrapping version control with a non-tech-friendly porcelain could help a lot of people escape user domestication from vendor lock-in.
Luckily, that responsibility is not in my wheelhouse, I just have to live with whatever decisions are made.
So yeah, mass adoption in the consumer space, I don't see that happening.
A revert or a rebase gone wrong and wails of "what happened to my file?"
Then I switched jobs to avoid touching .docx files ...
The best alternative I've found to generate .docx output is R markdown, which uses pandoc under the hood and let's you program the whole document the way LaTeX would.
docx and epub are zip files, you can rename them with a .zip at the end and open to see what is inside. It might not be as simple to zip them back, at least for epub is very important to zip the files in a certain order but I forgot the details, but is easy to do from command line.
The xml will probably need to be run through a formatter to be readable. You can type `:%!xmllint --format -` if you have xmllint installed.
Now prepare to spend several hours trying to make sense of the xml. :-p
Definitely binary once compressed, though, and even when extracted not an easy format to parse. It might be XML, but it’s still representing the full complexity of an MS Office document.
I do the same with markdown in Zettlr, which has a nice inline-preview format and can be used by my non-tech partners.
The generated .docx has a limited range of styles, but we see that as an advantage.
And all tracked under CVS with a management/tracking layer on top.
# make command_doc
and the pile of text became a lovely 250 page postcript ready for the laser printer.
AIUI, git is already prepared to be that, it just needs diff programs that can handle whatever format. I mean, other than git's interface being its own impediment to non-technical users.
It's not proprietary by definition. A nightmare to implement? Yes.
But definitely not proprietary.
And there you go, a human readable diff.
iirc this was the original pitch for Dropbox
> “Git for everything“ would be a multi-billion dollar startup easily.
Dropbox is valued at 8.5 billion
I like Dropbox, but for documents, 30 days worth of version history is not fantastic.
[1]: https://help.dropbox.com/files-folders/restore-delete/versio...
From Sep 15, 2008: https://www.maketecheasier.com/dropbox-backs-up-and-syncs-fi...
Version control with online MS Office and Google Docs seems to be going pretty strong.
Google docs has a similar feature built in too I think.
First thing I do on a new device is setup my mega shared drives - and there is a lot of plaintext files there!
I feel like building a Google docs clone for simple text files. Just one feature - versioning (A Time machine like interface) and perhaps add collaborative editing later. I just want to write and store a text document without having to create multiple files. Automatic versioning of snapshots so I can go back in time and refer to any timestamp.
So, uh, yeah I agree absolutely with you.
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.
How do you merge destructive edits to image files?
I love some of the collaborative nature of Microsoft Teams and CRDT editing Word/Excel, but I'm usually pretty remote. Text over a tenuous WAN connection is ideal.
I work at a government agency and I was /just today/ getting them to review and approve Git and VS Code for our staff use - and pandoc. A couple years ago we never would have gotten open-source software approved. I wish I knew of an equivalent to SELinux or AppArmor for Windows so they could lock down things a semi-trusted application can do. VS Code will be used in a few different departments, but I mostly want it to help those unfamiliar with Git and its CLI (Git Graph is nice).
There's a trick out there to first convert things like Word documents to Markdown, and then do a diff of that intermediate output: https://hrishioa.github.io/tracking-word-documents-with-git/
Pandoc can only do so much. I'm trying to convince my part of the gov to put policy documents we disseminate to staff in a git repo, so we can track who did what and why (based on commit messages). This will be a big step, but thankfully one part of our org is already moving toward version control for IT and data analytics so I'm proposing this and suggesting we hop on their bandwagon. Momentum.
There's a Word template that we commonly use for legal purposes where it gives you line numbers and you write text to align with the numbers. When reviewing it's easy to say "change line 23 to read ....". This - for example - will not translate well through pandoc because the numbers and the text are separate text elements.
There's a market for making pandoc better. Visually translating how elements "flow" from 1 format to another, instead of simply transpiling XML to Markdown.
I'm still excited thinking in a year I might be able to git-blame the legal department for things. Or see a diff from 1 administration to the next.
Some thoughts:
1. Policy makers think they write policy in English (or other human language). But more and more it is the software.
2. "policy engines" aren't going to cut it - we need to introspect code to decide what the code does - and translate that back to policy.
3. at my work the best solution i have got is using unit tests to explain what the policy is based on test comments - and again that's using english and again it's terrible ("best")
I think the real solution is both wider software literacy so that discussion happen "in code" and code that is more like policy (composable functional languages are thus likely to be useful here)
But great to hear you are taking any steps at all - would an HN letter writing campaign to your ministers help?
So you won't have a neat revision history, unless you implement something in the pipelines to also convert .docx to something human readable, because .docx and OpenXML isn't.
In an office environment, modern MS Word gives you a really nice version history, with automatic or manual/named versions, plus multi-user simultaneous editing, with a slick and fast UI. It’s even cross platform - I send a coworker a link to a document, and they can open it and work on Word for Windows while I edit the same doc on Word for Mac or even on the web-based Word.
It’s shockingly good.
While some of the ideas are great, the overall experience was pretty bad. Leaving autosave on often slowed down Word to an unworkable pace and after a few other issues (I'm not exactly sure what, wasn't involved) we just made sure only one person at a time works on the document.
Some other annoying small issues I experienced: when working together sometimes your undo history is gone. I guess that's because someone else edited too and correctly undoing something someone else edited in between is not simple. IMO it's impossible and any system doing merges automatically will fall apart at some point.
Track edits cannot track deleting rows of a table
Wed based word works actually pretty fine, but it misses random features. Adding captions seems not to be supported.
It's the little things...
I use it every day and really haven’t had slowness issues, even when running via Parallels on the Mac side. Of course, typically my docs are <100 pages and light on images.
I have seen undo history go away when edits collide with multiple users, but that’s really the only way it could work. And you can still view old versions of the doc if you need to retrieve/restore something.
MS Word as a whole is definitely very far from flawless, but it’s still better than the alternatives I’ve seen, and it’s extremely entrenched. That’s why it’s hard to see “git for office docs”succeeding.
~250 pages, ~100 images, not something I expect a modern computer to struggle with. We used the web version on Linux sometimes, but I think it also happened when we didn't.
>I have seen undo history go away when edits collide with multiple users, but that’s really the only way it could work. And you can still view old versions of the doc if you need to retrieve/restore something.
The other way is like git does it, manual merging and conflict resolving. I don't think there's a way around that once you work with enough people together on a file.
Personally for the kinds of documents I work on, I'd rather risk losing my undo history than have to deal with manually merging changes from multiple users.
Plus, without real-time concurrent editing, the changes are much more likely to conflict.
Most of what bothers me is trying to view, read-only a previous version. Usually I have several Word or Excel documents up on my screen, and it's easy to begin modifying a past version that then becomes the latest. It's not reflex to open a previous version and untoggle autosave. It bites me all the time.. In Office's pursuit to help people avoid losing data, I wind up overwriting what I need to preserve. A lot..
I have not seen manual version names in Word doc history. Maybe I'm sheltered :s
In my experience it starts to creak on large documents with multiple editors. I did a project many years ago where the key deliverable was a large report, worked upon by 3-4 contributors over 12 weeks.
That last week was absolute madness. Document got corrupted, and we tried all sorts of things. We ended up importing the corrupt document into Google Docs, which, oddly enough, did a better job of working with a corrupt Word document than MS Word did.
It doesn't help that there are lots of versions of online Word - there's the one that lives in Sharepoint, the one I get to via Outlook, the one in Teams, and (maybe? somehow?) the desktop Word when editing an online file.
These features are nice and all, but the thing is, most users not only don't care about using them, but don't care about even the idea of them to know they exist, so they continue with the old workflow.
Most of the time its better to get out of the users way, but in cases like this, if you truly do want to get rid of the infinite finals, they need a bit of a nudge
Microsoft word can't even open files from old version of the same software.
None of these word document will be readable in 50 years from now, a text file though.
macOS Time Machine and Windows Shadow Copy aren't perfect git-based versioning systems, but it's nice something in the general direction exists.
When they introduces this they changed the standard file operations and replaced "Save as…" with "Save a copy" - this was not universally welcomed.
Worked on a “Git for Word” project [1], which is currently on hold.
The diff part was manageable, though not trivial to get diffs that make sense for prose/regular text.
The hard parts are UX/UI (making Git concepts transparent to “normal” users) and merging. Yet without automatic merging, branching is not very convenient.
Would love to collaborate on this in the future again. Reach out if you are working in this space, happy to share.
Sourcetree is the best git GUI I've used. That could be used as a model.
I think an old-style solution to merging would be fine: output a word file that uses a unique font style to indicate which user made what conflicting changes, have the user edit the document and remove all of the "merge styles", then continue.
Just to show how useful this is here’s Indian Constitution with amendments as commits:
From what I've read, Pijul should fix at least the problem of needing to resolve the same conflicts multiple times over and over again. However, I feel that version control focused on text breaks, because the merging algorithm doesn't know anything about the semantics of what's represented in text. So yes, I'd say that version control in more areas would be nice, but one based on binary formats understood by version control. One glimpse of that may be KeePassXC, which can merge password databases and has never done it wrong in my experience.
In my opinion, the following configuration should have been the default with Git:
git config --global rerere.enabled true
git config --global rerere.autoUpdate true
The `autoUpdate` part means: every time you finish re-applying a recorded resolution, please `git add` the result automatically for me so I don’t have to look for a "conflict" that’s actually no longer there.
I don’t see how that is guesswork. My impression is that rerere is perfectly deterministic, and only repeat things the user has done before.
The downside is: once the user has manually created a faulty resolution, then rerere will possibly replay that faulty resolution.
That’s how things can go wrong, and I see how one might blame that failure on rerere itself. And I think the blame not entirely unjustified, because rerere could do a much better job in explaining how it interacts with certain scenarios. For example, let’s say I’m aborting a rebase. Will rerere roll back the resolutions it recorded? I honestly don’t know. The manpage vaguely claims that it will, but I’ve been unable to reproduce it.
I wish rerere made more transparent how it interacts with `--abort`. Just printing an informational line would already go a long way. I also feel a command like `git rerere log`, which would print the recent activity of the `rerere` database, might help with that.
Really? One new added line, and one delete/add two lines above it.
it usually works fine, it really does, but when it messes up, it really messes up big time. As long as it doesn't create a conflict, you just shrug and move on, but when it does create a conflict, holy-moley!
But no, people always seem to insist on that linear history is the only concern that matters, explicitly delete the history, and then wonder why Git is so annoying and easy to screw up.
Maybe Git should have locked rebase behind a feature flag of some kind. `git pull --rebase` should certainly never have been added.
There are many reasons why linear history is important. Rather than saying that "you shouldn't want to do that", I'd prefer it if the tools people use were fixed to better serve the things people actually want to do.
A merge would only make sure that I don't need to resolve the same conflict multiple times. It wouldn't result in the conflicts not being generated in the first place, or them being saner. The only difference in conflict resolution between rebasing and merging is that the sides are flipped (what's shown on left in rebase, is on the right in merge, and vice-versa). Which doesn't address the second issue I listed: conflicts are not only repeated, but the conflicts themselves are pretty crazy. In my example, often-times C would never even touch files which were detected as having conflicting changes with A or B. It was pretty absurd that I would have a 3-line change in C, several hundred-line changes in A and B, yet the biggest conflicts would be triggered when rebasing C on top of B, and those would be in files C did not touch. Other times diffs in conflicts would have most of the lines added and removed actually identical, with only a couple in the middle different. Why would git mark them as conflicting, is beyond me. And then there was the issue of git not detecting conflicts, when it should have, instead merging changes in a way that broke source code. None of those issues is better handled by merging than by rebasing. Most of them however have pretty good solutions in a patch-based version control system, as opposed to snapshot-based like git (conflicts in files which weren't changed? not going to happen). An even better solution would be binary formats with domain-specific merge logic, like the one in KeePassXC.
No, you just add it at the end of the commit chain?
> And rightly so: when I look at the master branch, I don't want to see random corrections someone made during review, they're just irrelevant once the reviewed changes are merged.
git log actually has the --first-parent for this, which hides all of the commits that were merged into the branch, without destroying the history when you try to go back and try to understand why the choices were made. The idealized version of history created by constant rebasing serves neither purpose.
> Rather than saying that "you shouldn't want to do that", I'd prefer it if the tools people use were fixed to better serve the things people actually want to do.
Agreed, tools that cope poorly with merges should be fixed, rather than forcing people to hack around it by rebasing.
> None of those issues is better handled by merging than by rebasing.
Not quite, rebasing generates more false positives, since it tries to merge every intermediate commit instead of only looking at the end states and the common ancestor.
Pijul doesn't, by the way, the diff algorithm is customisable. I wrote one industrial application of Pijul that uses spaces as breaks, and semantics-aware breaking is totally doable.
Which is the next thing. Git works just local and uses servers to sync. The purpose of servers is syncing and not depending on them. From this everything else comes, autonomous usage, speed, reliability, recovery.
Didgets (recently surfaced here on HN) seems like a sane approach to this, from the file system up. Pretty incredible performance too.
https://didgets.substack.com/p/where-did-i-put-that-file
Sadly not (yet) open source, though the developer is considering it.
http://www.oilshell.org/blog/2022/02/diagrams.html#text-narr...
https://news.ycombinator.com/item?id=30483914
It's generally not something you want to reimplement ...
Most people have no issues navigating a full folder of revisions to get to “Report Final Final draft v3.docx” but anything resembling version control would simply be unused. At corporate level, the version features of box.net, egnyte, and others are rarely used. I'd say most people don't even know they can navigate the revisions until they are in a data loss situation and asking about how to recover a corrupted file (which occurs most frequently with Excel files in my experience)
You can have a disk hierarchy if you desire, or trust that search will find you what you are looking for. For me search works fairly well and if I need something extra I can just grep/sed/awk.
Plus it has the features that a simple text editor will not have: displaying images, live preview, relationships between topics, etc. It even has a Vim mode!
This also works well for small organizations. Both GitHub and GitLab are able to render org files, with some minor limitations. Hence, a simple repository full of org files is already a wiki. Even local links just work, with zero dependencies.
It's possible to transform org files into HTML with some CI task to get support for all org features. But I have found this a bit of an overkill. I don't need most org features. The basics are already great: outlines, timestamps, hyperlinks, tables and footnotes.
You can achieve more or less the same things with Markdown as well.
This is truly the era of the memex.
I really wish Obsidian, or something like it, worked well for teams. Maybe it's on their roadmap, I'm not sure.
Also, is real time collaboration a game changer or a gimmick?
I used to think the former, but was questioning it recently.
What would be lost with syncthing + obsidian for your team or maybe something that does autocommit like fossil for probable conflicts?
But yes, realtime collaboration is a critical feature for documents that can be used during meetings (and IMO ~no meetings should be held without documents).
The other critical feature is comments, which I assume Obsidian does not have support for (they would be very nontrivial to represent in markdown).
https://gist.github.com/rattrayalex/2e4f934045aabc4caeeab249...
The real time is not as real time as, say, Google Docs. There's a lot of lag.
It is open source and everything is stored locally but not in markdown files. You can self-host the desktop app to share notes.
Best practice for tags is just include them in the plain text file, and inline images in Obsidian is like Derek said — just keep them in your folder structures just like your text.
If Obsidian went away, I'd still have a bunch of text files that I understood, and I'd know that I could find things tagged with #foo by using grep, that the [[links]] just mean to open links.md, that an image should be opened in a browser, etc.
You'll be able to get access to it in 20 years, even if not in a shiny UX friendly way. Which is more than can be said for some of the really old notes I took in proprietary pieces of software.
On Mac I use Ulysses. I get the benefits described here while still having a fast, native app with excellent UX.
I have Mac for work, and Linux for personal and an Android phone. That means Ulysses on Mac, ThiefMD on Linux, and Markor on Android, all synced with syncthings. Native apps on different OSes is the best solution I've been able to come across.
A single cross platform app would be preferable, but the last time I used Obsidian it was slow, heavy, bloated, with a pretty ugly UI, likely in part due to running on electron.
I do agree though, they do themselves no favours with that ugly black / purple website. They need a much better, much prettier default.
All that aside, I'm delighted with my switch to Obsidian. Just an amazing tool, and total reassurance that it's just markdown with all the benefits that brings. So glad to be rid of Evernote...!
$50/year puts you next to some good developer tools, that already do markdown pretty well, and I just don’t see the point of writing notes if they’re not also for work.
I’m sure it’s worth it once you have 100s or 1000s of notes by i somehow feel like it’s a bit of a too big pill to swallow in the beginning.
> You need to pay for Obsidian if and only if you use it for revenue-generating, work-related activities in a company that has two or more people. Get a commercial license for each user if that's the case. Non-profit organizations do not need commercial licenses.
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)
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 built two org-powered apps for iOS myself:
There are other great ones out there:
Lastly, a shoutout to Karl Voit who's been driving org markup awareness outside of Emacs with Orgdown https://gitlab.com/publicvoit/orgdown. He's also discussed org markup's strengths at https://karl-voit.at/2017/09/23/orgmode-as-markup-only
[1]https://docs.asciidoctor.org/asciidoc/latest/asciidoc-vs-mar...
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
Could someone name one decent md editor for Android?
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.
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.
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.)
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
Although I deliberately avoid Evernote and Notion for those stated reasons, I'm fine with Microsoft Word. I've been using it for 20 years. It even opens my proprietary DOS WordPerfect ("*.wp") files from 1980s!
Sometimes I need more flexible layout of fonts and graphics and MS Word is the tool I use for that. Markdown isn't an alternative. (EDIT add: Markdown isn't powerful enough for the style of documents I write. E.g. MS Word has tools to overlay graphic elements like arrows and callouts floating as editable layers on top of screenshots. Markdown can't do that.)
I'm confident I can still use it as a tool decades into the future. Even if Microsoft became more user hostile and eliminated local install in future versions and required a cloud-only Office 365 account, I'll just keep using Word 2019. LibreOffice may also be a Plan B option to open docx files. Not nervous about MS Word files at all.
Strongest possible respectful disagreement.
--- ^ orig comment above, edits below (I was interrupted when 1st commenting; apologies to anyone who responded to the short version) ---
See eg Obsidian (https://obsidian.md) for a great example. It's astonishing how feature-rich it's become. WYSIWYG editor, Excalidraw integration, Slid.es, etc etc etc.
And if you have any webdev chops at all, you have access to HTML, CSS and JavaScript. It's not even close.
I think that Markdown's success is due to a lack of a widely-used, simple alternative that's well-specified.
Org is easily and objectively the best markup but of course it's only very very recently that there was a non-emacs implement worth a damn.
The advantage of markdown isn't robustness, it's simplicity. Preteens can get a handle on it in minutes when using Reddit.
The main benefit that all these markup-shorthands serve IMO is getting people to add meaning semantically rather than with presentation. Word processor users typically adjust font size and color to make headings, even when given a list of headings right in the ribbon. Markdown is just an HTML shorthand: you can only work with semantic meaning.
Indeed and therein lies what I view is Markdown's worst feature.
@@html:<b>@@bold text@@html:</b>@@
>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:
$a^2
+1
=b$
$a^2
+1
+2
=b$
USA tends to use $123 to show dollar amounts,
but e.g. Germany apparently sometimes uses 123$.I laughed.
That’s the key. For much of my writing, all I need is text with a little formatting, and markdown is great for that as a user. (It’s less nice if you’re writing a parser, but that hasn’t come up for me yet :) )
For some of my writing I need professional-grade layout. There I either use LaTeX directly, or I use pandoc then LaTeX.
But sometimes I need to:
- Include images that don’t have a public URL
- Use more than one font
- Have a recipient be able to edit the document
- And the recipient isn’t a developer
Markdown doesn’t check all of those boxes. Word files do (as do Google Docs links, ODF files, and some others).
Markdown is great, but it’s not enough all of the time.
Word isn't bad, so long as you keep paying your subscription.
Web Word is free, like Google Docs is. (Meaning, it costs your credentials and data rather than your money).
https://www.techradar.com/uk/how-to/how-to-download-and-use-...
https://www.microsoft.com/en-us/microsoft-365/free-office-on...
For now. You don't know if and when Microsoft's business model is going to change.
It's 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.
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!
Plain text just works, everywhere, all the time.
No it doesn't. Try a plain text description of an electronic circuit vs a circuit diagram.
Try a a plain text instruction sheet vs an illustrated one.
Try plain text sheet music vs actual sheet music.
Try a mathematical plot vs plain text tables.
Try concept drawings of product vs text descriptions.
Try construction drawing vs plain text descriptions.
I could go on and on.
Narrow views on the world result in flawed thinking and absolutes that are just plain wrong.
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.
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
And again, I'm not talking about document formats for software - I'm talking about data representation for humans.
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.
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.
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.
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.
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.
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;
> 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.
https://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=...
Prose takes time, contemplation and thought. Leslie Lamport says similar.
Helps with understanding however not so much with selling.
> "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.
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.
https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
This tells me you've never actually tried this. For example the img tag allows you to, amongst other things, render an svg.
If you want a more full spec you can see here what it takes to render an img element:
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.
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.
Hum, yes you could. The formats aren't dead.
It's like putting on a blindfold and saying you couldn't see even if you wanted. Just remove the blindfold.
Just install Windows or Mac.
We think we are great innovators, but we are stuck in 1990. Notice also that there are no Vim-equivalents for phones, even though that platform has been widely used for 15+ years.
Sorry Bill Joy; sorry Bell Labs; sorry (many more); we let you down, and we let down the public, which now has no integrated multimedia format beyond WordPress or Instagram.
Lately I've been working with Inkscape and realized that SVG also has the capacity to be a freeform document tool, and one with a different default context than HTML(scrolling document) or PDF(paginated document). The default setup involves a canvas, it has a notion of object hierarchies that lets you browse content from an outline, it lets you embed assets and layout in a more-or-less arbitrary fashion, it can be coded with JS, and there's some (under-explored) possibility for structured accessibility. It just needs a viewer that approaches the format in a way that makes sense as a target for content creation, beyond its existing role of small vector icons and simple animations.
None of the existing formats have to work exactly right, they just have to be the starting point for a streamlined source; then make a direct viewer for the source and you have the integrated multimedia format.
It does remind me that EPUB, the ebook format, has potential: It's essentially, as I understand, HTML, CSS, and some metadata files, structured according to the specification, all in a zip file. It's already a standard, though AFAICT not quite stable.
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 store data all over the place.
I have Evernote for long book notes and tracking financial data.
I'm using notion right now as my base of notes for learning how to build a cabin (toggles and embedding videos is wonderful).
I tried to really use roam and its off-shots for a while but could never really get into it.
And i use a new txt file all the time. Anytime I don't know what I need or going to do. And 90% of the time, I never look at them again but they're all in my one synced folder.
At the end of the day, I keep thinking I'll settle on one solution but I'm doubtful that's ever going to be true.
So, you’re a note squirrel. So am I. I’ve stopped caring or stressing out about it. I just accept that I’m never going to be overly organized or systematic.
I do keep all of my notes in a /notes folder or sub folder so that fuzzy find works nicely. That’s the extent of my organization.
[0] https://www.youtube.com/watch?v=H69tRdemJiM
[1] https://en.wikipedia.org/wiki/Zettelkasten
[2] https://www.youtube.com/channel/UCCV1T7JbfzbE2O7P3kydmKw/vid...
1. Obsidian: has bidirectional linking and knowledge graphs, is faster and better supported, but doesn't have the outlining structure that Roam is based on.
2. Logseq: basically an open source Roam with 90-95% feature parity and some cool stuff that is its own.
3. Foam/Dendron/Athens etc: Roam clones.
4. Notion/Evernote/something else entirely.
Roam's about the block within an outline, interlinking and transclusion.
Dendron's core schtick is making traditional hierarchies easier to work with.
Like, with Roam a feelings of power scenario would be queries getting you subtrees from disparate outlines from which you pick out relevant trains of thought to synthesize your own writing, or just an outliner's ease in manipulating your text.
With Dendron it's more like, "oh, I've been thinking about this all wrong" and restructuring your notes so your new hierarchies reflect your new understanding.
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.
Outliving formats is an interesting angle. I'm sure some of us know people who still use proprietary formats and software from the 1990s or earlier. They keep backups, but they keep using what worked for them.
Some years back I wrote a modernizing-controller for a Dreamweaver site behind a traditional craftsman's business that is doing pretty well, especially with the help of the web. The modernizations I needed to plan for were so many that they had to think long and hard about years remaining until retirement. The scope changes I received were super awkward because I could feel their frustration with new ways of doing things. It was strange to see things like the .dwt Dreamweaver formats still in use. They also used other proprietary software & formats.
But I do find it hard to imagine that text files (in the sense of the article) would have run the site at any point. Text files do take a bit of a stoic philosophy to really grok at some level IMO, and this has been true since maybe the '70s? The thing about text is, first of all the information is the expression framework. This is backwards for a lot of psychologies out there. The emotional components show up as decoration. Font color schemes, etc.
The article also mentions mind mapping and other tools. Those can be really important as a way to express what is inside the mind as a completely different type of process. Mind maps in particular address a problem of categorical expression, in a breadth-first context. This makes the visual itself a very useful format-as-framework. I find that I use them just enough (I have my own variant) that I keep a semi-yearly Freeplane file at hand even though I mostly use text.
Anyhoo. :-) Lots of good points in there. Thanks for sharing the article.
I 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.
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.
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.
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.
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.
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.
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.
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.
I don't think your argument holds any water.
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.
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.
You can also cat and grep binary files I guess everything is plain text
I'm puzzled, how people use markdown? For what? Just to make text more formal?
The difference perhaps being that the note-taking/creating aspect is done in plain text, and stored as such.
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.
[1] https://workingcopyapp.com/
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.
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.
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.
Adding in some script... maybe people would like https://tiddlywiki.com/
Open Source, usable on iOS and Android via apps. Is pretty much a self contained webpage but it allows drag'n'drop image files onto the edit box.
I've started a simple Bash utility for organising, searching notes and extracting TODOs out of them: https://github.com/hkdobrev/notetaker
I'd be glad if someone finds it useful.
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.
[1] mem.ai
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.
My personal stuff is in Markdown.
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.
[0] https://plaintextaccounting.org/ [1] https://github.com/beancount/
FWIW: I chose the beancount dialect over the simpler hledger/ledger format because of the additional support for investments/currencies/assets.
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.
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.
Folders are hidden, no default text editor, lock-ins everywhere you look.
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'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.
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?
It's nothing fancy, just a prototype using electron and vanilla javascript, but it might be useful.
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.
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.
Anyone have suggestions for a solution?
This has a few positive sides and negative points. I think the positive sides are more relevant than the negative ones.
Your writing should outlive you.
The End. Period.
PS: Eventually, if it's important enough, it should transcend mediums, including electronic. ones
What's amazing about this is that your thought archive is now searchable (which is fast in bear).
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 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.
See if you’d like Joplin or Simplenote. I still use Simplenote. Because even though FSNotes seems promising, it’s still not there.
(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)
Joplin is FOSS. Format is not proprietary and it is easily readable and they also do a raw export https://joplinapp.org/help/#exporting
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.
- use math functions in the document
- add visual sections for people to be able to quickly scan the document once printed
- use tables
- use pictures
- real time collaboration involving all of the above
This is great because you can choose something that fits your problem instead of being forced to type in plaintext.
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:
- HTML: https://daringfireball.net/linked/2022/03/01/mozilla-on-tind...
- Markdown: https://daringfireball.net/linked/2022/03/01/mozilla-on-tind...
https://www.timeshighereducation.com/campus/joy-text-world-t...
PS. I am not the author or contributor just a daily user of it and i like 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.
The basic app is simple, but has a good extensions API which means people can and have gone nuts with it.
It mentions an advantage of not fiddling with formatting but I constantly switch between wiki markup, markdown, and even ini format; I can't help it.
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 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.
However using a note taking app that operates on plaintext (markdown) files like Joplin could be a good middle ground.
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.
But if you need rich text and images, it seems like the only alternative to plain text.
I really wish I could define a custom order for files in a directory. A folder hierarchy is almost an outline, but not quite.
Yes I could prefix with "01", "02", and sort alphabetically, but those are cumbersome workarounds and reordering is a pain.
Are there file systems that allow for a custom order of files/folders?
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.
BASIC line numbering:
010_...
020_...
030_...Extremely relevant: http://len.falken.directory/misc/writing-for-the-internet-ac...
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.
But that one little nugget that is relevant, can be worth a lot years later.
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.
Now even vim had a mode for them. Check out what pandoc is.
Don't use agenda features though, it is a huge distraction.
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.
It’s not any trouble at all to maintain and requires very little space.
I’m not sure why it would seem like an “incredible amount” of trouble to you.
What exactly is unportable about using asterisk for bullet lists and brackets for URLs?
> 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?
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.
All good?
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.
8.
> Date: 2022.02.03
> Is this March 3rd or February 3rd?
February 3rd, obviously.
But the periods are weird; the standard is hyphens.
> Sure, but what about dates and encoding?
ISO and UTF-8.
Anyone ... are fucked.
Hmm...
> If on the suitable media.
Hmm.
(Oh, and still February 3rd, obv. March 3rd would be 2022.03.03.)
Is parsing json (correctly) really markedly simpler/easier than parsing something like cbor?
Out of pure curiosity: Why do you need non-breaking spaces? I don't think I've ever used one, and now I'm wondering if I am missing out :)
who of you actually used plain text (not even markdown) for all texts and notes for say a month?
And who changed back, why and for what occasions?
I use vim mainly, and open in Mousepad before sending text to people via e-mail (plain text email of course).
Most of my knowledge base is in plain text. It is easy to 'find' and 'grep'.
And, unlike text files, it's easy to insert images and tables in a Doc file.
I can’t shake the ridiculous feeling that comes with typing plaintext journal entries on a gaming pc.
Plain text is great, I get the gist of Derek's post, but encoding of a plain text file is a whole other beast.
Writes HTML tags
:shrug:
> 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.
[1] Okay, I love to be pedantic
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.
Please show me a computing device that cannot deal with ASCII.
And UTF-8 has, by now, reached a level of ubiquity that encompasses almost everything in IT as well.
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.Homer was able to write the fall of troy and Shakespeare Hamlet without bold text.
So what can't one express without?
Are you sure they didn't use bold text, though?
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 appreciate modern computers conform to standards, but that doesn’t mean that these standards have always existed, or will always exist.
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.
> 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).
but this is true only for newer versions. In older versions it was binary salad derived from C's data model.
And even in new versions these are far from files you can safely edit by hand.
> This definitely isn't true
Yes, actually it is.
> and it kind of misses the point that there's no such thing as "plain text".
Who here made such a point? Anyway, that's not true either.
> It's still encoded in ascii, or utf-8
So, plain text files.
> and still potentially has problems being read on other machines.
What "other machines"? What problems? What matters is the software, not "machines".
> It's reasonable to say that ascii has become so ubiquitous as to be universal, but it definitely wasn't always so
I was alive when EBCDIC was common, but that isn't relevant.
> and won't definitely always be.
Sure, there's the heat death of the universe eventually.
Prose are Powerful
The result of that is, so long as you don't add any emoji or anything to your documents, a 2022 version of VS Code will store your text files in the same format as vi did in 1976.
And, as someone already mentioned, all the first 127 characters of the UTF-8 encoding are the same as the ASCII ones, so a UTF-8-encoded file containing only those characters is identical to -- is -- an ASCII-encoded file.
Where do you store them now?
And 2 KB is 2 thousand characters ... "pages and pages" of notes sounds like more than that.