From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Eli Zaretskii <eliz@gnu.org>
Newsgroups: gmane.emacs.devel
Subject: Re: A new filter-based customization interface
Date: Tue, 14 Jan 2025 14:58:16 +0200
Message-ID: <86sepltuvr.fsf@gnu.org>
References: <UUHX2wciGlBnAoGA0j4wLhMqN8pTN44tqswovM7lIE@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214";
	logging-data="6348"; mail-complaints-to="usenet@ciao.gmane.io"
Cc: emacs-devel@gnu.org
To: Moakt Temporary Email <a01158486246@drmail.in>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 14 13:59:43 2025
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>
Envelope-to: ged-emacs-devel@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 <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>)
	id 1tXgWD-0001Ua-KB
	for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Jan 2025 13:59:41 +0100
Original-Received: from localhost ([::1] helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <emacs-devel-bounces@gnu.org>)
	id 1tXgVU-0000vG-JI; Tue, 14 Jan 2025 07:58: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 <eliz@gnu.org>) id 1tXgVT-0000v5-1B
 for emacs-devel@gnu.org; Tue, 14 Jan 2025 07:58:55 -0500
Original-Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@gnu.org>)
 id 1tXgVQ-0007t0-El; Tue, 14 Jan 2025 07:58:53 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
 Date; bh=0tsb3clgrjTABIOwrZOpPGUaGJUMrJtCKDwA+X48Hv8=; b=Pb2XrtbJrS1AML7eDMjA
 SOLws5juLojRbMQoj1eJvJ5qmLsSGkLWdjMUoYeuqupgl2luSfJLUCkuK2lVA8HHyetzslI9vRalJ
 xrDS/Jgz8oo+3fAUpJA1JPOayg+ItUywc9GfwF0DVyOAMvnhLdRbn77iLXCxhdkuEKAvBURTeA08j
 yQ18k16TmSHeCd5qkLZnKsFhMAVb7LTrWtGecAqOfJ1PF8shcqBLWA2jiMmocXk+LxbA9tsQdquOE
 uVnrSdp87aVX07jjmCuRLbYougoHa2S9yzI7huGSealoEuYjVu2UdYNRSxuOxUlWQzpa0keKc9f2p
 VHistAwgD+3BAw==;
In-Reply-To: <UUHX2wciGlBnAoGA0j4wLhMqN8pTN44tqswovM7lIE@localhost.localdomain>
 (message from Moakt Temporary Email on Mon, 13 Jan 2025 23:39:01
 +0000)
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Emacs development discussions." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=subscribe>
Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org
Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org
Xref: news.gmane.io gmane.emacs.devel:328046
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/328046>

> Date: Mon, 13 Jan 2025 23:39:01 +0000
> From: Moakt Temporary Email <a01158486246@drmail.in>
> 
> > Since we already have customization groups and commands to present
> > them and allow users to look for the group(s) they need and customize
> > the relevant aspects, I feel that improving our groups (which
> > currently look not very rational or even helpful).  The next step
> > would be to support intersection	s of groups.
> > 
> > WDYT?
> 
> I am glad, you got the idea I am trying to communicate.
> 
> The groups definitely need to be improved, but wouldn’t that break backward compatibility for users that might be using the current interface, and/or the associated commands and groups ?
> 
> Maybe also some user’s code exits today, to auto-manipulate these groups, that might break ?

I think we should first come up with a reasonable set of groups, and
deal with the backward compatibility issues afterwards.  One almost
trivial possibility is to _add_ new groups instead of renaming the old
ones, so that backward compatibility is preserved (an option can
belong to more than a single group).  And there are possibly other
ways to solve the compatibility problem.

> It may also take non-negligible amount of time, that can be put towards the new interface ?

It is true that coming up with a good set of groups is a significant
task.  But the advantage is that the Customize interface has all the
rest already solved: a rich, graphical interface that is capable of
customizing complex options, including built-in access to
documentation and Help, etc.  This will save a lot of work that will
otherwise need to be invested for starting the UI from scratch.

> Another important question is that, can we really use the groups for “tagging” options ?
> 
> If, for every option, we add the corresponding potential tags, as groups, the actual customization interface tree can explode in size, and become unmanageable and difficult to find the option, and groups might even finally have a higher number of options for the user to go through.

Each customizable user option already has a group tag.  We just need
to change them (or add new groups) so that users could customize a
group of options that they are interested in.

Having large groups is indeed a danger, but we are already there: we
currently have a small number of very general groups, each group very
large.  We can make this better by using sub-groups (which are also
already supported).  Later, we could introduce a feature whereby users
could request to see options that are the intersection of several
groups, i.e. they belong to several groups at once.  We could also add
more features that could allow finding the options easier.

My point is that if we go that way, a lot of the necessary
infrastructure already exists and is well documented.  We use it all
the time when adding new options.  This is a good system, it's just
that its categorization needs to be improved.

> If we also make an option appears in too many places in the tree, which is meant initially to be navigated/browsed as such, it can be tedious and confusing for users.

No one in their right minds navigates the entire tree of Emacs
customization groups.  Neither are they supposed to.  They should be
able to start from the group that suits their needs.  Coming up with a
good set of customization groups will actually allow that.

> What about adding the packages ?

Each package comes with its own customizable options, and those should
also have groups defined for them.

> The actual interface does not show the options of unavailable packages.

That's true.  But again, we can add that in the future.  The problem
here is to have a place from which to fetch the data, and that problem
will exist no matter what method and UI you will choose.

> To make up for that, we can at least, in the new interface, let users also easily browse/find/discover the packages, and install the ones they need, and then the corresponding options would appear in the interface (so they do not miss some potentially useful features, they can add, while filtering on a given topic).

We already have an interface to package archives (M-x list-packages),
and we could build on that to help people find packages in a more
refined way.