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: Fri, 24 Nov 2023 10:52:38 +0900 Message-ID: References: <60ada9d4-8036-41d8-bdbf-012b8f5b2747@gmail.com> <30a1af86-ec8f-4371-95fa-2246bdf955da@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="8888"; 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 Fri Nov 24 02:53:35 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 1r6LNu-0002A0-MV for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 24 Nov 2023 02:53:34 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r6LNI-0006y0-7h; Thu, 23 Nov 2023 20:52:56 -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 1r6LNG-0006xn-GM for help-gnu-emacs@gnu.org; Thu, 23 Nov 2023 20:52:54 -0500 Original-Received: from mail-yw1-x112b.google.com ([2607:f8b0:4864:20::112b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r6LNE-0001rf-92 for help-gnu-emacs@gnu.org; Thu, 23 Nov 2023 20:52:54 -0500 Original-Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-5ce0a888492so1919147b3.3 for ; Thu, 23 Nov 2023 17:52:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=positron.solutions; s=google; t=1700790770; x=1701395570; 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=TQPYn3tRcdWBoy82hW4NDQhyrcMygTtBlU6htT9HmAo=; b=H4Msn3Jh9ruLoGPB6TDfmfzEyA9hLM+oJgo7xf4lJnKBgGkoEmZKMaZJUVHZa4jEhV yUd2WSlWGau/7D9FCvmiczxwmXxrPEWLV4ZFmqt6a27YAJSWceYSHX4qoUGu6+RudxGN RGEk3rqYIVSyLFbvEPhymxPOScu9hClAwtM/D9fBIgASeV7DIHFLOcwk5JsKG95CdKf4 SZnY2oyAGCks++JX017D4BL006nJb+v3pdyb0FBtWTcDndbKSW+FeyfP+syELF0iyYxb 9d72u6NBn+W6QivbGbytpYzOGvfZUc/fiafGX8HzIDDrbIf2r1xCtRmQelW6XBh+5W+i wlpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700790770; x=1701395570; 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=TQPYn3tRcdWBoy82hW4NDQhyrcMygTtBlU6htT9HmAo=; b=PDoIrd+ZI4QtvKIdJjW3KZdkrJk+/XQEHYztxEcHdyEUquHC4s7NtHOZYmJpKBBfBE Xebl6o7CKfUf/Fmt5SDykceHuxjGwODjwb/enMmaxDw8whKR4RWTHCS/6eLAHsXAyJIo IObQRFN2QnwCwJrxCl1QoUA2qxNEu9pP/QeJsr8fme8qFqkQLqZ0iqf2Ph8hrlfw7mpG gEmMxMGbUp/oPK3uAHKds2Jhmx5FItFG/S1jwVGqTbGwCALRFaaCrWu+OE0KX37kUlFO H2YgGrh8FIUKfdR+63s6PU8keuF5/MwyhxPibFZCvzLeLUw3E9WjTx+HqeUfivXlW98K rp+w== X-Gm-Message-State: AOJu0YxaM3/FhuEC/h15cAwWQAwJucChy56le9X259CkwHBy7OtEvASZ ixe/8rJ2L/1WCU8bCGSYtt6EJwgi/OPBiF8Br5/GjSU8/suhcmCcUJk= X-Google-Smtp-Source: AGHT+IHQ3vvLzo5kn6h3oaBvoCaj1Wk6QvN75KgFjxAAfOmhXpPLPOPwG2hMaPbXW5lpG9jhxnAL54c7wNnn9M6kj8w= X-Received: by 2002:a81:6cd5:0:b0:5cb:b5fd:c0c3 with SMTP id h204-20020a816cd5000000b005cbb5fdc0c3mr1092918ywc.16.1700790769913; Thu, 23 Nov 2023 17:52:49 -0800 (PST) In-Reply-To: <30a1af86-ec8f-4371-95fa-2246bdf955da@gmail.com> Received-SPF: pass client-ip=2607:f8b0:4864:20::112b; envelope-from=exec@positron.solutions; helo=mail-yw1-x112b.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:145565 Archived-At: My rough sketch of a solution is a more strict subset of use-package expressions that are merged by union. Detect conflicts. Support automatic and hands-on resolution. Track changes and notify the user when changes are available. If use-package were not eager and just collected declarations until the user said, "Okay that's all my declarations, now execute the ones that aren't no-op." We would be free of the 1:1 correlation between use-package expressions and packages configured for loading. For configurations that are made across several packages, their declaration would be untangled. Can we do this now? I don't know if some use of defer enables this behavior, but I have never seen an example or evidence of support for use in this way. Composition, the calculation of one set on another set, I don't think is necessary to do away with 80% of boring configuration, where the defaults are at odds with what's popular among users. Any composition will build on top of things that are better for union aka superimposition, so union must be supported before composition anyway. If a users only agrees with 75% of the 80% of popular settings, they still have only 40% of the configuration overhead. This works in maintenance because if changes made over time are only being rejected at a 25% rate, the you end up doing 40% of the work, and most importantly, you would see those changes as new conflicts rather than having to keep track of each package's evolution. The market rate can adjust to fit the ROI. For instance, if you agree with 99% of a small 20% of extremely unpopular values, depending on them instead of setting and tracking them yourself is almost a pure time save. Regarding Flakes and ecosystem health, to understand the kinds of mistakes that were being made by the uninitiated masses, you can't look at good organizations, but instead must look at middling organizations and bad organizations. The free-for-all approach to creating expressions without any structure lead to such oddities as operating Nix impurely and articulating CI and even deployments. It was a case of using something within the limits of what worked, and there were no limits because it's a programming language. Flakes made these extreme misadventures obviously wrong enough for them to stop happening. Being strict about whether each symbol is loaded removes implicit dependency, and then side-effects that are order-dependent don't rely on flukes of the loading order and even user behavior to work every time. The subset of really nice use-package declarations users do already fits well with the subset that is trivial to merge in union. On Thu, Nov 23, 2023 at 8:19=E2=80=AFPM Nikolay Kudryavtsev < nikolay.kudryavtsev@gmail.com> wrote: > I'm not sure that I fully understand what you're suggesting... I've been > a casual Nixos user for years and even contribute from time to time, but > nothing made me really care about flakes. So to try and explain this in > a more practical manner, it's something like this: > > There's a portal lets say emacs-tweaks.gnu.org. It operates much the > same way as a package repository, but the contents of it are not > features(packages), but tweaks(flakes, pedals, whatever). The difference > between a feature and a tweak is roughly that features implement new > behavior, while tweaks just modify existing features to some requirement. > > Your definition of tweaks also does not allow for composition. Which > means that most of them are limited to a single feature, which IMHO is > not going to provide much ROI either. Because most of those tweaks are > going to be isolated single variable tweaks and that's not where the > problem lies. It's also not going to fully take over most of the > configuration needs because you can't re-implement Spacemacs(on Doom, > whatever) using such a limited system. > > Correct me if I misunderstood anything. > > --=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