your intermediate calculations are still stored in memory and accessible
I don’t understand this. Is each code block in Jupyter an “intermediate calculation”? If yes, then Org behaves the same way.
they do not support parallel processing conveniently
Parallel processing is the purview of your code, not Jupyter or Org.
I found Babel/Org/Emacs wonderful, but what a pain in the ass to learn it !
These are four different things (along with Elisp), are you trying to learn them all together? This is a recipe for frustration and burnout. You can learn Emacs bottom up (starting with Elisp) or top down (Starting with Org, then Emacs). Pick an approach and stick to it.
The documentation is austere
This makes no sense – Emacs’ documentation is among the best for projects of its kind. The Emacs manual, Elisp manual, EINTR manual and Org manual have answered almost every question I’ve had, with very few exceptions.
So few examples are given.
The entirety of Emacs’ source is open to you, and that’s without including every package you have installed. Every usage of a macro or function is an example. xref-find-references is your friend.
There is too little blogs or books about Emacs, specifically about org and babel.
This may require a change in mindset. The reason I need books or blog posts to learn (say) Zig or Nix is because the manuals are out of date or publicly available source is unreadably dense. For the above given reasons, this is not true of Emacs.
The only time I’ve needed blog posts to learn about Emacs is for discovery – bringing attention to the existence of a feature is something Emacs does struggle with, despite the introduction of new commands like shortdoc. Even then, I prefer to just look up the source or the manual to learn about a feature once I know it exists.
It’s a game changer for a lot of my code, and would deserve a whole page to illustrate it. But no, it’s given in a «niche» example.
*this* is only useful for post-processing babel blocks (as I understand it), and it is mentioned in the section on post-processing babel blocks. It is explained with examples too. I don’t see where else it should go.
For such an old and wise piece of software, I can’t understand why we don’t have a smooth learning experience with Emacs.
Your idea of a smooth learning curve comes baked in with assumptions I don’t share. The manuals can teach you everything you need to know to beat Emacs into the shape you want. I’ve had a much smoother time learning Emacs than I’ve had learning any other complex piece of software, like Bash, Systemd, Blender or (heaven forbid) Nix.
In the meantime I added explicit support for GPT4All, the above instructions may be incorrect by the time you get to it. The Readme should have updated instructions (if it mentions support for local LLMs at all).
In that case you can use it right now with gptel, which supports an Org interface for chat.
Enable the server mode in the desktop app, and in Emacs, run
(setq-default gptel-model "gpt4all-j-v1.3-groovy"
gptel-host "http://localhost:4891/v1"
gptel-api-key "--")
Then you can spawn a dedicated chat buffer with M-x gptel or chat from any buffer by selecting a region of text and running M-x gptel-send.
I can add this to gptel quite easily, but I can’t find the instructions on how to use it. Does it use a local http server? Where can I find these details?
Top result from a Google search.
Also, you are not limited by a shell when inside Emacs – this is straitjacketed thinking. There are better ways to get what you want than replicating zoxide or fasd.