Hi Ihor,
> > Not really. I am proposing to tag each package and option, which is much > > more easier and efficient to find and discover packages and options, and > > even > > individual choices, and maybe tag also other things like keybindings, > > installation methods, etc. > > It is already done in customize UI. Every package and option is tagged. > Tags are called "groups". Any custom option may have multiple groups/tags. I know the groups. It is not really what I expect to be used as tags, at least without modifications. > >> Again, auto-generating the UI text might be beneficial here - you may > >> pull parts of the interface from Elisp; maybe also pull some > >> package-specific config ideas from contributed packages. It may be > >> difficult to maintain one giant all-in-one config repository. > > > > It depends what you means by difficult. > > > > I think most users will contribute, because the project will be useful > > for everyone. If every person sends one package, or one option, or > > even one choice, the config will be easily filled. > > > There are many users actually using literate config, or willing to. > > So it is better if we can all have a central org config file(s) from > > which we can all pull our shared configurations, and easily tweak > > them. Also new user won’t have any difficulty to start with such > > file(s). > > A giant Org file is hard to navigate. > A large number of people also hate having "unnecessary" staff in their > config. So, what you propose is not necessarily going to be a good thing > for all users. I already mentioned in my first message that each package should be separated in its own org file. We can also imagine that users may choose what packages/files to use if they want to. > > Instead of everyone doing the same tasks again and again, we can all > > do it once for all (of course with the required maintenance). There > > is a lot of gain here for everyone. > > Maintenance is the main problem. What you propose, IMHO, is not going to > be easy to maintain. It again depends on what you mean by “not easy”. We all already do the more or less the same maintenance tasks in our individual configurations. So again, doing so in one place is beneficial for everyone. Other maintenance tasks are normal part of any similar project. Are you planning to start this project ? Or you are just giving an opinion on that ? > >> Instead, > >> you may build the overall configuration from pieces contributed by > >> selected specialized configuration. > > > > > > What do you mean exactly ? > > Rather than having a single huge configuration file, construct it from > multiple contributed per-package/topic configurations. Can you be more precise on how do you exactly imagine it ? > >> I strongly recommend starting from some kind of prototype that can be > >> tried by people. > > > > That is exactly what I am proposing, in case someone has time, because I > > don’t have time to do so, and I didn’t want to keep the idea for myself. > > > > I have done a prototype some time ago, to show the tag filtering : > > https://lists.gnu.org/archive/html/emacs-devel/2024-12/msg00174.html > > Sorry, but I feel completely confused about how to use that file after > opening it. > > > [ I also wanted to send a proposal to implement the tag filtering in org, > > but > > I also don’t have time to do so. Did you get the idea ? Is it something > > you > > can consider implementing in org ? ] > > What exactly are you proposing? Very briefly, I imagine a command that insert an org link (filter) for each tag, at the top of the file for example. Clicking on link1/filter1 will call sparse tree on tag1, and in the same time hide the other links/filters whose tags belong exclusively to the hidden headings. Clicking on filter1 again for example, will do the reverse steps. Clicking on filter1 and filter2, will call sparse tree on tag1 and tag2, etc. We can also image adding links/filters for properties too, etc. This is a know filtering mechanism. It needs to be adapted to org files. If the idea is still not clear, I can explain it in a dedicated message when I have time. > >> This kind of topic has been raised a number of > >> times on emacs-devel, with various proposals on the table. Nothing > >> materialized as a prototype though. > > > > I did not came across a similar org literate config approach. Can you send > > me some references to check ? > > > > (Note that my idea is not related to Emacs development itself. Otherwise I > > would have send my message to emacs-devel. But if you think that it should > > be discussed there, I will let you do the correct thing.) > > https://yhetil.org/emacs-devel/897ed591-43bc-4029-912a-917e5e9f6...@gmail.com/ > That's not quite literate config, but the UI can be done via Org mode as well. Thanks for the link, but I thought it is something close to what I am proposing. In this case the customization UI is already the closest. In any case, and as I mentioned in my previous messages, the idea is essentially towards users already using (or planning to use) org to customize Emacs. I also proposed a startup wizard in the minibuffer some time ago on emacs-devel, and I didn’t know that a similar idea was already on the table. And recently Elijah Gabe Pérez proposed a similar idea too : https://lists.gnu.org/archive/html/emacs-devel/2025-04/msg00475.html. This being said, what I am proposing here is something different, and I hope it can have the good amount of energy to push it forward, because it combines all the possible advantages of all the customization methods, while eliminating most controversial problems. (Again it is for current and future org users, though it requires very little org knowledge if any to use it. And if we add buttons, it can even almost becomes a UI). It should be easy to extend it by adding packages, options, choices, etc once the very basic foundation is there. It can also have a huge impact on new users starting with Emacs, like easily and quickly customizing Emacs, and also easily and gradually learning Emacs Lisp, etc. Regards,
