emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A new filter-based customization interface [was: An anonymous IRC us


From: Eli Zaretskii
Subject: Re: A new filter-based customization interface [was: An anonymous IRC user's opinion]
Date: Thu, 12 Dec 2024 17:47:31 +0200

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]