From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Cross Subject: Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. " References: <87wowoh1m9.fsf@aquinas.i-did-not-set--mail-host-address--so-tickle-me> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000025f9f0056b1b5781" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33688) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fDKbC-0008FK-8y for emacs-orgmode@gnu.org; Mon, 30 Apr 2018 22:00:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fDKbA-00008M-PI for emacs-orgmode@gnu.org; Mon, 30 Apr 2018 22:00:58 -0400 In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Jon Snader Cc: Bastien , Org-mode --00000000000025f9f0056b1b5781 Content-Type: text/plain; charset="UTF-8" On 1 May 2018 at 08:39, Jon Snader wrote: > > Tim Cross 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 '

On 1 May 2018 at 08:39, Jon Snader <jcs@irreal.org> wrote:<= br>

Tim Cross <th= eophilusx@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<= br> 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?<= br>

The problem is that if the old behaviour remains as = the default, then that is what new users will be introduced to and the impr= oved new functionality won't be seen. If the new behaviour is the defau= lt, there will be a small period of adjustment for existing users, but new = users will be benefiting from the changes immediately.=C2=A0 For many exist= ing users, restoring the old behaviour is just adding a require to their se= tup, so it isn't a lot to ask. (I believe there will be some power user= s 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 addit= ional steps to migrate their custom block settings). The real issue isn'= ;t about changing the default as much as doing whatever is possible to info= rm existing users of the change and how to restore previous behaviour if de= sired.=C2=A0

In the past, after an org upgrade, I have seen messages in the *Mess= ages* buffer regarding inconsistent, incompatible changes and what action n= eeds to be taken (I think this occurred when changes were made to TODO temp= lates). 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.=C2=A0
<= div class=3D"gmail_extra">
Along these = same lines, maybe we need to consider adopting something similar to the Ema= cs obsolete/deprecated=C2=A0 approach. In this next release, add a message = to org-tempo advising that this functionality will change in the next relea= se where org-tempo will not be loaded by default. This could include a poin= ter 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 m= ight 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 si= lence this message of course.=C2=A0
=C2=A0<= /div>


--
regards,

Tim

--=
Tim Cross

--00000000000025f9f0056b1b5781--