emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates


From: Aaron Ecay
Subject: Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Date: Sun, 06 May 2018 21:02:18 +0100
User-agent: Notmuch/0.26 (https://notmuchmail.org) Emacs/27.0.50 (x86_64-pc-linux-gnu)

Hi Rasmus,

2018ko maiatzak 5an, Rasmus-ek idatzi zuen:

> I don’t like it, I’m afraid.  

Iʼm sorry to hear that.

> It’s a bit nagging.

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.

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]

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

(The patch I posted on the mailing list had a bug, which would trigger
the warning more often than it should be.  If you installed and tested
the patch from my email message, you would have seen that bug.  I pushed
a followup commit to the org-tempo branch in the repo that fixes the
bug.)

> 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.

> > 
>> One remaining decision to make is: what is the future of org-tempo?  I am
>> sympathetic to the idea that the best place for it eventually would be
>> org-contrib or GNU ELPA, and not org core.
> 
> We don’t have make that decision now, do we?

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.”

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

-- 
Aaron Ecay



reply via email to

[Prev in Thread] Current Thread [Next in Thread]