From: Eli Zaretskii <eliz@gnu.org>
To: Moakt Temporary Email <a01158486246@drmail.in>
Cc: emacs-devel@gnu.org
Subject: Re: A new filter-based customization interface
Date: Tue, 14 Jan 2025 14:58:16 +0200 [thread overview]
Message-ID: <86sepltuvr.fsf@gnu.org> (raw)
In-Reply-To: <UUHX2wciGlBnAoGA0j4wLhMqN8pTN44tqswovM7lIE@localhost.localdomain> (message from Moakt Temporary Email on Mon, 13 Jan 2025 23:39:01 +0000)
> 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.
next prev parent reply other threads:[~2025-01-14 12:58 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-13 23:39 A new filter-based customization interface Moakt Temporary Email
2025-01-14 12:58 ` Eli Zaretskii [this message]
2025-01-14 16:52 ` [External] : " Drew Adams
2025-01-14 18:37 ` Ihor Radchenko
-- strict thread matches above, loose matches on Subject: below --
2025-01-14 0:07 Moakt Temporary Email
2025-01-19 20:54 ` Björn Bidar
2025-01-14 0:01 Moakt Temporary Email
2025-01-13 23:44 Moakt Temporary Email
2025-01-09 13:46 Moakt Temporary Email
2025-01-10 3:24 ` Richard Stallman
2025-01-10 15:29 ` Björn Bidar
[not found] ` <87o70eptze.fsf@>
2025-01-16 0:06 ` Richard Stallman
2024-12-31 11:49 Moakt Temporary Email
2025-01-02 4:36 ` Richard Stallman
2025-01-02 4:36 ` Richard Stallman
2025-01-02 4:36 ` Richard Stallman
2025-01-02 4:36 ` Richard Stallman
2025-01-02 4:37 ` Richard Stallman
2024-12-16 22:02 Moakt Temporary Email
2024-12-31 4:43 ` Richard Stallman
2024-12-09 3:37 Moakt Temporary Email
2024-12-10 19:56 ` Philip Kaludercic
2024-12-12 4:48 ` Richard Stallman
2024-12-24 4:51 ` Richard Stallman
2024-12-24 21:10 ` Björn Bidar
[not found] ` <87bjx0oki1.fsf@>
2024-12-26 4:30 ` Richard Stallman
2024-12-29 15:29 ` Björn Bidar
[not found] ` <87o70ucxt5.fsf@>
2024-12-31 4:43 ` Richard Stallman
2025-01-01 20:00 ` Björn Bidar
[not found] ` <87o70quwxo.fsf@>
2025-01-16 0:06 ` Richard Stallman
2024-12-26 4:30 ` Richard Stallman
2024-12-27 2:04 ` Madhu
2024-12-27 13:07 ` Jean Louis
2024-12-27 15:16 ` dick.r.chiang
2024-12-28 5:58 ` Joel Reicher
2024-12-29 20:02 ` Björn Bidar
[not found] ` <87a5ce1clq.fsf@>
2024-12-31 4:43 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86sepltuvr.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=a01158486246@drmail.in \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.