From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: 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 14:35:49 +0200 [thread overview]
Message-ID: <871sevime2.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <CAJEGDKpZnS+WDBbT9d23yDp3VEStw0cP6sKUp-x7GdRdTAKAnQ@mail.gmail.com> (Steve Downey's message of "Tue, 01 May 2018 02:27:28 +0000")
Hello,
Steve Downey <sdowney@gmail.com> writes:
> Asking users to accept any breakage in the tool they use to get work done
> is a lot. Changes in UI in emacs are opt-in.
>
> Even if the change is the right thing to do.
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.
The second important point is there is a general design issue at stake.
Sorry, there is no pleasure in inflicting "torture" (as I read in this
thread) to users.
Org is too big. Its (lack of) design is wrong.
This is not from me, but from some the Emacs developers, in particular
Richard Stallman. You may want to read the thread "Differences between
Org-Mode and Hyperbole" in emacs-devel mailing list archives for the
exact quote.
Org has to be big, because it is featureful. Yet, we cannot ignore the
remark. Also, that doesn't mean we cannot do anything to improve the
situation. Actually, there are, at least, two areas in which we can make
progress:
1. externalize Org features that apply to other major modes, or drop
them if there are equivalents to them,
2. re-using (external) Emacs facilities for Org mode features that are
not central for us.
Not so long ago, we provided footnotes for other modes, even though
"footnote.el" had been there for a long time. This clearly felt into
(1), so we dropped the feature. Recently, I wrote "orgalist.el", which
ports Org plain lists into other modes. I moved it out of Org core
because of (1). It is now available in GNU ELPA.
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.
The question is not about you using "<s TAB": you now know (require
'org-tempo) could solve this. The question is not about breaking other
configurations: there always have been breakage and there will be again.
The question is about designing Org so it fits well -- better, at
least -- in the Emacs ecosystem. This means no unreasonable feature
overlap and enough modularity to be re-usable from other parts in Emacs.
Back to the current poll. It would be more efficient to think about
solutions to make the update less painful. In particular, how can we
tell users updating from ELPA about the necessary changes involved.
I remember that Magit experimented displaying a message the first time
you used a new release; you would silence it only by setting a variable.
I don't think this is the case anymore, so it may have failed, though.
We could also make the <https://orgmode.org/Changes.html> page more
prominent in the summary displayed along with the package.
Now back to the poll.
Regards,
--
Nicolas Goaziou
P.S: Bastien, would you please stop lobbying in every other
communication canal out there, that's not fair ;)
next prev parent reply other threads:[~2018-05-01 12:36 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 [this message]
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
-- 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=871sevime2.fsf@nicolasgoaziou.fr \
--to=mail@nicolasgoaziou.fr \
--cc=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=jcs@irreal.org \
--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).