From: Aaron Ecay <aaronecay@gmail.com>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>,
Steve Downey <sdowney@gmail.com>
Cc: Bastien <bzg@gnu.org>, Tim Cross <theophilusx@gmail.com>,
Org-mode <emacs-orgmode@gnu.org>, Jon Snader <jcs@irreal.org>
Subject: Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Date: Tue, 01 May 2018 17:28:23 +0100 [thread overview]
Message-ID: <87efivbas8.fsf@gmail.com> (raw)
In-Reply-To: <871sevime2.fsf@nicolasgoaziou.fr>
Hi Nicolas,
Iʼm very sympathetic to the direction of travel of these changes, and to
the suggestion that you make in your message about using warnings to
advert users to incompatible changes. (As you can read in my message to
the parent thread).
However (with great respect for all that you have done to improve org
over the years), I think you missed the point in some of the things you
wrote.
2018ko maiatzak 1an, Nicolas Goaziou-ek idatzi zuen:
[...]
> I think some of you (basically, anyone thinking we should enable "<s
> TAB" by default ;)) are missing the point.
>
>
> The first important thing to understand is that, even if we enable
> `org-tempo' by default, next Org release /will break/ for some of us.
>
> - It will break because `org-tempo' is only 99% backward-compatible. So
> anyone having customizing templates is bound to change them.
>
> - It will break because there are 9 other incompatible changes between
> 9.1 and 9.2.
>
> So, asking to load `org-tempo' by default just to avoid breaking users
> set-up is a wrong argument. It will only "protect" those among us that
> use "<s TAB" but didn't customize /and/ are not affected by the other
> incompatible changes. IOW, updating Org from 9.1 to 9.2 will not be
> smooth for everyone. No matter what `org-tempo' becomes.
By this logic, since org 9.2 already contains 9 breaking changes, we can
change anything else in that version. Make all the key bindings start
with M-S-C-e instead of C-c, sort all the headings in a file in
alphabetical order when opening it, ...
No software update will ever be entirely disruption-free, if nothing
else because bugs will always happen. So we have to think about the
impact of (intentional) changes not in a binary Yes/No fashion, but in
terms of how many users they affect, and how bad that effect is. In
this case, the number affected is large (as measured informally by
participation in this poll) and the disruption is severe (a specifically
documented org feature now doesnʼt work, with no obviously discoverable
reason why). So that is a powerful argument against making the change
in this way, when we can achieve the same long-term effect in a less
disruptive way (with deprecation warnings).
I do think that breaking changes should be grouped into batches. And
if org has as many as ten that are pending, it is a strong argument to
call the next release version 10, with all the associated fanfare (and
breakage warnings!) Or if point releases are needed in the meantime,
hold these breaking changes on a branch that can be merged before Org
10.
[...]
> Expansion templates are a great thing, but this is only sugar for Org,
> which is totally usable without them. Besides, some facilities are
> providing it for us. This falls into (2). By design, I'm convinced we
> should not include them. I also wish that anyone involved in this thread
> can take a step back to see the whole picture.
This is a red herring. The changes do not eliminate expansion template
code from org. They merely substitute (incompatibly) one expansion
template mechanism for a new one.
FWIW, I do think the idea is worth exploring of getting rid of the (old
and new) template expansion code and using emacsʼs built-in SRecode
template facility. Like most of the CEDET stuff, it looks horridly
overengineered at a first glance. But it is also included with emacs by
default (unlike e.g. yasnippet which otherwise looks more pleasant to
program to me), and it would be (even more) responsive to the concerns
from emacs-devel that were quoted in your full message. To be specific,
this would entail (eventually) getting rid of the
org-structure-template-alist variable entirely, as well as the menu now
bound to C-c C-,; the former would be replaced by (AFAIUI) template
files that would be included with org and/or created by users for their
custom templates; the latter would use SRecodeʼs built-in template
selection instead.
--
Aaron Ecay
next prev parent reply other threads:[~2018-05-01 16:28 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-29 15:06 [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 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 [this message]
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
-- strict thread matches above, loose matches on Subject: below --
2018-04-29 10:24 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
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:34 ` 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
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=87efivbas8.fsf@gmail.com \
--to=aaronecay@gmail.com \
--cc=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=jcs@irreal.org \
--cc=mail@nicolasgoaziou.fr \
--cc=sdowney@gmail.com \
--cc=theophilusx@gmail.com \
/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).