From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Moakt Temporary Email <a01158486246@drmail.in>
Newsgroups: gmane.emacs.devel
Subject: Re: A new filter-based customization interface
Date: Mon, 13 Jan 2025 23:39:01 +0000
Message-ID: <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="19213"; mail-complaints-to="usenet@ciao.gmane.io"
To: emacs-devel@gnu.org
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 14 04:21:59 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 1tXXV9-0004uu-28
	for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Jan 2025 04:21:59 +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 1tXXUY-00085Z-23; Mon, 13 Jan 2025 22:21:22 -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 <a01158486246@drmail.in>)
 id 1tXUNZ-0003Ez-5G
 for emacs-devel@gnu.org; Mon, 13 Jan 2025 19:01:57 -0500
Original-Received: from [64.31.33.50] (helo=moakt.com)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <a01158486246@drmail.in>)
 id 1tXUNX-0004ti-HQ
 for emacs-devel@gnu.org; Mon, 13 Jan 2025 19:01:56 -0500
Original-Received: from tm-php.tm_tm-network ([172.18.0.6] helo=localhost.localdomain)
 by moakt.com with esmtp (Exim 4.92)
 (envelope-from <a01158486246@drmail.in>) id 1tXU1N-0001PE-Ka
 for emacs-devel@gnu.org; Mon, 13 Jan 2025 23:39:01 +0000
X-Mailer: PHPMailer 6.6.3 (https://github.com/PHPMailer/PHPMailer)
X-Host-Lookup-Failed: Reverse DNS lookup failed for 64.31.33.50 (failed)
Received-SPF: none client-ip=64.31.33.50; envelope-from=a01158486246@drmail.in;
 helo=moakt.com
X-Spam_score_int: -10
X-Spam_score: -1.1
X-Spam_bar: -
X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, FROM_LOCAL_DIGITS=0.001,
 FROM_LOCAL_HEX=0.006, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001,
 RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Mailman-Approved-At: Mon, 13 Jan 2025 22:21:20 -0500
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:328021
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/328021>

Hi Eli,



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

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

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.

And if we don’t do so, we loose the ability on doing the intersection between options later on, which is at the heart of the new interface, and which allow user to quickly/easily find and also discover options.

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.

I maybe have missed something ? WDYT ?


What about adding the packages ?
The actual interface does not show the options of unavailable packages.

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


Does this make sense ?



Thank you