I don't think anyone disagrees that this change comes at a cost. Change is very difficult and many people don't like change. The real question is how do we manage this change to minimise the pain while moving org forward to make it an even better solution.
Many seem to believe that what is being discussed here is a loss of functionality. This isn't really the case. What we are talking about here is a change, even an enhancement, of functionality. Unfortunately, that change cannot be implemented without some impact to users. The question is how do we implement this change so that users will get to benefit from the improvements while minimising impact to those who don't want to change or cannot make the change right now and at the same time, ensure users are exposed to the new functionality so that they can gain the benefit from this change. On one side, we have those who feel the impact is too muich and will cause too much pain for users and on the other side, we ahve a concern that without some impact to users, we run the risk of inertia and unawareness of the improvements/enhancements for existing users and new users being introduced to the older, less feature rich solution rather than the enhanced version. 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. The key will be how we communicate this to existing users. Tim On 1 May 2018 at 07:46, Jon Snader <j...@irreal.org> wrote: > > Richard Lawrence <richard.lawre...@berkeley.edu> writes: > > Jon Snader <j...@irreal.org> writes: >> >> I use the <s[TAB] mechanism all the time and /definitely/ want it >>> enabled. I don't want to have to deal with a menu and its more >>> complicated calling sequence >>> >> >> I feel the same! Please don't disable <s[TAB] or make it more >> complicated to use. >> > > You can make the case that it doesn't really matter because all that's > needed is a minor adjustment to your init.el to restore the old > behavior. But here's what's going to happen: A user who upgrades through > ELPA is going to discover that suddenly the familiar template code is no > longer working. He'll likely think it's an bug and wait for an upgrade > or two for it to be fixed. When it doesn't get fixed, he'll ask the > Internet what's wrong. > Here's what's not going to happen: he's not going to read the ORG-NEWS > file. In the first place, as Bastien says, most users don't but many > users won't even know where to look. Org mode is famously Emacs' killer > app and many non-technical users have been drawn to Emacs to get access > to it. Many of them probably have no idea where the ELPA files are > stored and even if they do they probably won't look in the etc > subdirectory. > > Why torture our users when it's so simple to keep the old behavior > enabled? If I hadn't seen Bastien's tweet pointing to this thread, I > would most certainly be one of the people described above. > > -- regards, Tim -- Tim Cross
