From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Downey 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="000000000000cf4316056b1bb6e6" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36746) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fDL15-0002Kb-Me for emacs-orgmode@gnu.org; Mon, 30 Apr 2018 22:27:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fDL14-0002qb-Cs for emacs-orgmode@gnu.org; Mon, 30 Apr 2018 22:27:43 -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: Tim Cross Cc: Bastien , Org-mode , Jon Snader --000000000000cf4316056b1bb6e6 Content-Type: text/plain; charset="UTF-8" >> For many existing users, restoring the old behaviour is just adding a require to their setup, so it isn't a lot to ask. 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. On Mon, Apr 30, 2018 at 10:01 PM Tim Cross wrote: > > 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 ' 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 > > --000000000000cf4316056b1bb6e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>>=C2=A0=C2=A0 F= or many existing users, restoring the old behaviour is just adding a requir= e to their setup, so it isn't a lot to ask.

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.=C2= =A0

Even if the change is the right thing to do.=C2=A0


On Mon, Apr 30= , 2018 at 10:01 PM Tim Cross <t= heophilusx@gmail.com> wrote:

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

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 t= hat is what new users will be introduced to and the improved new functional= ity 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 benef= iting from the changes immediately.=C2=A0 For many existing users, restorin= g 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 cust= om 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 s= ituation for them anyway as they will have to take additional steps to migr= ate their custom block settings). The real issue isn't about changing t= he default as much as doing whatever is possible to inform existing users o= f the change and how to restore previous behaviour if desired.=C2=A0
<= div class=3D"gmail_extra">
In the past,= after an org upgrade, I have seen messages in the *Messages* buffer regard= ing inconsistent, incompatible changes and what action needs to be taken (I= think this occurred when changes were made to TODO templates). Maybe somet= hing 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 use= d in the future when we make other changes.=C2=A0

Along these same lines, maybe w= e need to consider adopting something similar to the Emacs obsolete/depreca= ted=C2=A0 approach. In this next release, add a message to org-tempo advisi= ng 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 e= xplaining the change and associated benefits and how to make the switch now= if desired. While this might delay the transition, it might address concer= ns regarding impact to existing users and new users will be aware of the al= ternative etc. It would be important to have a way to silence this message = of course.=C2=A0
=C2= =A0


--
regards,

Tim

--
Tim Cross

--000000000000cf4316056b1bb6e6--