Moakt Temporary Email <1ceb37432...@drmail.in> writes: > After I proposed a new customization interface for Emacs [1], I jumped > on the occasion to rewrite my literate org configuration to replicate > this interface idea there. > ... > * package1 :tag1:tag2: > ** option1 :tag3:tag4:tag5: > - [ ] choice1 > - [X] choice2 > - [ ] choice3 > ** option2 :tag4:tag5:tag6: > ** option3 :tag5:tag6:tag7: > ** install > ** load/enable feature > ** keymap/keybinding > * package2 > same here. > .... > We can also add buttons/links (for new users) to select a given choice, and > to save/tangle the modifications into the init file. (I am adding/removing > “tangle” header arguments, and calling ‘org-babel-tangle’ manually for the > moment. Not complicated after all). The org file can also be enhanced in > many other ways. > > If we want to also tag and/or reference individual option’s choices, (which I > find very useful in many cases), we should use org headings instead of org > lists. > > There is not need to argue which archive, package or option to > include/exclude, etc. We can include literally everything. Anyone can send > his favorite package(s), option(s), and even individual choice(s), and also > the favorite method to install a package, etc.
So, it appears to me that you are re-implementing the customization UI. Having a text version of customization is an interesting idea, 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. On the other hand, your idea may allow more complex snippets to be included into the UI, which might be something to explore. > 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. 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. Instead, you may build the overall configuration from pieces contributed by selected specialized configuration. > 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. > 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. Otherwise, you may be overwhelmed with various ideas people already have. 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. -- 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>
