From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. " References: <87wowoh1m9.fsf@aquinas.i-did-not-set--mail-host-address--so-tickle-me> <871sevime2.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49155) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fDY8n-0006Y0-HY for emacs-orgmode@gnu.org; Tue, 01 May 2018 12:28:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fDY8m-0000rV-BT for emacs-orgmode@gnu.org; Tue, 01 May 2018 12:28:33 -0400 In-Reply-To: <871sevime2.fsf@nicolasgoaziou.fr> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Nicolas Goaziou , Steve Downey Cc: Bastien , Tim Cross , Org-mode , Jon Snader Hi Nicolas, I=CA=BCm 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 " TAB" by default ;)) are missing the point. >=20 >=20 > 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. >=20 > - It will break because `org-tempo' is only 99% backward-compatible. So > anyone having customizing templates is bound to change them. >=20 > - It will break because there are 9 other incompatible changes between > 9.1 and 9.2. >=20 > 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 " 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=CA=BCt 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=CA=BCs 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=CA=BCs built-in template selection instead. --=20 Aaron Ecay