Moakt Temporary Email <749106659...@drmail.in> writes: >> The group system in customize UI does something similar. > > 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. >> 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. > 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. >> 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. >> 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? >> 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. > By the way, do you use org to configure Emacs ? I configure everything https://github.com/yantar92/emacs-config/ -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
