>> 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 <theophil...@gmail.com> wrote: > > On 1 May 2018 at 08:39, Jon Snader <j...@irreal.org> wrote: > >> >> Tim Cross <theophil...@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 > >
