From: Tim Cross <theophilusx@gmail.com>
To: Bastien <bzg@gnu.org>
Cc: emacs-orgmode@gnu.org, Nicolas Goaziou <mail@nicolasgoaziou.fr>
Subject: Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Date: Mon, 30 Apr 2018 08:27:34 +1000 [thread overview]
Message-ID: <87bme1y7ft.fsf@gmail.com> (raw)
In-Reply-To: <874lju6tap.fsf@bzg.fr>
Bastien <bzg@gnu.org> writes:
> Hi Nicolas,
>
> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> Bastien <bzg@gnu.org> writes:
>>
>>> Again, I may be wrong in thinking disabling this will cause trouble to
>>> many users. Let's just take a moment to see what users think.
>>
>> It will case trouble during the time necessary to read ORG-NEWS
>> incompatible changes section or ask the mailing list, and then adding
>> (require 'org-tempo) to their configuration file.
>
> I wish I'd be as optimistic as you are and assume every user reads
> ORG-NEWS! I seriously doubt a majority of users do. Those installing
> Org from ELPA cannot possibly know where to find ORG-NEWS, Org gives
> no indication where it lives: IOW, it's not even because users are
> lazy or what.
>
>> It seems nonsensical to let Org handle expansion templates. Dedicated
>> packages do it way better than what we provide, and the task is really
>> out of our scope.
>
> I can't remember anybody complaining Org's expansion mechanism.
>
>> Worse, we would provide two different ways to expand blocks /by
>> default/.
>
> I see it differently. You and Rasmus (and those participating to the
> discussion) cleanly separated two functionalities: one is to *insert*
> templates the other one is to *expand* them.
>
> M-x org-insert-structure-template RET is good for discovery as it lets
> users see what templates are availables and <[KEY][TAB] is good for
> fast inline expansion.
>
> Both complete each other IMO, and both deserve to be in Org's core.
>
> But again, I might be wrong, I just don't want this to be a discussion
> between us two :)
The problem here is two competing objectives. I agree with Nicholas'
position that overall, org should not reproduce/re-invent/duplicate
functionality already provided by Emacs or well established Emacs
packages like ysnippets etc. On the other hand, Bastien's concern
regarding impact on users and basic change management concerns are very
valid.
There is no solution which will make everyone happy. However, as a long
term org user who hopes to continue using org for many more years, I
tend to come down on the side of whatever will make org easier to
maintain in the long term.
I think org itself should provide a very stable core and avoid
incorporating too many add on enhancements. It should be as stable as
possible to encourage others to develop and maintain such enhancements
and extensions. So while some of the changes Nicholas has proposed may
have some short term inconvenience, I agree with his approach and I
agree that if we enable org-tempo by default, we are unlikely to see
people switch and org-tempo will end up being another module needing to
be maintained as part of core.
While the switch will be a little inconvenient for me while I learn to
re-train my fingers, I think what I'm really doing is undoing a bad
habit learned because of the original '<s' expansion. I recall being a
little frustrated when I first started using org that I had to learn
another expansion key binding just for org mode. Consequently, I'm not
going to enable org-tempo, instead going for re-training of my fingers
to use the new C-c ' binding.
I agree with Thomas that adding an org-tempo require is an easy addition
for those who do not have the time/inclination to make the change
immediately.
So in basic terms, I agree with Nicholas' position. Having said that, I
do feel he is being optimistic/pragmatic and Bastien's concerns are very
valid. I don't think people will read the NEWS file and I do expect we
will see numerous posts about org templates not working. However, this
should only be a short term bit of pain and I don't see it can be
avoided. The tempo solution will go a long way to reduce that pain for
those who don't have time to deal with the change right now. Most
reasonable people will understand why this change is occurring provided
we can make the rationale clear and easy to find, so information on the
org web site, to relevant mail lists and any other forum would be a good
idea.
Tim
--
Tim Cross
next prev parent reply other threads:[~2018-04-29 22:27 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-29 10:24 [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") Bastien
2018-04-29 10:50 ` Nicolas Goaziou
2018-04-29 11:05 ` Bastien
2018-04-29 12:01 ` Nicolas Goaziou
2018-04-29 13:22 ` Bastien
2018-04-29 17:40 ` Thomas S. Dye
2018-04-29 20:56 ` Bastien
2018-04-29 22:05 ` Tim Cross
2018-04-29 22:31 ` Bastien
2018-04-29 22:27 ` Tim Cross [this message]
2018-04-29 23:03 ` Bastien
2018-04-30 10:29 ` Nicolas Goaziou
2018-04-30 14:03 ` Kevin Foley
2018-04-30 14:17 ` Kevin Foley
2018-05-05 17:20 ` Rasmus
2018-05-02 12:43 ` Bernt Hansen
2018-05-08 6:23 ` Bastien
2018-05-05 17:17 ` Rasmus
2018-05-08 6:27 ` Bastien
2018-05-01 15:49 ` Aaron Ecay
2018-05-01 19:31 ` Eric S Fraga
2018-05-02 9:10 ` Rasmus Pank Roulund
2018-05-02 17:12 ` Aaron Ecay
2018-05-05 17:29 ` Rasmus
2018-05-06 20:02 ` Aaron Ecay
2018-05-07 22:53 ` Rasmus
2018-05-08 0:57 ` Aaron Ecay
2018-05-08 6:56 ` Bastien
2018-05-21 14:24 ` Rasmus
2018-05-08 6:52 ` Bastien
2018-05-21 14:19 ` Rasmus
2018-05-08 6:49 ` Smooth transition for modules (was: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")) Bastien
2018-05-08 9:26 ` Aaron Ecay
2018-05-08 9:46 ` Smooth transition for modules Bastien
2018-05-08 13:28 ` Aaron Ecay
2018-05-08 6:34 ` [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") Bastien
2018-04-30 8:47 ` Eric S Fraga
2018-05-08 8:37 ` Bastien
2018-04-29 13:24 ` Christian Moe
2018-04-29 13:55 ` Charles Millar
2018-04-29 19:08 ` Diego Zamboni
2018-04-29 20:30 ` Rasmus
2018-04-29 20:44 ` Bastien
2018-04-29 23:32 ` Bernt Hansen
2018-05-02 20:24 ` Bernt Hansen
2018-05-03 9:44 ` Carsten Dominik
2018-05-03 13:30 ` William Denton
2018-05-04 7:34 ` Neil Jerram
2018-05-04 7:45 ` Bastien
2018-05-05 1:37 ` Samuel Wales
2018-05-05 2:16 ` Tim Cross
2018-05-05 2:28 ` Samuel Wales
2018-05-05 2:37 ` Tim Cross
2018-05-05 12:42 ` Nicolas Goaziou
2018-05-05 17:33 ` Rasmus
2018-05-01 11:57 ` Nick Helm
2018-04-29 20:25 ` Rasmus
2018-04-29 21:53 ` Nicolas Goaziou
2018-05-02 9:03 ` Rasmus
2018-04-30 16:36 ` Steve Downey
-- strict thread matches above, loose matches on Subject: below --
2018-04-29 15:06 Jon Snader
2018-04-30 20:37 ` Richard Lawrence
2018-04-30 20:46 ` Peter Dewey Ore
2018-04-30 21:33 ` Michael Gauland
2018-04-30 21:46 ` Jon Snader
2018-04-30 22:25 ` Tim Cross
2018-04-30 22:35 ` Cook, Malcolm
2018-04-30 22:39 ` Jon Snader
2018-04-30 22:49 ` Kaushal Modi
2018-05-01 1:29 ` Alan Tyree
2018-05-01 14:07 ` Christophe Schockaert
2018-05-01 2:00 ` Tim Cross
2018-05-01 2:27 ` Steve Downey
2018-05-01 12:35 ` Nicolas Goaziou
2018-05-01 16:28 ` Aaron Ecay
2018-05-05 18:07 ` Rasmus
2018-05-06 20:34 ` Aaron Ecay
2018-05-06 22:11 ` Tim Cross
2018-05-07 22:30 ` Rasmus
2018-05-08 0:25 ` Aaron Ecay
2018-05-08 7:36 ` Bastien
2018-05-13 20:52 ` Rasmus
2018-05-01 16:54 ` Cook, Malcolm
2018-05-05 18:01 ` Rasmus
2018-05-06 5:00 ` Carsten Dominik
2018-05-07 22:33 ` Rasmus
2018-05-08 7:37 ` Bastien
2018-05-21 14:35 ` Rasmus
2018-05-05 23:26 ` Adrian Bradd
2018-05-05 23:37 ` Josiah Schwab
2018-05-08 7:31 ` Bastien
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bme1y7ft.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=mail@nicolasgoaziou.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).