Re: A new filter-based customization interface

[Moakt Temporary Email]

Hi Richard,


Thank you for taking my proposition into consideration.


> Would you like to familiarize yourself with M-x configure and related
> commands, see what it does and what it doesn't do, and describe
> your idea in terms of how it differs from what we already have?
>
> Do the differences concern manner of display, or the semantics
> of the customization methods?

I listed below some of the differences that come to my mind first:


- make better choices:
many things can be done in emacs, in different ways, filtering on a specific 
topic, can show user that he has alternatives to what he is trying to 
accomplish.



- discover-ability:
emacs has many options/features (even little ones), that are of big help/change 
for users, in their daily use of emacs, and they often discover them (very) 
late.



- self-descriptive:
The interface by itself, before even using it, describes what emacs can do.
(Yet emacs can do many other things that should be added to the interface)



- navigation
I find it difficult to navigate back and forth in the actual interface.

Most softwares have a fixed menu to the left, that is always there, to which 
you can always refer.  And also sometimes tabs to the right (for each entry in 
the left menu), for which also you can always refer.

With the actual interface sometimes you also loose the sense of where you are.  
You can only see the direct parent group, and also sometimes you need to scroll 
to see it, other times you find multiple direct parent groups which can be 
confusing.

With the new interface, we can avoid this.
we can display all the filter section in a buffer, and all the resulting 
options in another buffer, which gives the user a more pleasant navigation 
(although we are comparing two different concept for finding the options).



- beginner-friendly
Using terms that users may be already familiar with.  Users can be coming from 
different backgrounds.



- gradually introduce users to emacs vocabulary
While most of the filters would use familiar terms, there are some that are 
emacs-specific.  This makes users realize that these words are 
important/special in emacs.
For example: face, overlay, minibuffer, keybinding, keymap, font-lock, 
narrowing, mark, region, kill ring, mark ring, etc.

User should have been already introduced to the other more important ones 
(modeline, frame, window, echo area, buffer, command, etc.), which are _really_ 
needed to start using emacs. (check the side note below)



- intuitive
emacs has a huge number of options, for which some are candidate to more than 
one group, and can have also some side effects on other things happening in 
emacs or on the user system, etc.  So the most intuitive way I can think of is 
to use tags.



- visually
I did not add anything special to the interface, yet it already looks nicer.
With little modifications it can be even better, we can for example use some 
colors, icons, etc.



- important options when starting with emacs:
There are somehow “known” options that user would normally add/change first 
when starting with emacs, we can put them forward, when the user opens the 
interface for the first time, or group them together under a specific filter.



- extensible/flexible
The interface can be extended to include any sort of filters.
For example, we can let user filter on options depending on emacs versions 
[...] [27] [28] [29] [30] [deprecated], or if option is safe or not, etc.



- help/learn:
I can see the same questions are being asked from emacs users, on platforms, 
(how can I do this ?, etc.), while in there very question, you can find the 
necessary keywords, that if they use in this interface, they would easily find 
what they are looking for.



- help/troubleshoot:
many questions are also related to problems, (having this behavior when doing 
this action, or emacs became very slow, etc.). These keywords can also be used 
to find the corresponding responsible option(s).



- attractive
Users are often attracted by what they see first, if an image of the new 
interface (yet to be enhanced/modified) is posted on emacs website, or on some 
platforms, will be more appealing to users, than an image of the actual 
interface.


- more informative
We can instead of displaying filters like this:
 [modeline]  [window]  [frame]  [tab]

we can add a counter of the underlying options like this:
 [modeline(30)]  [window(25)]  [frame(10)]  [tab(15)]



- user’s tags/filters:
We can give user the possibility to tag the options himself. (by workflow, 
project, task, work, home, friend, favorite, check later, laptop, etc.)
These tags would automatically appear in the interface.



- accurate results
doing a text search might not find the option user is looking for, maybe 
because the keyword is not included, or the keyword is wrongly written, or 
written differently, for example “modeline”/“mode line”, or maybe a synonym of 
the keyword was used.

Sometimes, user may get options he was not looking for, because it happened 
that the keyword is present in the text.



- possible search keyword(s)
new users often don’t really know what to search for.  For example, user should 
search for “auto-completion” or “auto-fill”, “cut” or “kill”, “paste” or 
“yank”, “region” or “selection”, “cursor” or “point”, “color” or “font” or 
“face” or “theme” or “appearance” or “visual”, etc.

while trying different keywords in the actual interface, user will get some 
results (and mostly different each time), which bring more confusion.

And even though, it happens that user chose the correct keyword(s) from the 
first time, and as the results are not guaranteed to be accurate (check 
previous section), this might bring even more confusion.



- excluding tags:
This interface would normally filter on intersection ([a] AND [b]) between 
selected filters.
But sometimes user would need to select [a] AND [b] AND ![c].
I don’t see the usefulness of doing a union [a] OR [b], but it can also be 
implemented using this interface, if needed.



- task-oriented
When users choose emacs (or any other software), it is to accomplish a given 
task first (agenda, spellcheck, irc, etc.), this interface (a) will enable 
users to quickly find the options related to the given task.

If someone may find that these tags should be represented in another way (b), 
or someone else prefers (c).

We can give the user an option to choose between interface (a), (b) or (c), 
with one of them being the default.



-package integration: [^1]
we can also integrate packages, so user can easily find the needed package(s), 
and install them (their corresponding options would be then added).
It would be somehow similar to what “M-x finder-by-keyword RET” does.

This will also be a nice and straight-forward way to gradually introduce user 
to package ecosystem in emacs.



- user’s commands integration: [^2]
We can also tag the commands in the same go, so user can easily find the 
command(s) he needs to accomplish a certain task, the same advantages above 
would apply here.



- other symbols integration: [^3]
Also tagging the other api functions, variables, hooks, macros, etc, which will 
be a great help for users/developers trying to learn and/or write their own: 
(the same advantages above would apply here too)
+ to see if it already exists, before doing so.
+ to search which api they can use, for a certain task, in their own functions.
+ to find some similar functions, as an example/inspiration to what they are 
trying to accomplish (if the “exact” functionality is not already implemented).
+ to “discover” the available api gradually.



- other
tagging the options might have other usefulness than for using them for this 
interface.  Some tags can be more internally oriented, and not intended to be 
used/shown to user.




[^1], [^2], [^3]:
For these, they can be in a separate interface, or we can add them to the same 
interface, for example as below:
- filter by type: [option] [command] [variable] [function] [macro] [hook] 
[package]




Side Note:
----------
I wrote a “Get Started” introduction to emacs, and showed how it can be nicely 
integrated in the current Startup buffer, to guide the user when opening emacs 
for the first time (or even referring to it later as needed), and I would like 
to know your opinion on it.  It is the HTML code at the very end of the 
following message: 
https://lists.gnu.org/archive/html/emacs-devel/2024-10/msg00245.html.



I am proposing a global idea to make starting with emacs much easier and 
intuitive for newcomers and deferring any (long) reading material to later on. 
(this will also be useful for everyone)



Thank you