A new filter-based customization interface [was: An anonymous IRC user's opinion]

A new filter-based customization interface [was: An anonymous IRC user's opinion]

[Moakt Temporary Email]

Hi everyone,

I hope that the persons who were first interested in this discussion, will re-jump to contribute and share their point of view.

Eli, I came up with a “filter-based” ui idea, to implement the customizations, instead of the minibuffer q&a I previously proposed, which I think, will solve all the concerns you enumerated. I described it at the end of this message, I will answer your questions/comments first.


> I'm probably missing something because in the HTML you posted this
> part is basically empty.  It mentions Customize in general terms, but
> that's _how_ to customize Emacs, not _what_ to customize.  How is the
> user supposed to know which variables/features to customize?
>
> What did I miss?


I mentioned that the questions are to be listed. I also added a link to my first message for more details, and to see some questions as an example.

To have an even better idea, I added this time around 35 customizations and more details in this message (more information on that later).

I used normal “sentences” for each customization, instead of the previously suggested “questions”.


> This is an idea that has come up before, more than once.  I think
> everyone agrees that it's a good idea.  The hard part in this is to
> come up with a good sequence of questions, which would address
> different usage patterns that Emacs can support.  I don't think I've
> seen any attempts to do this which are close to completion, I only saw
> this idea being described and discussed, and a few attempts to produce
> a starting point.  If you can post the more-or-less full list of
> questions (which will probably be a tree or a DAG, not a linear list,
> since the user should be asked quite early what are his/her needs that
> they want to accomplish with Emacs, and perhaps also what are their UI
> preferences.), please do: I think this could be a very good step in
> the right direction.


You are totally right, I started something that should give a better view and also make it easier to contribute to (more info at the end of this message), but it will be difficult for me to have a complete list, or even an almost complete list, for many reasons, one of them is that this involves multiple packages which I did not have the chance or the need to use, etc.

This may also be the main reason why there are always attempts to produce “starting points”, and never something complete. This is hardly achievable by a single person and needs multiple contributors. So maybe it is time to gather some efforts to push this to success.

If every person reading this message adds his preferred customizations for his preferred package (that he uses and/or maintains and/or knows very well), the list will be quickly and easily completed. I added an org file to the end of this message which facilitate this. The process needs to be organized of course (share this org file in a collaborative way, etc.).

I think a very limited but useful subset is just fine, more customizations can be added later (maybe based on users feedbacks/contributions/requests on this).

This is an example org entry representing a customization:
* create backups of modified files:         :backup:
:PROPERTIES:
:Variable: make-backup-files
:Package: emacs
:UI_element: checkbox
:END:

To add other customizations to the provided list, one or more of the following (in addition to the sentence) need to be provided (more info on that at the end of this message):

- What is the sentence user should see for this customization.
The sentence should be as short as possible, should uses beginner friendly terms as much as possible, and should be coherent with all other sentences. (to be added to the org file, as an org entry heading)

- if the sentence is not already obvious, what description is to be given to the customization. The description should also be as short as possible, should use beginner friendly terms as much as possible, and should be coherent with all other descriptions. (as heading’s content)
Normally this should be also a link to a documentation. It is up to you to decide how you want to implement this part.

- Which variables are involved in this customization (as “:Variable:” org property)

- Which packages are involved (as “:Package:”)

- What ui element to customize it: field, checkbox, etc. (“:UI_element:”)

- What are the list of choices to be given, if applicable (“:UI_choices:”)

- What actions to be done if user pick a given choice (:Action:),
Or you can add an org source block (#+BEGIN_SRC #+END_SRC) to the entry for a detailed explanation of what needs to be done (as elisp code) for a given customization choice.

- add corresponding org tags to the entry (add the tags to the top of the org file first, if they are missing)

- add any other useful information.

More info on that at the end of this message.


> I think https://emacs.amodernist.com/ is a good starting point, but
> IMO it is nowhere near being complete.  I see the following ways to
> improve it:


I totally agree.

I may have been misunderstood, in fact I am not asking to add this implementation to emacs, it has some problems (in addition to the ones you listed), one of them is that it is only useful to generate an init file, so user will not be able to modify _some_ customizations later, without going through all of them again, etc.

I mentioned it, because its the only thing and nearest I found, that can save me from going into details, while representing the global idea/goal I wanted to communicate (it was given to me by someone in #systemcrafters channel, when I first tried to propose my idea there), which is “to make emacs starts with a useful configuration in a quick way for almost any user”. The author just implemented the idea differently. I think many had the same idea before, but it seems no one else did try to implement something, except him, which I think is a good starting point.

I don’t know why this idea, as a whole, did not find its way into emacs earlier, it is _very_ important addition to emacs.

I think every user who started using emacs asked the same question:

“I did all this to start using emacs. Now, how can it be made easier for other newcomers not to go through all this ?”, or in other words:

“How I would like starting with emacs to be, if I am a new user and just discovered emacs ? not only for me, but also not to hesitate when recommending emacs for others.”


>   . More background information on the features it asks about, so the
>     readers could make up their minds about using them.  For example,
>     it asks about Org without actually telling much about it: how is
>     the reader supposed to know ehether he/she wants it?  It generally
>     assumes that the readers already know what they want and need just
>     to be pointed to the Emacs feature which implements some
>     functionality.  A good example is "Version Control" -- are we sure
>     everyone knows what this is about?


There are 2 cases:
1. user can discover them outside emacs (a blog, a friend, ...), then he can be pointed out that he can use emacs for these, and he should be able to setup and start using emacs in a very short time.

2. user can discover these through emacs itself, while using it for other tasks (in the customization interface, manual, …), he needs to understand them first by reading their respective documentation to know if these can suites his needs, and after that he should be able to setup and start using emacs for these, in a very short time too (in addition to other customizations he is already using in emacs).

A very short description and/or a “learn more” link can/should be added next to the corresponding customization to point user to some documentation.


>   . It leaves out many popular and important features in Emacs.  One
>     notable example is email; another is access to remote files; yet
>     another is debugging and the built-in GDB front-end; etc. etc.
>   . The "Miscellaneous" section at the end is a very small subset of
>     convenience features Emacs offers, and should be greatly expanded
>     and classified into groups (otherwise it will be a very large
>     unsorted list of unrelated settings, which will be hard to read
>     and understand).  It also needs to describe each feature in more
>     than just a single sentence.


I agree.


> If you want to code a customization interface that is based on asking
> questions, then doing that for complex values might be difficult or
> cumbersome.  As a simple example, how do you propose to let users to
> customize a face by asking questions instead of having checkboxes and
> fields?  The basic disadvantage of asking one question at a time is
> that the user doesn't see the whole picture, and also that there's no
> easy way of going back to a previous question and answering it in a
> different way.


Ok, lets drop the q&a in the minibuffer.

I have a new “filter-based” ui idea of the implementation of this part, I hope it will have everybody’s agreement. More information on that at the end of this message.


> If a developer already knows about LSP, and already decided LSP server
> is the best solution for what the developer has in mind, then yes.
> But what if the developer doesn't know about the alternatives Emacs
> provides that don't require an LSP client?  Setting up an LSP server
> is not a trivial task, so if Emacs provides an alternative, the
> customization helper you describe should give enough information for
> the developer to consider these alternatives and make up his/her mind
> about the one best for him/her.  E.g., many people don't know about
> etags and the many languages it supports, or about ElDoc and its
> backends other than LSP-driven Eglot.  IMO, the customization wizard
> should mention those.


This is basically similar to the question above (on org and version control), so the answer is similar for LSP client:
1. if the user knows about LSP and is pointed out to use emacs for this, then lets give him a way to start using emacs in the shortest time possible.
2. if the user discovered LSP through emacs, than he probably discovered the alternatives too at the same time.

The _main idea_ is to give new users the quickest way possible to _start_ using emacs for whatever they want (and let them discover many things _later_), no need to overwhelm users from the start.

New users also can be using different softwares for different tasks, and emacs can offer to replace them, so users should be given a quick and easy migration path (one task/software at a time) to emacs, by keeping what they are using first, and then discovering other things _later_.

That being said, the new “filter-based” ui customization implementation idea is very flexible, and can do what you are asking for.


> We don't recommend reading the manual in its entirety anywhere.
> Instead, we recommend reading those chapters and sections in the
> manual that are relevant to the job in hand.  The manuals are well
> indexed and organized to allow this method and to make it
> time-efficient for our users.


I agree, I am one of them, I did not read the entire manual.
But many things needs to be read before being able to customize emacs using the customization interface or manually editing the init file, and installing packages, etc.



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


Using the filters, user should be able to:
1. choose a single filter.
[Try to click on “window” filter for an example].
- This will show only customizations related to windows in emacs. (done)
- This can also show a “window[X]” filter to make it easy to deselect the “window” filter and also to know on what the user has already filtered on (not done).
- This can also hide all other filters, that will render an empty customizations list, if additionally chosen by user (not done).

2. remove a single filter.
[Try to click on “window” again].
This can also be achieved by clicking on a “window[X]” (not done).

3. choose multiple filters.
[Try to click on “window” again (to reselect it) and then click on “auto-save” filter].
This should show customizations for “window” _AND_ “auto-save” (done)

4. reset all filters (not done)


The filter mechanism itself is very well known, and has slightly different variants (add the “X” or not to the selected filters, put selected filters in a separate list, color selected filters, etc.), it is up to you to decide how to implement it.

Only some of the filters for the first 3 categories (“interface”, “general” and “editing”) will work. All other links are empty and added only to show the filters classification.

The most important filters to add first to emacs are “by category” filters, this is what the user should see when he opens the new “filter-based” customization ui.

For example filtering on “ide” or “irc client” will list all customizations user needs to change (or maybe keep the defaults for some), to turn emacs into an IDE or an IRC client, etc.

Filtering on “startup” will list all customizations involved when emacs starts, etc.

Filtering on “auto-save” will list all customizations involved in auto-saving things, not only for auto-saving modified files, that is why I added it under “general” and ”editing” (it can be more specific if needed, by adding, for example, an “auto-save-file” tag as child of the actual “auto-save” tag, to filter only on customizations involved in auto-saving modified files. This is very flexible), etc.

The classification should not follow the packages “separation”, specially when not beginner friendly. For example, user needs to filter only on “completion”, no need to add “in-buffer-completion”, “minibuffer-completion” and “dabbrev-completion” filters (this is not only non-beginner friendly, but also will make the filter cumbersome). The sentences in the resulting list of customizations, should be enough to tell the user what he will get as completion behavior. If the list is too long, maybe some other filters can be added to help user further narrow the list.

When user choose to filter on “completion” for example, all the packages’s filters will be hidden, leaving only completion related packages visible like “corfu”, “cape”, “vertico”, “abbrev”, “dabbrev”, etc. These can be used  to filter on a specific completion behavior (this is for more advanced users of course).

Maybe an “auto-completion” filter can be added (as “completion”’s sub-filter), to further narrow the filtered list on auto-completion’s customizations, but this will make the ui more cumbersome for little user benefit, specially if the resulting list of customizations is already very short, and user can easily find what he wants when first filtering only on “completion”, etc. (I may have given the wrong example here, because there are multiple auto-completion customizations. So this should only be taken as an example on how to decide whether or not to add more filters, etc.)

Some mechanism should be implemented if the filters and classifications are numerous to fit nicely on the screen. Maybe the most popular filters are to be added first (user can also be given a customization variable to customize this behavior), and add a “more” link at the end of each line, for user to click on, to display more filters, etc.

For example the “auto-completion” filter, mentioned above, can be easily hidden under “more”. When user filters on “completion” first, many filters will disappear, making room for “auto-completion” to become visible, and then user can use it to further narrow the list, etc.

Emacs can also do many other very important things, but I did not complete the filters list and their classification, because you know emacs better then me, but what I added should be enough to give you a clear idea.
Please consider changing anything that does not suites you.

The other non-”by category” filters are also useful and can be added (maybe later) to the interface, and many of them should start as hidden, and user should click “advanced filter” to see them.

1. For example the “by package” filters are somehow advanced for a new user, and at the same time useful for a later use, and is also a nice way to introduce new user to “packages” in emacs.
If the list is too long to fit nicely, maybe the most popular packages can be explicitly added, and clicking on a “more” or “more packages...” link can show other packages, etc. (the actual list is not completed of course)

2. The “by system resources” filters are also useful so user can be aware of what is happening on his system, and to fix some “obvious” problems due to bad customization choices (before searching the internet, or asking other emacs users, etc), for example:
- to give user a hint about which customizations are using the disk to store some files (backup, save cursor, …), or may read/write intensively on disk (if not well customized), or may use lot of disk space (undo-tree history, …)
- same can be done for customizations using the network.
- customizations that calls/depends on a binary on the system.
- customizations that may consume lot of cpu if not well customized (like the delay, and the number of character, before start suggesting auto-completion candidates, …)
- customizations that may consume lot of memory if not well customized.
- etc.

Many other filters can be added, for example:
- if customization ships with emacs (built-in) or needs a package from GNU ELPA archive.
- show only customizations that have default values (or the opposite).
- etc.

Some sorters can also be added to sort the customizations list. (not done)

As emacs is highly customizable, maybe the ui itself will also be customizable, giving users the ability to:
- hide/show classifications/filters/sorters.
- rearrange them in the order they prefer.
- define their own classifications/filters/sorters.
- preselect filters/sorters to be applied when opening the ui.
- change the filters colors.
- etc.


I added ~35 customizations, each customization as an org entry:

- The heading contains the sentence.
 
- I added a preselected customization state (between []), at the end of each heading, only for example (can be removed if not necessary).

- to quickly open the actual documentation for a customization/variable, type M-x newpack-describe RET while point is on the corresponding entry.
(some customizations may involve more work than just modifying a single variable: adding hooks, installing packages, …)

- to quickly open the actual customization interface for a customization/variable, type M-x newpack-customize RET.

- each customization entry has some org properties, and one or more org tags (used by the filters too). (tags are inherited by default in org, so no need to add the _same_ tag for the underlying entries/customizations. But these can have their own additional tags of course).

- to filter on customizations belonging to some specific package for example, the package names can be added to each customization entry either as an org tag (:@org:, :@undo-tree:, :@eglot:, ...) or inside org :PROPERTIES: for example “:Package: eglot” (I used the later).


This org file can be used as a prototype, before implementing the UI, and also to have the customizations list, and for example to:

- mark already done customizations as “DONE” (this means all info needed to implement this customization are completed), and add any other useful task lifecyle.

- give priorities to know which ones are to be added to emacs first.

- add some :PROPERTIES: for each customization, as state previously, for example:
:PROPERTIES:
:Variable: 
:Package:
:UI_element: => checkbox, drop-down, field, …
:UI_choices: => visible, hidden, enabled, disable, always ask,…
:Action: => what should this customization do when user pick a choice…
:Other: => etc...
:END:

- add a #+BEGIN_SRC #+END_SRC, to explain what the customization will do as elisp code.

Once everything is completed and agreed on, ui implementation can start.


The elisp code, for each customization (that will be written to the customization file) can be kept/shown in the ui (first hidden, to be expanded by the user), which will also be a very nice way to introduce new users to elisp in general, and in the same time to emacs variables, hooks, etc.

For example, when user choose not to show the startup buffer, he will see the following elisp code, if he clicks on some “show source” link/button:
#+BEGIN_SRC emacs-lisp
  (setq inhibit-startup-message t)
#+END_SRC


I think the differences between this new ui and the actual customization interface are obvious, but I will enumerate some:

- Use beginners friendly terms as much as possible when describing the customizations.

- propose customizations from GNU ELPA archive, and automatically install corresponding packages.

- propose to automatically configure hooks for some basic/common/popular choices. For example showing line numbers for source code only.

- avoid using elisp regex as much as possible, try to give user some basic/common/popular choices that will fill some predefined regex for him. (for more choices, user will then need to learn and write regex himself).

- use the “filters” to easily navigate and customize emacs.

- filters classification by category is a very nice way to discover emacs features without being overwhelmed, easily picking what user needs, etc.

- classification of filters are also beginner friendly.

- also introduce new users to “package” ecosystem in emacs in a gradual way.

- also introduce new users (mainly devs) to elisp language (and emacs variables, hooks, etc.) in a gradual (and somehow educational) way.
This will also make them realize that emacs can be easily tweaked for more specific needs beyond the provided customizations.


I hope you understand what such a feature can bring to emacs.

Thank you all for your time.


Note: This customization interface will of course needs introducing user to some emacs vocabulary before-hand (window, frame, modeline, …). That is why I proposed a “Get Started” introduction to emacs, that you can find in a previous message https://lists.gnu.org/archive/html/emacs-devel/2024-12/msg00064.html.
Please consider having a look at it too, and sharing your thoughts.


==============
ORG FILE BEGIN
==============
#+STARTUP: overview hidestars indent hideblocks hidedrawers
#+COLUMNS: %25ITEM %1PRIORITY %4TODO %20Variable %10Package %TAGS
#+TAGS: [ ui : modeline toolbar menubar scrollbar theme frame window font tabbar ]
#+TAGS: [ general : startup quit backup session mouse_scrolling navigation minibuffer_history keybindings ]
#+TAGS: [ editing : auto_save completion spellcheck cursor undo_redo ]

#+NAME: startup
#+BEGIN_SRC emacs-lisp :results silent
  (defvar-local newpack-filters '()
    "Contains user selected filters as list of strings.")

  (defun newpack-toggle-filter (filter)
    "Add/Remove FILTER to/from the filters list and create a sparse tree according to the new list content."
    (if (member filter newpack-filters)
        (setq newpack-filters (delete filter newpack-filters))
      (push filter newpack-filters))
    (org-match-sparse-tree nil (mapconcat #'identity newpack-filters "")))

  (defun newpack-describe ()
    "Open documentation for entry at point"
    (interactive)
    (describe-variable (intern (org-entry-get nil "Variable"))))

  (defun newpack-customize ()
    "Open customization for entry at point"
    (interactive)
    (customize-variable (intern (org-entry-get nil "Variable"))))
#+END_SRC


- Column view: [[elisp:(org-columns t)][On]]  [[elisp:(org-columns-quit)][Off]]




- Filter by:                                                 [[<< reset filter >>]]
  1. category:
    - [[elisp:(newpack-toggle-filter "+ui")][interface]]: [[elisp:(newpack-toggle-filter "+modeline")][modeline]] [[elisp:(newpack-toggle-filter "+toolbar")][toolbar]] [[elisp:(newpack-toggle-filter "+menubar")][menubar]] [[elisp:(newpack-toggle-filter "+scrollbar")][scrollbar]] [[elisp:(newpack-toggle-filter "+frame")][frame]] [[elisp:(newpack-toggle-filter "+window")][window]] [[elisp:(newpack-toggle-filter "+font")][font]] [[elisp:(newpack-toggle-filter "+tabbar")][tabs]] [[theme]]
    - [[elisp:(newpack-toggle-filter "+general")][general]]: [[elisp:(newpack-toggle-filter "+startup")][startup]] [[elisp:(newpack-toggle-filter "+quit")][quit]] [[elisp:(newpack-toggle-filter "+backup")][backup]] [[elisp:(newpack-toggle-filter "+session")][session]] [[elisp:(newpack-toggle-filter "+minibuffer_history")][command inputs]] [[elisp:(newpack-toggle-filter "+keybindings")][keybindings]] [[elisp:(newpack-toggle-filter "+auto_save")][auto-save]] [[elisp:(newpack-toggle-filter "+navigatiion")][navigation]] [[elisp:(newpack-toggle-filter "+mouse_scrolling")][mouse scrolling]]
    - [[elisp:(newpack-toggle-filter "+editing")][editing]]: [[elisp:(newpack-toggle-filter "+auto_save")][auto-save]] [[elisp:(newpack-toggle-filter "+cursor")][cursor]] [[elisp:(newpack-toggle-filter "+undo_redo")][undo/redo]] [[elisp:(newpack-toggle-filter "+completion")][completion]] [[elisp:(newpack-toggle-filter "+spellcheck")][spellcheck]]
    - [[ide]]: [[completion]] [[LSP client]] [[linting]] [[highlighting]] [[debugging]] [[build]] [[version control]] [[diff]] [[issue tracking]]
    - [[internet suite]]: [[web brower]] [[irc client]] [[email client]]
    - [[note-taking]]: [[Outline]] ([[edit]] [[view]] [[search/filter]] [[import/export]] [[fields/columns]]) [[meeting minutes]] [[zettelkasten]] [[flashcards]] [[checklist]] [[literate programming]]
    - [[personal information management]]: [[habits]] [[reminders]] [[calendar]] [[agenda]] [[journal]] [[address book]] [[RSS/Atom feeds]] [[spreadsheet]]
    - [[task management]]: [[lifecycle]] [[priority]] [[effort-estimation]] [[scheduling]] [[deadlines]] [[time-tracking]]
  2. package: [[emacs]] [[org]] [[package]] [[which-key]] [[undo-tree]] [[vertico]] [[corfu]] [[cape]] [[marginalia]] [[orderless]] [[flymake]] [[eglot]] [[eldoc]] [[etags]] [[tramp]] [[saveplace]] [[savehist]] [[desktop]] [[recentf]]
  3. system resource:
     - [[disk]]: [[none]] [[read]] [[write]] [[intensive read]] [[intensive write]] [[high peek usage]] [[high long term usage]]
     - other: [[network up]] [[network down]] [[system packages]] [[high cpu]] [[high memory]]


- Sort by: [[package]]


* Selected Customizations:
** create backups of modified files:     [X]                        :backup:
:PROPERTIES:
:Variable: make-backup-files
:Package: emacs
:UI_element: checkbox
:END:
*** create multiple (numbered) backups for each file:        [only for files that already have some]
:PROPERTIES:
:Variable: version-control
:Package: emacs
:Introduced: 17
:END:
**** number of old (numbered) backups to keep for each file:         [2]
:PROPERTIES:
:Variable: kept-old-versions
:Package: emacs
:Introduced: 17
:END:
**** number of new (numbered) backups to keep for each file:         [2]
:PROPERTIES:
:Variable: kept-new-versions
:Package: emacs
:Introduced: 17
:END:
** auto-save modified files:      [X]                            :auto_save:
:PROPERTIES:
:Variable: auto-save-default
:Package: emacs
:END:
*** idle time before auto-saving modified files:      [30 seconds]
:PROPERTIES:
:Variable: auto-save-timeout
:END:
** move files to trash when deleted:     [X]                        :delete:
:PROPERTIES:
:Variable: delete-by-moving-to-trash
:END:
** save frames, windows and buffers configuration between sessions:      [always ask]                :frame:window:buffer:session:
:PROPERTIES:
:Variable: desktop-save
:Package: desktop
:END:
*** idle time before auto-saving:        [60 seconds]           :auto_save:
:PROPERTIES:
:Variable: desktop-auto-save-timeout
:Package: desktop
:END:
*** idle delay before loading files  (from previous session):       [5 seconds]                 :startup:
:PROPERTIES:
:Variable: desktop-lazy-idle-delay
:Package: desktop
:END:
*** number of files (from previous session) to be loaded immediately (no delay):      [2]                     :startup:
:PROPERTIES:
:Variable: desktop-restore-eager
:Package: desktop
:END:
*** how to handle loading of deleted files:         [print error to *Messages*]                     :startup:
:PROPERTIES:
:Variable: desktop-missing-file-warning
:Package: desktop
:END:
** save cursor position (in each file) between sessions:       [X]              :cursor:session:
:PROPERTIES:
:Variable: save-place-mode
:Package: saveplace
:END:
** save provided inputs to commands :        [X]                      :minibuffer_history:session:
:PROPERTIES:
:Variable: savehist-mode
:Package: savehist
:END:
*** time between auto-saving inputs:         [300 seconds]            :auto_save:
:PROPERTIES:
:Variable: savehist-autosave-interval
:Package: savehist
:END:
*** remove duplicate inputs:         [X]
:PROPERTIES:
:Variable: history-delete-duplicates
:END:
*** number of "file names" provided as inputs to save:        [20]
:PROPERTIES:
:Variable: file-name-history
:Package: emacs
:END:

#+BEGIN_SRC emacs-lisp
  (put 'file-name-history 'history-length 20)
#+END_SRC
** startup buffer:      [disabled]                        :ui:startup:
:PROPERTIES:
:Variable: inhibit-startup-screen
:Package: emacs
:END:
** tool bar:          [hidden]                                     :toolbar:
:PROPERTIES:
:Variable: tool-bar-mode
:END:
** scroll bar:        [visible]                                  :scrollbar:
:PROPERTIES:
:Variable: scroll-bar-mode
:Package: emacs
:END:
** menu bar:        [visible]                                      :menubar:
:PROPERTIES:
:Variable: menu-bar-mode
:END:
** add a menu item to open recent files (under the "File" menu):       [X]                       :menubar:session:
:PROPERTIES:
:Variable: recentf-mode
:Package: recentf
:END:
** organize windows (by grouping them) under tabs:       [enabled]              :tabbar:
:PROPERTIES:
:Variable: tab-bar-mode
:END:
** display current column number in the modeline:       [X]               :modeline:
:PROPERTIES:
:Variable: column-number-mode
:Package: emacs
:END:
** display current line number in the modeline:       [X]          :modeline:
:PROPERTIES:
:Variable: line-number-mode
:Package: emacs
:END:
** display line numbers for files:      [X]              :ui:buffer:
:PROPERTIES:
:Variable: global-display-line-numbers-mode
:Package: display-line-numbers
:END:
** keybindings help window:       [enabled]              :ui:keybinding:
:PROPERTIES:
:Variable: which-key-mode
:Package: which-key
:END:
*** idle delay before displaying keybindings help window:         [1 second]
:PROPERTIES:
:Variable: which-key-idle-delay
:Package: which-key
:END:
** undo/redo:        [enabled]                           :undo_redo:
:PROPERTIES:
:Variable: global-undo-tree-mode
:Package: undo-tree
:END:
*** save undo/redo changes (for each file) between session:       [ ]                       :session:
:PROPERTIES:
:Variable: undo-tree-auto-save-history
:Package: undo-tree
:END:
** use  C-z/C-x/C-c/C-v key bindings for undo/cut/copy/paste:       [X]                      :editing:keybinding:
:PROPERTIES:
:Variable: cua-mode
:Package: cua-base
:END:
** location of file containing emacs customizations:       [~/.emacs]                  :startup:
:PROPERTIES:
:Variable: custom-file
:Package: emacs
:END:
** system font:        [ignore]                                       :font:
:PROPERTIES:
:Variable: font-use-system-font
:END:
** confirmation when closing emacs:       [always ask]           :quit:
:PROPERTIES:
:Variable: confirm-kill-emacs
:END:







* [ Needed to bootstrap the "startup" source block ]
# Local Variables:
# eval: (progn (org-babel-goto-named-src-block "startup") (org-babel-execute-src-block))
# End:
============
ORG FILE END
============

Re: A new filter-based customization interface [was: An anonymous IRC user's opinion]

[Eli Zaretskii]

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