Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

["Cook, Malcolm" <MEC@stowers.org>]

[-- Attachment #1: Type: text/plain, Size: 3840 bytes --]

If the poll is still open, I vote don’t change the default.

Unless I missed a prior good argument for changing it…

Or, unless, upon first invocation, org-mode guided you through or prompted you to changing your defaults, or at the very least, offered/insisted upon your reading ORG-NEWS.

Otherwise, I think Jon is spot on in his assessment of  “what’s going to happen” to many.


From: Emacs-orgmode <emacs-orgmode-bounces+mec=stowers.org@gnu.org> On Behalf Of Tim Cross
Sent: Monday, April 30, 2018 5:25 PM
To: Jon Snader <jcs@irreal.org>
Cc: Bastien <bzg@gnu.org>; Org-mode <emacs-orgmode@gnu.org>
Subject: Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

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 <jcs@irreal.org<mailto:jcs@irreal.org>> wrote:

Richard Lawrence <richard.lawrence@berkeley.edu<mailto:richard.lawrence@berkeley.edu>> writes:
Jon Snader <jcs@irreal.org<mailto:jcs@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


[-- Attachment #2: Type: text/html, Size: 8479 bytes --]