Off the top of my head, all PKMs make trade-offs on discoverability, portability, maintainability, and ease of recall. Broadly, "discoverability" is how likely you are to stumble on something you'd forgotten (just recently, I found a file in my "taxes" directory listing all the documents I needed last year, which was a big help, and which I did not remember writing), "portability" is how resistant the system is to a company shutting down/project being abandoned, "maintainability" is how easy to keep your system consistent with its principles (including inserting a new note), and "ease of recall" is how easy it is to find something if you know you're looking for it.
When thinking about a lifelong PKM, I feel like I value portability more than most; something highly tied to a particular company like Notion is right out for me, and I'm leery of stuff like Obsidian or even org-roam, since even if the entries in those systems are just text, I just know that someday the logic that ties them together will stop being developed/maintained and I'll have to migrate.
I feel confident in directory structures and text files as long-term mediums though, and so JD is appealing to me, but its maintainability (specifically the cognitive load around inserting a new note) is such a stumbling block for actually creating content for it. Not to mention the primary thing it trades maintainability off for (ease of recall) is almost entirely solved by search functionality, leaving discoverability as the only benefit over just chucking everything in a flat "notes" directory.
I do something PARA-adjacent now, and I might just commit to that, although denote is interesting as an Emacs user for a slightly more portable tagging- and search-based option.
I keep everything in a single folder, as plaintext Markdown files.
Even if my own software breaks someday, I can always ingest these into a flavor-of-the-month indexer (though I think sqlite + fts plugin goes a long way) and carry on.
I use paperless-ngx with about 10 document types. Most documents don’t have a type. I scan everything we get in paper form (mail, prescriptions, anything) with a document scanner and dump it all in there. For email pdf I forward it to an account that ingests the documents.
It has a classifier so after a while it picks up the date, correspondant (if you set it), document type automatically.
Daily backups to rsync.net and the export function is a dump of all the files + metadata in json format.
The search (via OCR) is pretty good and it’s the easiest system to manage I’ve found. I used mayanedms before but it’s too cumbersome and upgrading major versions was very complicated.
> trade-offs on discoverability, portability, maintainability, and ease of recall
Good insight. Thx.
I feel fairly confident in Obsidian as a portable system, since its basic concept (markdown docs with tags and links between) can be found in many other apps [^1].
I'm currently using Bear, but I've made experiments migrating to Obsidian without issues.
[^1]: Bear Notes, IA Writer, Ulysses, Craft (kinda), NotePlan, ...
I wish I knew more interesting games that could be played with a standard deck. My wife and I travel a lot and there's something I find deeply appealing about being able to walk into any gas station, corner shop, or airport store anywhere in the world and come out with a dependency-free way of entertaining yourself (or even making friends!), and I feel like I don't know enough games that take advantage of that.
That's interesting! My wife and I both pictured him as masculine. In my case, as a cis, bi man who's honestly evaluated how I play my gender, it was because a lot of the way Murderbot feels about being amidst humans is IMO just dead-on how a lot of men feel being amidst women?
Like "everyone here is a little wary of me, and I can't even really blame them for it, because I just categorically am a more threatening presence."
Contra to a lot of what's being said in this thread, I think a lot of smart people get stuck in the trap of overvaluing quality of input relative to quantity of input. Put another way: the bitter lesson applies to the AI inside your skull too.
Relatedly, it took me a while to appreciate that seeking out and organizing the best knowledge on a topic is, for me, just a form a procrastination. Its ok if I'm doing it for fun. But if I want to learn, the key seems to be that every single day I start the day learning or reinforcing something, and do no other activity until that one is completed. A somewhat related thing I learned in medical school, is that many people have an internal cue for when you've really learned something. When you have re-visited something for the nth time, and the feeling you have is a deep level of annoyance that you are rehashing the same thing again, that is usually the signal that it will stick. May not work for all but worked well for me and the folks I shared it with.
People aren't angry/worried because they don't have a competitive advantage any more--people are angry/worried because they sense (I think correctly!) that AI will eliminate the part of their work that they find enjoyable.
Artists, by and large, don't do art because they enjoy having art--they do art because they like /the process/ of producing art. If that process can be done faster and better by AI, then yeah, sure, they /might/ be able to still do art for a living (some artists will be able to leverage their experience to maintain an advantage; other, less flexible ones will lose work)--but the work they do will likely not be commensurate to the work they were doing before, and will likely be less enjoyable to them.
The thing that worries people about AI is that it'll make all creatives into middle-managers.
To me, creative fine woodworking is making a cool idea based on the world around me and experiences I've had that balances engineering needs with artistic form.
Then I spend 95% of my hobby time tediously sanding boards and applying finish and this is NOT the fun part of my hobby.
I will say the only time I've gotten compensation directly as been for the latter because nobody likes doing that stuff.
I'd say AI will make creatives into micromanaging middle managers, the type that gets way too involved in a critique of your every decision is still going to micromanage, they'll just be harassing an AI instead of humans.
Fundamentally the creative act of making book cover art has always been specification. You can say to an artist "make me a book cover looking like ..." or you can hire a guy and give him no direction and trust him to decide what to do. But the creative act was the specifying, not the mechanics of turning that idea into printing ready art.
Another problem you run into is AI is as currently produced, a groupthink enforcement technology, and most people will be turned off by that. The blandest least offensive corporate dining experience is likely McDonalds. How much do hipster foodies prefer going to McDonalds over ... anywhere else on the planet? AI can only create the ideal big mac, and you can make money shipping big macs, but only selling to poor people, everyone else wants something else, even if in a strict corporate inhuman sense its inferior in every way to a big mac.
I'm really impressed with the strides Emacs has made recently: native compilation, project.el, eglot, and now tree-sitter?
As a user who hadn't kept up with development news until recently, I'd always mentally sorted Emacs into the same taxonomy as stuff like `find`: old, powerful, with a clunky interface and a stodgy resistance to updating how it does things (though not without reason).
I'm increasingly feeling like that's an unfair classification on my part--I'm genuinely super excited to see where Emacs is in 5 years.
Yes, it feels there is a lot of momentum going on recently.
Both neovim and Emacs are being improved at breakneck pace, and it is quite incredible for such an old piece of software with, dare I say, a quirky contribution model. The maintainers are working really hard on keeping it current and competitive.
I'm really hoping that Emacs becomes multithreaded somehow. Or at least improves some operations so that they're non-blocking.
I've been using Emacs primarily for org-mode/roam/babel for a few years now. I'm very glad for its existence, I really think I've become a more effective DevOps person because of it.
I'll be entirely satisfied with a process/event queue/loop that we can submit tasks to like Javascript's. There is already a command loop in Emacs, we just can't use it for anything other than input events and commands. Once we have an good event loop, we can build a state machine like Redux on it, then we can start rebuilding the display machinery, then we can start deleting all those hooks that constantly interfere with each other...
I meant exactly that, both core JS and ELisp share the same model of a global interpreter where blocks of code can be interleaved and yielded (both manually and in response to external events). I wanted to know what in particular about JS you were missing.
You have been able to emulate cooperative multitasking using callbacks since at least the 70s with lisp. There's always been some form of concurrency in any lisp, the problem is, the event listening/emitter pattern is pretty much not a thing in Emacs, so you can't fire a custom event and hope it will drop into the event loop and get responded to by whatever is listening, because it's not an event loop, it's a command loop. The types of events you can respond to is fixed.
I don't think it needs to become multithreaded, it just needs better support for async/event loop style concurrency!
Right now we can run subprocesses without blocking anything with "make-process", but interacting with the process is pretty clunky, and you have to use the process sentinel and filter to perform callbacks when the process changes state or exits. There is quite a lot of boilerplate to setup for all of this and the control flow is pretty confusing IMO.
A nice "async/await" style interface to these things could really go a long way I think!
Indeed, I'm using Emacs for Code, reading/writing documents and emails, as well as consuming RSS feeds. The ecosystem and values that underpin Emacs are fantastic - in my personal case the only downside to heavy use of Emacs is that it can struggle to utilise my hardware. This tends to be particularly noticeable when using TRAMP and Eglot, or producing large org tables.
I probably didn't use the right terminology. I mean that if I list-packages then U, then x to start updating, I should be able to go back to my editor and continue working.
There was a package[1] that did exactly that, so it should be technically possible, unfortunately it has been unmaintained for a while. In any case I/O asynchronicity is achievable without actual multithreading (there are also IRC/telegram/matrix/mastodon clients that don't freeze the UI).
I think a lot of packages are not yet using threads. And to be honest, I'm a bit scared of packages starting to use threads because there are a million ways in which you can mess up with threads especially given Emacs’ architecture. What if two threads start manipulating the same buffer? Emacs wasn’t built with these scenarios in mind. But perhaps I'm too pessimistic and there are good answers for that.
I was sad the day I saw Emacs implemented threads before a proper async event loop / futures / etc. Do those first, see what kinds of concurrent code people actually want to write, then write a multithreaded scheduler for that.
Instead it’s backwards, now we have hard-to-use concurrency primitives and still shitty UIs.
I want to see good interactive tools for working with and introspecting threads / async / other concurrency models first. In general, because I don't know of any, and in Emacs in particular.
My current experience with Emacs concurrency is mostly negative - occasionally, an async-heavy package (like e.g. Magit-style UI for Docker) will break, and I find it hard to figure out why. Futures-heavy code I've seen tends to keep critical data local (lexically let-bound), which is the opposite of what you want in a malleable system like Emacs. For example, I'd like to have a way to list all unresolved futures everywhere in Emacs, the way I can with e.g. external processes. But it seems that at least the async library used (aio, IIRC) is not designed for that.
> For example, I'd like to have a way to list all unresolved futures everywhere in Emacs, the way I can with e.g. external processes.
I think you could get this done by advising promise creation/resolution functions, aio-promise and aio-resolve. The async/await macros are wrappers around generators-over-promises in this library.
But yes, in general Emacs concurrency sucks. The least bad option I found was using promises' implementation (chuntaro/emacs-promise) that uses `cl-defgeneric` for `promise-then` and (obviously) moving as much processing to a subprocess as possible. The former allows you to make any type "thenable" by implementing the method for it, which is nice for bundling the state around async operations. cl-defstructs are nice for the purpose.
Emacs threads are not parallel and are co-operative rather than preemptive. The co-operative parts mean that you can guarantee atomic updates very easily when updating global variables or buffers so you don't run into some of the more nasty issues that can happen with preemptive threading.
Like the way Python have threads lol.
Emacs has generators too, and there are promises implemented on top of them, but they aren't very useful in the elisp ecosystem because at some point you are still going to have to poll due to a lack of a JS like event loop that users can submit tasks to.
There is one more, possibly gigantic, thing though: Better handling of very long strings. I know the data structures for strings have various tradeoffs, but properly abstracted, it should be possible to even give a choice, no? So users could choose the data structure, based on their use cases. But I know little about the internals and maybe that is all too low level to be something a user could choose from the user interface or configuration.
I hope string data structure is properly abstracted from, so that it is exchangable for another data structure, but I have my doubts. Would like to be surprised here and anyone credibly telling me, that string data structure in Emacs has an abstraction barrier around it, and is actually exchangable, by implementing basic string functions like "get nth character" or "get substring" in terms of another data structure.
If it is not properly abstracted from, then of course it could be a nightmare to change the data structure.
I use IntelliJ products but still prefer Emacs as an editor. I moved off it for code for IDE features, even if I managed to get some convenience in Emacs it ran synchronously which meant experience could be pretty laggy at times vs "at worst popup with extra info will be delayed" in IDEA
I adopted GTD right before I left college, and I sometimes wonder how I ever would have managed to adapt to the explosion of tiny, attention-grabbing tasks that adult life supplies without it. Admittedly, it feels a little clunky and "enterprise-grade" in places, but the underlying principles are so rock-solid and obvious-in-hindsight it feels magical.
Plus, org-mode really helps to make the over-engineered parts more frictionless--I run my life off of org-agenda now, where creating a new project, capturing tasks for it, and refiling them as needed are only a few keystrokes away. Keeping with the theme of hyped productivity books, I also take inspiration from Deep Work to tag certain actions as being ":deep:", so that after clocking into those tasks, I can look at a clock report at the end of the day/week to understand how many hours I actually spent working on "important" stuff. It's very motivating to make that number go up!
I know not everyone feels the need to be so intentional about their productivity landscape--indeed, a lot of very naturally productive people I know explicitly /don't/. But for those of us who aren't one of those magicians, I highly recommend putting some thought into at least a bare-bones system.
He drowned the world once, but did he not instruct His faithful servant how to weather that storm? Did He not guide Noah's hand to build an ark, to gather animals and his family, to ride the waves until the time was ripe to repopulate the Earth with righteousness? Was that all Noah's Godlike doing, or did he benefit from divine assistance?
Think of the distinction between "over the board" and "online" as kind of like the distinction between "NBA game" and "pickup game". Even that might be understating it. The levels of importance are radically different.
Also, think about how much harder it would be to cheat over the board. You might use hidden devices, accomplices, secret signals--compare that to an online game where all you need to do is switch over to another tab to check the engine. Cheating OTB requires a significantly greater degree of forethought, planning, and commitment--a persistent and repeated willingness to cheat that is way less acceptable than an online player getting tilted and looking at an engine. Still cheating, yeah--but at least it's not premeditated.
I can second the comments that a solid E ink device makes reading pdf/epub stuff a lot more enjoyable, and I greatly prefer it to reading on a traditional screen.
That said, for exactly the class of books (didactic/reference) that your question calls out, there's no substitute for physical books. For me, so much of reading a book meant to instruct involves flipping back quickly to an earlier chapter to refresh my memory on the exact definition of a concept, or paging rapidly through a section to see what headings it covers, or switching from a page in one part of the book to a page in an entirely different part so I can compare their content. There just isn't a frictionless analogue for this, even with E ink devices: and when you're trying to learn stuff, a solution with friction is barely a solution at all.
When thinking about a lifelong PKM, I feel like I value portability more than most; something highly tied to a particular company like Notion is right out for me, and I'm leery of stuff like Obsidian or even org-roam, since even if the entries in those systems are just text, I just know that someday the logic that ties them together will stop being developed/maintained and I'll have to migrate.
I feel confident in directory structures and text files as long-term mediums though, and so JD is appealing to me, but its maintainability (specifically the cognitive load around inserting a new note) is such a stumbling block for actually creating content for it. Not to mention the primary thing it trades maintainability off for (ease of recall) is almost entirely solved by search functionality, leaving discoverability as the only benefit over just chucking everything in a flat "notes" directory.
I do something PARA-adjacent now, and I might just commit to that, although denote is interesting as an Emacs user for a slightly more portable tagging- and search-based option.