Hello, Bastien <b...@gnu.org> writes:
> Here is what the experience can look like: > > - Upgrading Emacs or Org (hurray!!) > - Trying to hit <s as usual one month after the upgrade > - Thinking your stupid [...] I have an issue with this argument: it can be opposed to virtually any backward-incompatible change we make. There are actually 10 such changes in Org 9.2. Would it makes sense to remove them because some users, unfortunately, will encounter a workflow break upon updating Org? I totally agree this is an issue, yet, we have to move forward. We can make UX consistent across releases, but we cannot guarantee 100% compatibility at each step. As a data point, I don't know any software that preserves the exact same UX after each release -- Firefox, Gnome, I'm looking at you! There are unavoidable gotchas. This just means Org is still vivid. > In fact, I'm inclined to ask the real question: if org-tempo is on by > default, who will have good reasons to turn it off and why? This is one problem: only a few will have a reason (good or bad, who cares?) to turn it off, e.g., because expansion gets in the way with other templating systems. Possibly even fewer will actually turn it off. As a consequence, the vast majority of users will keep using "<s" -- and put maintenance burden on us -- instead of trying, and improving something else. Inertia... I already stated the following, sorry for re-iterating. Marking a region and wrapping it in some environment is a basic operation Org is expected to provide. We already did with `org-emphasize'. Implementing programmable templates, even though we are re-using what Emacs ships with, is another story. Org Tempo is a nice tool. I'm not questioning this. It is also almost 100% compatible with previous feature. Yet, it competes with external Emacs libraries, as capable as itself. Since it is not a feature mandatory in Org, why forcing it onto the users? I'm inclined to think we shouldn't. Regards, -- Nicolas Goaziou 0x80A93738