Hello, Bastien <b...@gnu.org> writes:
> You seem to disagree as you just disabled Org tempo in commit 4c13d0a > ("Do not load Org Tempo by default"), saying: You disagreed with me in the first place with commit 71ad7b1. It was my original intent to not load Org Tempo by default. > I wonder what users on this list think, maybe I'm wrong. > > Should the old expansion mechanism "<s" be enabled by default? Some history first. We introduced a new expansion mechanism, recently bound to `C-c C-,'. This mechanism is more in line with usual Org functions: it operates on regions like, say, `org-insert-drawer'. It is an obvious default expansion mechanism. If the big menu, we could however improve it with an "expert" UI, like we already do for export and tags. Now, some users are used to "<s" constructs, and are not willing to switch to that expansion mechanism. Fair enough. I first suggested to use Yasnippets, which is powerful enough and easy to use. Some users still didn't want to use that. Well. I suggested Tempo, but, admittedly, out of the box, it is not really usable. Then Rasmus wrote Org Tempo. Even though Org Tempo is probably useful for a part of users, it is yet another occurrence of NIH in Org mode. Instead of using already available, and fitting, libraries for a task, we implement one. Also, it will probably prevent the default expansion mechanism to receive feedback, and therefore, improvements (even though it is better for basic uses) because users will not even notice the new mechanism if the old one works out of the box. IMO, Org Tempo should live outside of Org core, like many other Org-related libraries. Some die-hard "<s" users might be annoyed if they had to install an external library. So asking for a "(require 'org-tempo)" was an acceptable compromise, until your disagreement. Regards, -- Nicolas Goaziou