From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: A new filter-based customization interface [was: An anonymous IRC user's opinion] Date: Thu, 12 Dec 2024 17:47:31 +0200 Message-ID: <86ikrozywc.fsf@gnu.org> References: 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="16537"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Moakt Temporary Email <14b27f40fbf4@drmail.in> Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 12 16:48:52 2024 Return-path: 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 ) id 1tLlQp-0003yI-3Z for ged-emacs-devel@m.gmane-mx.org; Thu, 12 Dec 2024 16:48:51 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tLlPz-0006UL-Q7; Thu, 12 Dec 2024 10:47:59 -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 1tLlPw-0006U9-Uy for emacs-devel@gnu.org; Thu, 12 Dec 2024 10:47:57 -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 ) id 1tLlPw-0005ma-Ce; Thu, 12 Dec 2024 10:47:56 -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=QJZ5gX36PSHa151n4nJZbN01TGaN6EXHrj/VEbbkuQc=; b=J/BLtY67jwZrjLL6u6xN MpaJbqWUIEpPbNW7Xj4YHGdqrk8kI+RqqCbBy0z5j/paj+pnwL/TL418HyEdx+uEL5WnQ7muYfOYr 6UFMmBTkhG+VOpbuZ4NTyLZqfoYKCAr88jyu0taLnHt1e/lg8Nf6NAd5GJinj3AF1fMchAiqKA5gj HLfJYpJJzyPnmgAFoKJ52dyCXABkVqjxP0dCqEO5a5Tq/fOlQvRTBn39BGM3dtNYmuub6KTMRooSp RDKf3sCH9V015aMOLWX8KV1wvlrvFkXN+7f+VTxO0eTmQ0eU0rAWcjfaH8gxebeTwT0qIeKttzTTm M5NjrLnQHCNtLA==; In-Reply-To: (message from Moakt Temporary Email on Thu, 5 Dec 2024 05:43:08 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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:326429 Archived-At: > Date: Thu, 5 Dec 2024 05:43:08 +0000 > From: Moakt Temporary Email <14b27f40fbf4@drmail.in> > > New implementation idea: > ======================== > A “filter-based” ui customizations (instead of q&a in the minibuffer): > > The main idea is to give user the ability to easily “filter” on customizations and thus quickly customize emacs for his needs (using “familiar” terms of course). > > This will also, be a nice way for user to have a quick and global overview of what emacs can do. > > The idea has many other advantages as you will see below. > > I implemented a prototype in an org file (which you can find at the end of this message), using org “sparse-tree” to filter customizations (please consider opening it in emacs before continuing), when opening the org file, the “startup” elisp source block will be executed to define the “newpack-toggle-filter” function, which will be called when clicking on some [[elisp:]] org links (filters), and 2 other functions to be called interactively (check below). > > > There are 3 main sections in this org file: > 1. “filter by”: contains the filters that user can choose to filter the customizations. > > 2. “sort by”: contains the sorters to sort customizations. > > 3. “Selected Customizations”: the list of customizations (This list can maybe be displayed in another buffer if needed, also to make room for the other sections if necessary, and also for user not having to scroll up and down. Or maybe allow user to customize this behavior). I see where you are coming from, but for Emacs there's a significant downside here: the number of combinations will explode if done properly. That's because the number of useful categories of Emacs features is very large, and their combinations are a legion. We already have "M-x customize-group", which by default shows the list of top-level groups. IMNSHO, what we have there is not very useful. Just type "M-x customize-group RET RET" and see for yourself. For example, it to0ok me quite some time to find where the "Windows" group is, although customizing windows is really a very basic thing in Emacs, and I expected it to be one of the top-level groups. So maybe a first useful step is to overhaul our customization-groups system (the starting point is at the beginning of cus-edit.el, where you see a series of defgroup calls). I think having a rational and useful hierarchy of customization groups can be a significant step towards the goal of letting new users find customization options they look for quickly and efficiently. Once we have good customization groups, we could think about supporting intersections of groups. But note that this requires to audit the available defcustom's and assign more than one group to options for which it makes sense. Thanks.