Did you manage to get pixel-scroll-precision-mode to not snag on large images? It’s not clear from the README what improvements you’re planning to send upstream that are not mac-only.

effectively simulates a feature-complete trackpad driver in elisp, complete with scroll interpolation, a timer-based momentum phase, etc.

I remember reading through this code when I was looking over pixel-scroll-precision and thinking “this is crazy”. The event loop is already full to bursting in a typical Emacs session.

A shame that acme(1) only gets a passing mention when the original paper on acme’s predecessor help really drives the point home for having a mouse-friendly interface: https://doc.cat-v.org/plan_9/1st_edition/help/

Unfortunately it is uniquely difficult to make any nuanced point about mouse usage because of the inertial pull of the decades old keyboard vs mouse argument, and the equally vapid “use both” argument. Talking about Acme’s design would have derailed things further.

I wasn’t advocating for mouse-friendly interfaces at all, by the way. My goal was only to point out that (i) there are times when using the mouse with Emacs is natural, although the specifics depend on your use of Emacs, and (ii) Emacs includes some features to improve mouse expressivity (gestures, configurable drag-and-drop, etc.)

This isn’t so much a problem with use-package as it is the primitives (autoload and with-eval-after-load) and the way Emacs manages load order with load-history. I don’t know that you can write a better macro to handle composite package configurations under these constraints. I also haven’t tried to, so maybe there is.

An actually declarative system will need something like a fixed point evaluator, and be much more complicated than use-package internally.

Practically speaking, the only solution right now is (i) proactive measures by package authors to shove all the bits meant for integration into separate file(s) and provide separate features, and (ii) knowledge of this organization on the part of the user.

Even this can be too much, magit-extras (which contains magit-project-status) is 900 lines, most of which you don’t need.

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.

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.

Github, MELPA

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?