Storing knowledge in a single long plain text file

I was thinking about making math more like a mode i.e. make it available in every block type, as opposed to it's own block type.

Then it would be active in plain text, markdown and even code blocks.

As to data fetching - falls a bit outside of scope.

Mostly it supports multiple notes and it's a web app, not a desktop app.

I could build a desktop app but it would not offer almost any advantages given that Edna can also save notes on disk (that's how I use it).

You can use Chrome's "Install" feature to make it look act like a native app (it opens in it's own window and acts independently of the browser).

I wanted multiple notes and I didn't get why it was made as a desktop app first given that all functionality to implement it is available in a browser (well, Chrome).

So I forked it and added those features.

Been using it daily so it was worth it.

https://app.heynote.com/

So Edna either stores notes in localStorage or in a directory of your choosing on disk.

In Edna you can right-click for context menu to switch between localStorage and disk.

If you ask: "how do the browser APIs work", you can look at https://github.com/kjk/edna/blob/main/src/fileutil.js

Basically, there's `window.showDirectoryPicker()` to ask user for permission to access directory (either read only or read write). And then using that directory handle you can read list of files, read / write files or create new files.

I've been thinking about more featureful markdown note taker that would support images and more.

I've started on such a thing but stalled. It's way more work. The good thing about Edna is that I spent less than a month adding the features I wanted to Heynote fork.

The current version is at https://notedapp.dev/ but don't use it for actual notes.

Initial note storage is in localStorage. To switch to disk: right-click for context menu, `Notes storage` / `Move notes from browser to directory`.

Then choose a directory on disk and we will do one time migration from localStorage => disk.

You can then switch to another directory (some apps call it a "workspace"). Because why not.

Encryption is probably the next feature I'll add because I want to store secrets in my notes and I'll feel better if those notes are encrypted.

More docs: https://edna.arslexis.io/help

Multiple notes is pretty big addition. I loved the concept and implementation of blocks in Heynote but a single note was a deal breaker for me.

I've also added some UI like right-click context menu for discoverability, ability to enable spell checking.

And I'm really trying to optimize for speed of use, including speed of switching between notes.

For example you can assign Alt + 0 .. Alt + 9 as note quick access shortcuts.

By default I create 3 notes: scratchpad, daily journal and inbox and they get Alt + 1, Alt + 2, Alt + 3 quick access shortcuts but you can assign them to any page you want.

What I know about Codemirror I mostly learned by reading other people's code so I suggest that.

Specifically code of silverbullet: https://github.com/silverbulletmd/silverbullet/tree/main/web... (and a few other directories there).

It implements very advanced Markdown mode, lots of code to learn from.

My guess is that the attacks you draw will skip any basis in technical merit and land directly on the tone, proceeding on an emotional basis. We have an n=1 here with plenty of that behavior on display.

You'd like to believe that someone proposing Tree Notation for a project wouldn't be dismissed with "isn't that, like, the YAML for TimeCube guy?". But this is, in large part, how the world actually functions.

A file is a very abstracted concept and it technically can mean a lot of different things depending on the file system.

However, it is a very good abstraction that's nearly universal and practically there is little to no reason not to use them to organize things.

My message is an echo to earlier comments of earlier posts that talked about a similar point: nothing is ever new, everything has already been done before. If we tell ourselves we're engineers, we should be studying what came before in order to prove that the new thing is indeed better.

That being said, recutils is the standard method of recording data in GNU, and ndb is the standard method of configuring stuff in Plan 9, a system that any proponent of UNIX mindset should know about. I'm not exactly talking about obscure stuff here.

My confidence is shaken considering the sparse “prior art” section links to Apple M1 as an example of “fast file systems”.

That's perfectly fine, but that's besides the whole point.

The point is that between coming up with something and implementing it, there should be a step to check if anyone already did something similar.

The whole point of researching prior work is to a) don't waste time reinventing the wheel, b) leverage prior work to improve your own ideas, c) make better use of your time by doing meaningful contributions instead of taking a risk on whether you're ripping off someone else's work.

That's the absolute basic standard on scientific publishing, for example. If you pick up any paper at all, you'll notice that right after the introduction and summary you get a bibliographical review listing any relevant work that your peers already contributed. When anyone submits a paper, the reviewers can and outright do reject your submission if it fails to adequately contextualize the paper with regards to prior art and related work. One of the points is to ensure the author is not wasting everyone's time with a novel approach to the wheel.

More importantly, if an author fails to know what's already there, how can they tell their idea is any good?

Except that the title ("A New Way to Store Knowledge") is leaning heavily on NEW.