From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Cross 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="000000000000478cdc056b185353" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fDHEK-00042L-Mp for emacs-orgmode@gnu.org; Mon, 30 Apr 2018 18:25:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fDHEJ-0003Dy-Ae for emacs-orgmode@gnu.org; Mon, 30 Apr 2018 18:25:08 -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: Jon Snader Cc: Bastien , Org-mode --000000000000478cdc056b185353 Content-Type: text/plain; charset="UTF-8" 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 wrote: > > Richard Lawrence writes: > > Jon Snader writes: >> >> I use the >> 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 > 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 --000000000000478cdc056b185353 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 whil= e moving org forward to make it an even better solution.=C2=A0

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 he= re is a change, even an enhancement, of functionality. Unfortunately, that = change cannot be implemented without some impact to users.=C2=A0
=
The question is how do we implement this change so that user= s will get to benefit from the improvements while minimising impact to thos= e who don't want to change or cannot make the change right now and at t= he same time, ensure users are exposed to the new functionality so that the= y can gain the benefit from this change.=C2=A0 On one side, we have those w= ho 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 fo= r existing users and new users being introduced to the older, less feature = rich solution rather than the enhanced=C2=A0 version.=C2=A0

<= /div>
Personally, I feel the new version should be the default and we s= hould provide an easy way to re-enable the old version for those who wish t= o continue with what they are use to. The key will be how we communicate th= is to existing users.=C2=A0

Tim

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

Richard Lawrence <richard.lawrence@berkeley.edu> writes:

Jon Snader <jcs@irre= al.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!=C2=A0 Please don't disable <s[TAB] or make it more<= br> complicated to use.

 You can make the case that it doesn't really matter because all that= 9;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 th= rough
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 upgr= ade
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 O= RG-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' ki= ller
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

--
T= im Cross

--000000000000478cdc056b185353--