From: Tim Cross <theophilusx@gmail.com>
To: Jon Snader <jcs@irreal.org>
Cc: Bastien <bzg@gnu.org>, Org-mode <emacs-orgmode@gnu.org>
Subject: Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Date: Tue, 1 May 2018 12:00:53 +1000 [thread overview]
Message-ID: <CAC=50j_AH2kcmHLA1rr7T8JMZvJiuxYqp3L+oNP2hWAeeXxNDg@mail.gmail.com> (raw)
In-Reply-To: <m24ljsb9p2.fsf@irreal.org>
[-- Attachment #1: Type: text/plain, Size: 2737 bytes --]
On 1 May 2018 at 08:39, Jon Snader <jcs@irreal.org> wrote:
>
> Tim Cross <theophilusx@gmail.com> writes:
>
> [Snip]
>>
>> Personally, I feel the new version should be the default and we should
>> provide an easy way to re-enable the old version for those who wish to
>> continue with what they are use to.
>>
>
> We already have this. The problem, as you say, is
>
> how we communicate this to existing users.
>>
>
> But here's what I don't understand: what, exactly, is so bad about
> leaving the old behavior enabled by default. The new behavior is still
> available and naive users don't get surprised. What's not to like?
>
The problem is that if the old behaviour remains as the default, then that
is what new users will be introduced to and the improved new functionality
won't be seen. If the new behaviour is the default, there will be a small
period of adjustment for existing users, but new users will be benefiting
from the changes immediately. For many existing users, restoring the old
behaviour is just adding a require to their setup, so it isn't a lot to
ask. (I believe there will be some power users with lots of custom blocks
who may be more impacted, but as I understand it, whether the new or old
functionality is enabled by default doesn't really change the situation for
them anyway as they will have to take additional steps to migrate their
custom block settings). The real issue isn't about changing the default as
much as doing whatever is possible to inform existing users of the change
and how to restore previous behaviour if desired.
In the past, after an org upgrade, I have seen messages in the *Messages*
buffer regarding inconsistent, incompatible changes and what action needs
to be taken (I think this occurred when changes were made to TODO
templates). Maybe something along these lines could also be done - maybe
have a message displayed when someone tries to do a '<s' expansion and does
not have org-tempo loaded? Maybe this could be developed as something which
could be used in the future when we make other changes.
Along these same lines, maybe we need to consider adopting something
similar to the Emacs obsolete/deprecated approach. In this next release,
add a message to org-tempo advising that this functionality will change in
the next release where org-tempo will not be loaded by default. This could
include a pointer to a web page explaining the change and associated
benefits and how to make the switch now if desired. While this might delay
the transition, it might address concerns regarding impact to existing
users and new users will be aware of the alternative etc. It would be
important to have a way to silence this message of course.
--
regards,
Tim
--
Tim Cross
[-- Attachment #2: Type: text/html, Size: 3860 bytes --]
next prev parent reply other threads:[~2018-05-01 2:00 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-29 15:06 [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") Jon Snader
2018-04-30 20:37 ` Richard Lawrence
2018-04-30 20:46 ` Peter Dewey Ore
2018-04-30 21:33 ` Michael Gauland
2018-04-30 21:46 ` Jon Snader
2018-04-30 22:25 ` Tim Cross
2018-04-30 22:35 ` Cook, Malcolm
2018-04-30 22:39 ` Jon Snader
2018-04-30 22:49 ` Kaushal Modi
2018-05-01 1:29 ` Alan Tyree
2018-05-01 14:07 ` Christophe Schockaert
2018-05-01 2:00 ` Tim Cross [this message]
2018-05-01 2:27 ` Steve Downey
2018-05-01 12:35 ` Nicolas Goaziou
2018-05-01 16:28 ` Aaron Ecay
2018-05-05 18:07 ` Rasmus
2018-05-06 20:34 ` Aaron Ecay
2018-05-06 22:11 ` Tim Cross
2018-05-07 22:30 ` Rasmus
2018-05-08 0:25 ` Aaron Ecay
2018-05-08 7:36 ` Bastien
2018-05-13 20:52 ` Rasmus
2018-05-01 16:54 ` Cook, Malcolm
2018-05-05 18:01 ` Rasmus
2018-05-06 5:00 ` Carsten Dominik
2018-05-07 22:33 ` Rasmus
2018-05-08 7:37 ` Bastien
2018-05-21 14:35 ` Rasmus
2018-05-05 23:26 ` Adrian Bradd
2018-05-05 23:37 ` Josiah Schwab
2018-05-08 7:31 ` Bastien
-- strict thread matches above, loose matches on Subject: below --
2018-04-29 10:24 Bastien
2018-04-29 10:50 ` Nicolas Goaziou
2018-04-29 11:05 ` Bastien
2018-04-29 12:01 ` Nicolas Goaziou
2018-04-29 13:22 ` Bastien
2018-04-29 17:40 ` Thomas S. Dye
2018-04-29 20:56 ` Bastien
2018-04-29 22:05 ` Tim Cross
2018-04-29 22:31 ` Bastien
2018-04-29 22:27 ` Tim Cross
2018-04-29 23:03 ` Bastien
2018-04-30 10:29 ` Nicolas Goaziou
2018-04-30 14:03 ` Kevin Foley
2018-04-30 14:17 ` Kevin Foley
2018-05-05 17:20 ` Rasmus
2018-05-02 12:43 ` Bernt Hansen
2018-05-08 6:23 ` Bastien
2018-05-05 17:17 ` Rasmus
2018-05-08 6:27 ` Bastien
2018-05-01 15:49 ` Aaron Ecay
2018-05-01 19:31 ` Eric S Fraga
2018-05-02 9:10 ` Rasmus Pank Roulund
2018-05-02 17:12 ` Aaron Ecay
2018-05-05 17:29 ` Rasmus
2018-05-06 20:02 ` Aaron Ecay
2018-05-07 22:53 ` Rasmus
2018-05-08 0:57 ` Aaron Ecay
2018-05-08 6:56 ` Bastien
2018-05-21 14:24 ` Rasmus
2018-05-08 6:52 ` Bastien
2018-05-21 14:19 ` Rasmus
2018-05-08 6:34 ` Bastien
2018-04-30 8:47 ` Eric S Fraga
2018-05-08 8:37 ` Bastien
2018-04-29 13:24 ` Christian Moe
2018-04-29 13:55 ` Charles Millar
2018-04-29 19:08 ` Diego Zamboni
2018-04-29 20:30 ` Rasmus
2018-04-29 20:44 ` Bastien
2018-04-29 23:32 ` Bernt Hansen
2018-05-02 20:24 ` Bernt Hansen
2018-05-03 9:44 ` Carsten Dominik
2018-05-03 13:30 ` William Denton
2018-05-04 7:34 ` Neil Jerram
2018-05-04 7:45 ` Bastien
2018-05-05 1:37 ` Samuel Wales
2018-05-05 2:16 ` Tim Cross
2018-05-05 2:28 ` Samuel Wales
2018-05-05 2:37 ` Tim Cross
2018-05-05 12:42 ` Nicolas Goaziou
2018-05-05 17:33 ` Rasmus
2018-05-01 11:57 ` Nick Helm
2018-04-29 20:25 ` Rasmus
2018-04-29 21:53 ` Nicolas Goaziou
2018-05-02 9:03 ` Rasmus
2018-04-30 16:36 ` Steve Downey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAC=50j_AH2kcmHLA1rr7T8JMZvJiuxYqp3L+oNP2hWAeeXxNDg@mail.gmail.com' \
--to=theophilusx@gmail.com \
--cc=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=jcs@irreal.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).