Carsten Dominik <domi...@uva.nl> writes: > On Sat, May 5, 2018 at 8:02 PM Rasmus <ras...@gmx.us> wrote: > >> Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: >> >> > Hello, >> > >> > Steve Downey <sdow...@gmail.com> writes: >> > >> >> Asking users to accept any breakage in the tool they use to get work >> done >> >> is a lot. Changes in UI in emacs are opt-in. >> >> >> >> Even if the change is the right thing to do. >> > >> > I think some of you (basically, anyone thinking we should enable "<s >> > TAB" by default ;)) are missing the point. >> > >> > >> > The first important thing to understand is that, even if we enable >> > `org-tempo' by default, next Org release /will break/ for some of us. >> > >> > - It will break because `org-tempo' is only 99% backward-compatible. So >> > anyone having customizing templates is bound to change them. >> > >> > - It will break because there are 9 other incompatible changes between >> > 9.1 and 9.2. >> > >> > So, asking to load `org-tempo' by default just to avoid breaking users >> > set-up is a wrong argument. It will only "protect" those among us that >> > use "<s TAB" but didn't customize /and/ are not affected by the other >> > incompatible changes. IOW, updating Org from 9.1 to 9.2 will not be >> > smooth for everyone. No matter what `org-tempo' becomes. >> >> Nicolas, I have been wondering about something, reading all these posts, >> irrespective of whether tempo is loaded by default or not (I don’t care). >> >> Do you think org-tempo should try to detect "old" versions of >> org-structure-template-alist and give a better error if it sees one? I >> don’t know what the "best practice" is this case... >> > > Yes, it absolutely should.
Thanks. I guess it would be enough to check if the elements of the alist are cons (newer Orgs) or lists (older orgs). A more "complex" procedure could look for at the content of the ca?dr, I guess, but I don’t know if that’s necessary. Rasmus -- I feel emotional landscapes they puzzle me