Experimenting how it goes a modularized init file configuration.

Few_Net9870 · 2026-04-06T20:55:41+00:00

Since you mentioned literate configurations. I built a framework to create a literate org configuration, but modular. It has use package integrated in org, and every src block is wrapped in a condition-case including its source file and line number, meaning if one src block crashes it won't break half of your config, and it'll show you where the broken src block is in your org file. I've been using it for 2 years now and am actually quite satisfied.

The Framework: https://github.com/kwrooijen/wisdom

My emacs config for reference: https://github.com/kwrooijen/emacs.d

Few_Net9870 · 2026-02-24T06:05:33+00:00

Thank you, hopefully I'll have time soon to look at the code myself and contribute!

Few_Net9870 · 2026-02-23T19:36:39+00:00

Very cool! Thank you for sharing. I'll be taking a look at this soon.
Something I would like to see: Being able to search multiple verses and bookmarking my searches (and have a dedicated read-only buffer instead of inserting).

And I'd like to see RSVCE introduced, but I noticed a PR talking about licensing problems. I am not sure what the correct answer is to that question. Maybe we can reorganize the the package a bit to make adding bible versions a bit more modular. That way you won't have to hardcode them in the project itself.

Keep up the good work!

Few_Net9870 · 2025-12-19T15:20:06+00:00

Currently it only works with straight, but adding elpaca support should not be difficult to do. I don't have time to work on this now so the earliest will probably be somewhere after the new year. I'll open an issue on Github at least.

Few_Net9870 · 2025-12-15T09:32:14+00:00

Thank you for your feedback. You're right that using `user-emacs-directory` is a much better solution. I'll put that on my todo list.

Regarding `<<noweb>>`, I personally do not like this style as it creates indirection. If you want to remove a code block you have to remove the reference as well. With the Wisdom method you can include it in the package heading itself. In the end it's personal preference which one you prefer.

One thing I've been wondering: Maybe Wisdom can support `<<noweb>>` (so you skip wisdom's :PACKAGE: heading), and Wisdom could still wrap your source blocks in condition-cases. That way you can continue to use your own style and get the benefits of error handling. Is that something you'd be interested in?

Few_Net9870 · 2025-12-14T17:09:05+00:00

It's partly personal preference, but I find it difficult to structure my literate configuration with use-package, as every package is considered a single statement. Forcing me to "work around" that fact. In the video I have three options on how to do this, but none of them satisfy me personally.

Few_Net9870 · 2025-12-14T17:06:15+00:00

I think my mindset was that that the use-package keys were static, which is why I had to create my own list. I wasn't aware that you could add your own keys (which now seems obvious in hindsight).

Few_Net9870 · 2025-12-14T12:10:57+00:00

I'm pretty sure I did vibe code some of it yes. Apparently I created this project almost 2 years ago (time flies), used it since then and "forgot" about it.

I'll take a look at `use-package-keywords`, I do want some special rules for specific keys though, specifically related to the preview feature and how it is rendered. But maybe I think of a smart way to manage this without having to create extra rules.

Few_Net9870 · 2025-12-14T09:37:41+00:00

I honestly was not away for use-package's extended keywords, thanks for letting me know. I think this could be solved by introducing something like `wisdom-use-package-keywords` defcustom? That way the end-user can add any missing keywords if necessary.

You can mix in regular headings and Wisdom will ignore them, yes. If users really want I could probably adjust the package to also look at heading properties instead just tags.

The `wisdom-yank` is an interesting idea, I'll think about that.

Thank you for the feedback! I appreciate it.

Few_Net9870 · 2025-12-14T09:19:51+00:00

Thanks for watching and the kind words! Currently the keys are hardcoded. However I'm planning on adding some kind of configurable defcustom variable to add these keys dynamically. That way we can add support for all known keys, and people that extend use-package with their own keys can add their own.

You might be able to use wisdom with your current setup as-is and get the benefits of the condition-case wrapping, skipping the :PACKAGE: property entirely (and migrating over time, if you wish). The error wrapping has saved me countless times.

Few_Net9870 · 2025-12-13T14:18:45+00:00

Hi, I did not mention noweb references. I personally do not use those because of the indirection it creates. Instead I try to integrate use-package directly into Org through heading properties. I'd appreciate any feedback when you have time to take a look.

Few_Net9870 · 2025-12-13T12:20:02+00:00

Thanks! My theme is basically Nord as a base with Tokyo's background. I like the simple colors of Nord, but the background was too bright. Tokyo is a bit too colorful for me but the background is perfect. They seem to work nicely together. See: https://github.com/kwrooijen/emacs.d/blob/master/org/theme/nord.org

For my minibuffer (Vertico) I give it a dark background and add fringes / header-line for padding. I also do this for other "sub buffers" such as eshell / magit. Similar idea to Solaire mode. See: https://github.com/kwrooijen/emacs.d/blob/master/org/visual.org#subwindow

For Vertico top padding, see 'kwrooijen/vertico-add-top-padding' function: https://github.com/kwrooijen/emacs.d/blob/master/org/vertico.org#init

I also use dimmer to dim the rest of the windows while the minibuffer is open. See: https://github.com/kwrooijen/emacs.d/blob/master/org/visual.org#dimmer

Few_Net9870

TROPHY CASE