Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

[Cook, Malcolm]

Thanks for the re-cap.  

I'm changing my vote.

Make the change!  Change the default!  And make lots of noise advertising it 
(make more prominent https://orgmode.org/Changes.html , etc).

Someone suggested going to v10.x  Is there a case for this?

Thx of org!

 > -----Original Message-----
 > From: Emacs-orgmode <emacs-orgmode-
 > address@hidden> On Behalf Of Nicolas Goaziou
 > Sent: Tuesday, May 01, 2018 7:36 AM
 > To: Steve Downey <address@hidden>
 > Cc: Bastien <address@hidden>; Tim Cross <address@hidden>; Org-
 > mode <address@hidden>; Jon Snader <address@hidden>
 > Subject: Re: [O] [POLL] Should Org tempo be enabled by default? (expand
 > templates thru e.g. "<s[TAB]")
 > 
 > Hello,
 > 
 > Steve Downey <address@hidden> 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.
 > 
 > 
 > The second important point is there is a general design issue at stake.
 > Sorry, there is no pleasure in inflicting "torture" (as I read in this
 > thread) to users.
 > 
 >     Org is too big. Its (lack of) design is wrong.
 > 
 > This is not from me, but from some the Emacs developers, in particular
 > Richard Stallman. You may want to read the thread "Differences between
 > Org-Mode and Hyperbole" in emacs-devel mailing list archives for the
 > exact quote.
 > 
 > Org has to be big, because it is featureful. Yet, we cannot ignore the
 > remark. Also, that doesn't mean we cannot do anything to improve the
 > situation. Actually, there are, at least, two areas in which we can make
 > progress:
 > 
 > 1. externalize Org features that apply to other major modes, or drop
 >    them if there are equivalents to them,
 > 
 > 2. re-using (external) Emacs facilities for Org mode features that are
 >    not central for us.
 > 
 > Not so long ago, we provided footnotes for other modes, even though
 > "footnote.el" had been there for a long time. This clearly felt into
 > (1), so we dropped the feature. Recently, I wrote "orgalist.el", which
 > ports Org plain lists into other modes. I moved it out of Org core
 > because of (1). It is now available in GNU ELPA.
 > 
 > Expansion templates are a great thing, but this is only sugar for Org,
 > which is totally usable without them. Besides, some facilities are
 > providing it for us. This falls into (2). By design, I'm convinced we
 > should not include them. I also wish that anyone involved in this thread
 > can take a step back to see the whole picture.
 > 
 > The question is not about you using "<s TAB": you now know (require
 > 'org-tempo) could solve this. The question is not about breaking other
 > configurations: there always have been breakage and there will be again.
 > The question is about designing Org so it fits well -- better, at
 > least -- in the Emacs ecosystem. This means no unreasonable feature
 > overlap and enough modularity to be re-usable from other parts in Emacs.
 > 
 > 
 > Back to the current poll. It would be more efficient to think about
 > solutions to make the update less painful. In particular, how can we
 > tell users updating from ELPA about the necessary changes involved.
 > 
 > I remember that Magit experimented displaying a message the first time
 > you used a new release; you would silence it only by setting a variable.
 > I don't think this is the case anymore, so it may have failed, though.
 > We could also make the <https://orgmode.org/Changes.html> page more
 > prominent in the summary displayed along with the package.
 > 
 > 
 > Now back to the poll.
 > 
 > Regards,
 > 
 > --
 > Nicolas Goaziou
 > 
 > P.S: Bastien, would you please stop lobbying in every other
 > communication canal out there, that's not fair ;)