Re: A new filter-based customization interface

[Moakt Temporary Email <059393ccf4a8@drmail.in>]

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