>>   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 <theophilusx@gmail.com> wrote:

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