Not that anyone likely cares, but I just refactored my #emacs config away from literate org-mode, into a collection of specific elisp files. The top level init.el is now quite clean.
I got tired of having to edit source blocks in the org-mode config and having to preload org-mode just to load my config, all just so it looks prettier (?) when reading it on github.
The elisp files still have sections, rg can search them just fine. I'm happy. https://github.com/garyo/emacs-config
Maybe an init.org makes sense after your config has been stable and unchanging for 10 years... else it's just extra work to constantly delete/edit all the paragraphs that no longer describe the code. :/
So I found a situation where emacs -Q runs a loop 60x slower than my personal Doom Emacs config!
Any #emacs#lisp wizard who might have an idea why? It's as if it's garbage-collecting for a whole minute. It's not the loop itself that's slow, because it actually completes all iterations, and only then does Emacs hang.
@louis@kakafarm I just learned that a too big chunk of garbage invites something called OS paging... That's why gcmh-mode uses 16 MB as the "high" value.
@louis Often it's to do with mass-operations on org files, so I need to know files to avoid, like *.bak, logseq backups, syncthing conflict duplicates, whatever is in the user's org-roam-node-exclude-function...
Anyway, instead of making an user setting "ignore-paths" for every package I make, it'd be easier to instruct the user to have a good .ignore file.
@karthink@oantolin@ctietze So on first glance it's pretty cool but I realized there aren't that many embark actions as to need completing-read.
With the vanilla keymap prompter, all the possibilities fit in the popup window on my screen anyway. What is the appeal of completing-read-prompter? I guess it's to "search by typing" instead of by eye?
I can't figure out how to automatically filter mail in #mu4e into specific folders... Like take everything from the mailing list emacs-orgmode@gnu.org into its own maildir.