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
>From 012f8d0b71c76f5d255af6bdaeb2d9c83a47cf85 Mon Sep 17 00:00:00 2001 From: Aaron Ecay <aarone...@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) -;;; 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