From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Psionic K Newsgroups: gmane.emacs.help Subject: Re: Strategies for Composable Modular Configuration? Date: Wed, 22 Nov 2023 22:58:40 +0900 Message-ID: References: <60ada9d4-8036-41d8-bdbf-012b8f5b2747@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27257"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Psionic K , help-gnu-emacs@gnu.org To: Nikolay Kudryavtsev Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 22 14:59:48 2023 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1r5nlc-0006rw-HP for geh-help-gnu-emacs@m.gmane-mx.org; Wed, 22 Nov 2023 14:59:48 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r5nky-0003Z3-39; Wed, 22 Nov 2023 08:59:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r5nkp-0003Xl-Tz for help-gnu-emacs@gnu.org; Wed, 22 Nov 2023 08:59:00 -0500 Original-Received: from mail-yw1-x112c.google.com ([2607:f8b0:4864:20::112c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r5nkm-00057J-Dx for help-gnu-emacs@gnu.org; Wed, 22 Nov 2023 08:58:59 -0500 Original-Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-5cb8a6e2dc0so20606647b3.0 for ; Wed, 22 Nov 2023 05:58:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=positron.solutions; s=google; t=1700661531; x=1701266331; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wv4IdR4goKgWmjoOtM+G98FwaIJRYotwMmLcusN1McI=; b=C5ouldyB4+VR2vyls18D7mol8XOTNuCZ/JdbLxWxzbCrHwalP1x5HXsJH/Ni/oipJr KiqraEfRQyaHbkxn2r7WTpuC8qZJY5Kee0E88uJH8SdgGoa0HBL9ZnJw8GioJhFog1G2 /fLlzgoX3ZyvmObPXOYeVXp2atj4AMRrypnFlJuwCfdcDmfW4+DYzSAK2fDNYmkRm5EX DNHbjSfe75FL7nbNIRWiMdzv9df2p1+gY9UgJhMGr3IAChLYsi01yPQKeD1Q6yjBQLCi Xuzi/80LVb7Sa7Mavn+cvD7i59m8l15Je2jXnTHYbu06BflY0EZlljt6o6qXVaRWArRX 5zoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700661531; x=1701266331; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wv4IdR4goKgWmjoOtM+G98FwaIJRYotwMmLcusN1McI=; b=MXMlDKlg5GMbVCodG3yFROnfJzu7VdZtgLibSym8q7AXK7AduTIfokoU+Cpbvb/7qp 4YqDCUURqfxPuXJfFDnkCcIMbIyiMY753bkCC505yF7gZ4atOfAXaaIAmbraXck68gkM McKDzPMCf4Igi0XUheSkidktdIgwaIhaTaPaFOXK+RizxLfUD60NzLjExxf8AtTf5E61 uzb3+9u5oEfmTfo0zULBRdUr+IZfNrQTPEGzgVT8iuOX4zuDCn7j16aUWV+MSYUMYKwP gPBmDXmAWxAWreWe5lFYZ/upi79gbyYLjFuZDrKT+swmlLB2jgVRMfDQdAtgwolD0plP 8+gA== X-Gm-Message-State: AOJu0YxAc9ITI3G4PrEdu8AByCTJHOBYtR9fLpHODFjKXJjnwCGghbAP i1GLub7IZV28xkrBVC/RAvNMCd9p9KdRDEyCwpV+KvBj1xD9F36WKE4= X-Google-Smtp-Source: AGHT+IFp20KofVOZ8uVGU4xZqr6d5kIfHk9zrcsKzWjoVUHF0KdkaRP7nVSSHROaLcy4EyJA6IOlvUVORv3SL9a5qNg= X-Received: by 2002:a0d:d756:0:b0:5cb:5171:ab07 with SMTP id z83-20020a0dd756000000b005cb5171ab07mr2297723ywd.12.1700661531567; Wed, 22 Nov 2023 05:58:51 -0800 (PST) In-Reply-To: <60ada9d4-8036-41d8-bdbf-012b8f5b2747@gmail.com> Received-SPF: pass client-ip=2607:f8b0:4864:20::112c; envelope-from=exec@positron.solutions; helo=mail-yw1-x112c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:145560 Archived-At: 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=E2=80=AFPM 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 implementatio= n. > > 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. > > --=20 =EB=82=A8=EB=B0=B1=ED=98=B8 =EB=8C=80=ED=91=9C =EA=B2=B8 =EA=B3=B5=EB=8F=99 =EC=B0=BD=EC=97=85=EC=9E=90 =ED=8F=AC=EC=A7=80=ED=8A=B8=EB=A1=A0