From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Psionic K <psionik@positron.solutions>
Newsgroups: gmane.emacs.help
Subject: Re: Strategies for Composable Modular Configuration?
Date: Fri, 24 Nov 2023 10:52:38 +0900
Message-ID: <CADQMGAT_257DiasBO2f0j7SOTR7vF4tewtzNrx3DKg=thJctvg@mail.gmail.com>
References: <CADQMGARAW=DKqgLpgKsRkpj+irzCbwwsnFTQGYKC4g6NrMCPqA@mail.gmail.com>
 <60ada9d4-8036-41d8-bdbf-012b8f5b2747@gmail.com>
 <CADQMGAS6TyszQrgCqjFYEZ3=iO0-meFTpJ0-LhgLgZeAvwTHXQ@mail.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 <psionik@positron.solutions>, help-gnu-emacs@gnu.org
To: Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com>
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: <help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org>
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 <help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org>)
	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 <help-gnu-emacs-bounces@gnu.org>)
	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 <exec@positron.solutions>)
 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 <exec@positron.solutions>)
 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 <help-gnu-emacs@gnu.org>; 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 <help-gnu-emacs.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/help-gnu-emacs>,
 <mailto:help-gnu-emacs-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/help-gnu-emacs>
List-Post: <mailto:help-gnu-emacs@gnu.org>
List-Help: <mailto:help-gnu-emacs-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/help-gnu-emacs>,
 <mailto:help-gnu-emacs-request@gnu.org?subject=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: <http://permalink.gmane.org/gmane.emacs.help/145565>

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