From: Aaron Ecay <aaronecay@gmail.com>
To: Tim Cross <theophilusx@gmail.com>, Bastien <bzg@gnu.org>
Cc: emacs-orgmode@gnu.org, Rasmus <rasmus@gmx.us>,
Nicolas Goaziou <mail@nicolasgoaziou.fr>
Subject: Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Date: Tue, 01 May 2018 16:49:11 +0100 [thread overview]
Message-ID: <87h8nrbclk.fsf@gmail.com> (raw)
In-Reply-To: <87bme1y7ft.fsf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4482 bytes --]
2018ko apirilak 29an, Tim Cross-ek idatzi zuen:
[...]
> 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.
As someone who has worked (in a small way) on orgʼs development, I
certainly agree with the above sentiment. Org is a many-headed
hydra, and decreasing its surface area makes for a better org (since
development efforts can be concentrated) as well as a better overall
user experience (because users can rely on packages, like in this
case yasnippet, that are better at doing something that Org tried to
do).
On the other hand, as an org user breaking changes are inconvenient. I
have the impression that I can keep up with using org-mode only because
I follow the development list. Whatʼs much worse, I feel like I should
not advocate the use of org-mode to my colleagues (who are often quite
computer-literate but value long-term stability of software they use),
basically because of the potential problems Bastien listed in his
message.
This situation is also inconvenient for developers...I have in mind a
change several years ago to the #+begin_src lines for shell code. We
changed from #+begin_src shell to #+begin_src sh (or vice versa, I
canʼt remember precisely). The result was that “bug” reports trickled
in for over a year, all of which had to be answered with the advice to
change to the new specification. At the time I paid close attention to
babel-related bug reports because I was working on that code a lot.
Answering these reports (or even just reading them to see that they had
been answered by someone else) took away from my opportunity to do
(what I saw as) interesting things with orgʼs code. I can only imagine
that for ML subscribers who were not as interested in babel bugs as I
was, the distraction could only have been worse.
As a general (idealized) principle, I think user-visible changes should
be phased in over at least one org major version. I have no problem
with “intrusive” deprecation warnings, but abrupt changes in behavior
should be avoided.
Hereʼs what I imagine that could look like in the org-tempo case:
For org 9.X:
- Introduce the new functions and machinery for org-tempo as well as the
new C-c C-, keybinding
- Enable org-tempo by default
- Show a user warning whenever a “<X” style template is being expanded,
saying that this feature will go away in the next major version and to
keep it, users should add “(require 'org-tempo)” to their .emacs
- Arrange matters so that users who take this step will not receive
further warnings when expanding <X (this might require changing the
activation trigger of org-tempo from a library to some other
mechanism, see below)
For Org 10:
- No longer enable org-tempo by default
- Remove the logic for the deprecation warning
I would also question the decision to change the format of
org-structure-template-alist. That has caused some errors (in the sense
of calls to the elisp ‘error’ function) for me because a third
party-library (ox-reveal) still uses the old format. The change also
seems orthogonal to the switch from <X to C-c C-, expansion mechanism.
If itʼs really deemed to be important, I would suggest:
For org 9.X:
- Correctly handle alist keys in both new and old formats
- Show a deprecation warning if any old format keys are found in the
alist
For Org 10:
- Remove the code to handle old-style keys and the deprecation warning.
Iʼm only too aware that this approach would increase the complexity
of developing new features, both in terms of code and needing to
coordinate addition/removal of bits of compatibility code across
multiple org versions. It also requires some additional mental
effort since the deprecation path to follow is slightly different in
each case. But I think this strikes a necessary balance between the
extremes of “UX must never change” and “UX can be revised at any
point”.
Finally, irrespective of which options are chosen, I think that org-tempo
would be better implemented in terms of a minor mode. This would allow
it to be autoloaded, turned on/off for different buffer(s) in an emacs
session, and avoid duplicating the logic for activating global minor
modes. Patch attached.
--
Aaron Ecay
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Use-minor-mode-machinery-for-org-tempo.patch --]
[-- Type: text/x-patch, Size: 1767 bytes --]
From 012f8d0b71c76f5d255af6bdaeb2d9c83a47cf85 Mon Sep 17 00:00:00 2001
From: Aaron Ecay <aaronecay@gmail.com>
Date: Tue, 1 May 2018 15:32:36 +0100
Subject: [PATCH] Use minor-mode machinery for org-tempo
* lisp/org-tempo.el (org-tempo-mode):
(org-tempo-global-mode): New minor modes.
(org-tempo-mode--activate-in-buffer): New function.
---
lisp/org-tempo.el | 33 ++++++++++++++++++++++-----------
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/lisp/org-tempo.el b/lisp/org-tempo.el
index e1268b893..2feed24dc 100644
--- a/lisp/org-tempo.el
+++ b/lisp/org-tempo.el
@@ -170,17 +170,28 @@ didn't succeed."
'org-tempo-tags)
\f
-;;; Setup of Org Tempo
-;;
-;; Org Tempo is set up with each new Org buffer and potentially in the
-;; current Org buffer.
-
-(add-hook 'org-mode-hook 'org-tempo-setup)
-(add-hook 'org-tab-before-tab-emulation-hook 'org-tempo-complete-tag)
-
-;; Enable Org Tempo in all open Org buffers.
-(dolist (b (org-buffer-list 'files))
- (with-current-buffer b (org-tempo-setup)))
+;;; Org Tempo minor mode
+
+;;;###autoload
+(define-minor-mode org-tempo-mode
+ "Expand \"<X\" style templates in org-mode buffers.
+
+See `org-tempo-keywords-alist' for more information on how
+templates are defined."
+ :lighter " tempo"
+ (if org-tempo-mode
+ (progn
+ (org-tempo-setup)
+ (add-hook 'org-tab-before-tab-emulation-hook #'org-tempo-complete-tag nil 'local))
+ (remove-hook 'org-tab-before-tab-emulation-hook #'org-tempo-complete-tag 'local)))
+
+(defun org-tempo-mode--activate-in-buffer ()
+ (when (derived-mode-p 'org-mode)
+ (org-tempo-mode 1)))
+
+;;;###autoload
+(define-global-minor-mode org-tempo-global-mode org-tempo-mode
+ org-tempo-mode--activate-in-buffer)
(provide 'org-tempo)
--
2.17.0
next prev parent reply other threads:[~2018-05-01 15:49 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
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 [this message]
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=87h8nrbclk.fsf@gmail.com \
--to=aaronecay@gmail.com \
--cc=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=mail@nicolasgoaziou.fr \
--cc=rasmus@gmx.us \
--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).