Hi Bastien, 2018ko maiatzak 8an, Bastien-ek idatzi zuen:
> Thanks -- I tested it. Thanks :) > I like the idea of sending a warning to the user for > backward-incompatible changes but in this case, well, we take for > granted that org-tempo will be turned off by default in the next > release... but this is not decided yet. Indeed, the patch was written under that assumption. If the situation changes, (at least) some tweaks would be needed. > > To be clear, the whole change still needs work for sure, and nothing > is decided so far. > > But here is some food for thought on how to deprecate an Org feature > more nicely. > > We have org-modules, which is an internal mechanism to load default > Org modules. Yes, this predates Emacs package system, and yes, we > should question the usefulness of it now (I do). > > But: what if [...] I like this idea, but I also think that emacsʼ packages feature is a better/newer way to implement something like this. What if: 1. We donʼt include org-tempo in org releases 2. We teach GNU ELPA to include org-tempo as a package (corresponding to stable org releases) 3. We teach <https://orgmode.org/elpa/> to also do so (corresponding to nightly org releases) 4. We implement your suggested user prompt, but it will ask them if they want to install the org-tempo package from ELPA In this way, users who either install org from GNU ELPA or use the version bundled with emacs will get the latest release version of org-tempo from GNU ELPA. Those who install the nightly version of org will get the corresponding nightly version of org-tempo.* WDYT? (An alternative to step 3 above is to cater for the nightly release users by putting org-tempo in org-contrib. Then we wouldnʼt have to publish org-tempo on Org ELPA, only GNU ELPA. But this (a) doesnʼt help those who install nightly org as opposed to nightly org-plus-contrib, and (b) means that org-tempo, unlike other packages in contrib, would have to be kept copyright-clean...so Iʼm not sure it is a good choice.) Aaron * Those of us who install org from git might have to do something else to make sure the right version of org-tempo is loaded, but weʼre used to living on the edge. :P -- Aaron Ecay
