Re: Strategies for Composable Modular Configuration?

[Psionic K]

If abstracting settings by grouping and naming them, yes, the result is
indirection.  I agree that this approach fails to deliver ROI.  IIRC both
Doom and Spacemacs style configuration involves named abstraction of groups
of settings and also cascading some settings into other settings
(composition, but without nearly the discipline of a Nix style solution).

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.
>

This is also an abstraction by naming style solution.  While it does make
declarations more generic, such declarations must be concurrently
implemented with broad consensus or else it will become  inconsistently
applied indirection.  The ecosystem cannot move in this way except for
problems of near ubiquitous frequency.

Superimposing configuration works differently.  Instead of the packages you
consume providing a generic interface, you would use a "pedals" declaration
that can produce every variation of just the additional contents that each
minibuffer configuration would need.  When adding all the declarations, if
the set doesn't exist, the contents are never calculated and the addition
is no-op.  The minibuffer packages don't care, and maintenance is
completely centralized into the one "pedals" declaration.

Because each group of users who wants a "pedals" can create and maintain it
without any cooperation with the packages they depend on, it's adding
opt-in cooperative gains without organizational complexity for maintainers
in the ecosystem.  It is not easier for the individual pedals users.  It is
easier for groups of users that are larger than individuals but much much
smaller than those with near ubiquitous problems.

Superimposing is a simple union of declarations.  For some strict subset of
possible use-package expressions (ones written with one preferred way for
everything instead of doing things however one pleases), it's trivial to
implement, can express everything, and is transparent to debug.  Discipline
in the Nix community with the introduction of Flakes has been very good to
the ecosystem.

We can leave composition alone.  Composition relies on a fixed point
calculation, a recursive lazy merge where declarations thunk on each other
until everything resolves or a loop is found.  The value add is not
incredible compared to the complexity.  For Emacs users, 90% of the
maintenance overhead and new user setup can be handled by simple union of
declarations.


On Wed, Nov 22, 2023 at 9:59 PM Nikolay Kudryavtsev <
nikolay.kudryavtsev@gmail.com> wrote:

> 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.
>
>

-- 

남백호
대표 겸 공동 창업자
포지트론