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

[Rasmus]

Hi Aaron,

Thanks for the reply.

Aaron Ecay <address@hidden> writes:

> I wouldnʼt call it nagging.  The user presses “<s[TAB]” expecting
> something special to happen.  The status quo is that nothing at all
> happens.  My proposal is to make something special happen.  Itʼs
> different than what the user expected, but it informs them of what has
> changed and how to get the old behavior back if they want.

They’d already have the "old" behavior if it’s enabled by default in
org.el.  Perhaps I’m too cruel or harsh after many years of dealing with
the Emacs-way, but I do think that such as change is adequatly documented
in ORG-NEWS and the manual.  (Days after a new release there will also be
a stackoverflow question for the Googlers).  I sometimes open many new
Emacs on any given day, sometimes loading my init.el sometimes not.  I
imagine the message would get old quickly.

> Note that the only circumstance when the “nagging” happens is when a
> user presses “<s[TAB]”, and it goes away when either they add
> “(org-tempo-global-mode)” to their .emacs or learn a new habit of
> pressing C-c C-, instead of <s[TAB]

I’m perfectly happy with my (Emacs) habits :)  

> (We could make the warning appear only once per emacs session, if that
> seems like a better balance.)

Yes, that would be a must.

>> There’s tools to mark thinks as obsolete in Emacs should we need to.
>
> There are tools to mark functions and variables obsolete when they are
> used in elisp code.  There is no way of warning a user about non-code
> changes to the user experience, like (in this case) a changed key
> binding.

Customize-changed would bring up the changes to
org-structure-template-alist, which mentions Org Tempo.

ORG-NEWS as well.

But now I’m going in circles.

> We donʼt strictly have to.  Obviously one approach to making the
> decision is to wait and see whether org-tempo is widely adopted/used,
> and remove it from core if not.  But if we* can already decide on
> principle that something like org-tempo belongs best in contrib or
> ELPA, then we can communicate the relevant info all at once when 9.2
> is released, rather than for 9.2: “now add (require 'org-tempo) to
> .emacs to keep using <s[TAB]” [...time passes, a new org release is
> born...]  “now you also have to install org-tempo from somewhere
> else.”

Perhaps.  As I said, I like batteries included, but it’s not for me to
decide.

> *Here Iʼm using “we” loosely, I imagine it will mostly be up to you with
> input from Nicolas and Bastien and perhaps others.

I like the looser definition!

Rasmus 

-- 
Dung makes an excellent fertilizer