Hello Ihor,
Thanks for your reply, > So, it appears to me that you are re-implementing the customization UI. It is important for me to stress on the fact that this idea is essentially towards all users already using, or planning to use, org to customize Emacs. > Having a text version of customization is an interesting idea, Don’t forget that this was not the main goal in itself. It just happened that everyone is already using this “text version”. I am just proposing to enhance it. > but you > seem to be re-inventing things customization UI already does. > For example, your idea about "including everything" is already there in > customization UI, with various custom options and values defined by > packages in Elisp. In other words, your proposed text-based > customization interface can be auto-generated, at least in parts. If this is makes things easier, why not. But I think it will still need some manual modifications, and adding tags, etc. > On the other hand, your idea may allow more complex snippets to be > included into the UI, which might be something to explore. That’s is one of the many advantages of this approach, by sharing complex snippets, to have more choices for users to select from. > > A problem I can see, is when we will have a lot of packages. So maybe > > then we can separate each package into his own org file, while having > > a single main org file containing the tags/filters. The tag filtering > > should be made to work just like it works today for org agenda files. > > If org experts can give us some advice on if it is something > > reasonable to do, and what is the best approach. > > 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. > 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). 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. As I said in my previous message, no need to automate anything (add buttons, auto syncing files, etc.) or consider them as blocking. If these “nice to have” additions cannot be implemented (right away), it is not a problem doing things manually. The idea of having central file(s) for everyone to use is already important in itself. > Instead, > you may build the overall configuration from pieces contributed by > selected specialized configuration. What do you mean exactly ? > > Another thing, is how we can implement a way to keep someone’s local > > config org file(s) synced with the central config org file(s)’s > > modifications, without loosing local customizations. (Maybe we can > > assign an org id to each choice). > > If you auto-generate the config file as text, user choices will be > recorded via customie interface, so you can reconstruct them. I am not sure we are on the same page ? > > So if someone has time to do so, I think it is a very good idea, > > instead of every person struggling on his own through the exact same > > difficulties, and spending the same amount of time and energy in > > building their individual configuration file over the years, and > > without having a way to share them efficiently, so everyone can > > benefits from each other valuable work. > > 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 Though, it is missing many things. Someone can take it from there if they want. It is enough to start with few packages, and then I am sure, everyone will join. If the project contains only some packages, it is already a good thing. The packages should normally be added gradually over time, and I don’t really expect to have all packages right away, and before having something usable for the majority of users. [ 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 ? ] > Otherwise, you may be overwhelmed with various ideas > people already have. I think the idea I presented should be clear. Though, I would prefer to hear what others think about it, and share their inputs. > 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.) By the way, do you use org to configure Emacs ? [ If you know some people already using org + (use-package), and they are not on this list, and who might be interested in this topic, you can CC them if you want. ] Thanks again. I appreciate your time,
