Re: Strategies for Composable Modular Configuration?

[Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com>]

This topic gets discussed here and there sometimes.

I think the first issue is configuration discoverability. You can run 
someone's init for org and see that you're having a much better 
experience, because of settings A,B,C. But there may also be setting D 
that you don't need. Setting E that actually makes it worse for you. 
Then for you there's actually an even better value for setting B.

Then there's the learning curve problem. Emacs already has quite a 
curve, but any third party configurations almost double it, because you 
now have multiple behavior providers - a thing may be a part of core 
Emacs functionality and the default. While some other thing is provided 
by a third party package X, bundled in your starter kit. Then there's 
the starter kit configuration layers on top of it.

Now onto your questions:

2. Considering your minibuffer package zoo example, I've been thinking 
that something akin to protocols from Clojure would work for this case 
as that extra layer of indirection that can solve those kinds of 
problems. Clojure protocols are its basic are a set of function hooks 
unified under one name. So, for example I decide to use the flight sim 
rudder pedals in my Emacs configuration. Obviously I want them to 
iterate over items. So lets say Emacs had 
item-iteration-binding-protocol. Which has next-item and previous-item 
hooks. Then every minibuffer completion package can implement that and I 
just need to bind my pedals to that next and previous item bindings for 
it to work everywhere. Very obviously this is the best case scenario and 
there would be numerous practical problems when it comes to implementation.

3. I have never played with Doom, but from my limited experience with 
it, Spacemacs seems to be doing as good of a job as possible with its 
layers system, considering the complexity of the problem.