* [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") @ 2018-04-29 15:06 Jon Snader 2018-04-30 20:37 ` Richard Lawrence 0 siblings, 1 reply; 87+ messages in thread From: Jon Snader @ 2018-04-29 15:06 UTC (permalink / raw) To: emacs-orgmode, bzg I use the <s[TAB] mechanism all the time and /definitely/ want it enabled. I don't want to have to deal with a menu and its more complicated calling sequence; this is Emacs, after all. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 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:46 ` Jon Snader 0 siblings, 2 replies; 87+ messages in thread From: Richard Lawrence @ 2018-04-30 20:37 UTC (permalink / raw) To: Jon Snader, emacs-orgmode, bzg Jon Snader <jcs@irreal.org> writes: > I use the <s[TAB] mechanism all the time and /definitely/ want > it enabled. I don't want to have to deal with a menu and its > more complicated calling sequence I feel the same! Please don't disable <s[TAB] or make it more complicated to use. -- Best, Richard ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 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 1 sibling, 1 reply; 87+ messages in thread From: Peter Dewey Ore @ 2018-04-30 20:46 UTC (permalink / raw) To: Richard Lawrence; +Cc: bzg, emacs-orgmode, Jon Snader [-- Attachment #1: Type: text/plain, Size: 517 bytes --] I second (third?) Richard and Jon. I use <s[TAB] very frequently and I appreciate the simplicity. On Mon, Apr 30, 2018 at 1:37 PM, Richard Lawrence < richard.lawrence@berkeley.edu> wrote: > Jon Snader <jcs@irreal.org> writes: > > I use the <s[TAB] mechanism all the time and /definitely/ want it enabled. >> I don't want to have to deal with a menu and its more complicated calling >> sequence >> > > I feel the same! Please don't disable <s[TAB] or make it more complicated > to use. > > -- > Best, > Richard > > [-- Attachment #2: Type: text/html, Size: 1121 bytes --] ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-30 20:46 ` Peter Dewey Ore @ 2018-04-30 21:33 ` Michael Gauland 0 siblings, 0 replies; 87+ messages in thread From: Michael Gauland @ 2018-04-30 21:33 UTC (permalink / raw) To: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 694 bytes --] Same here! On 01/05/18 08:46, Peter Dewey Ore wrote: > I second (third?) Richard and Jon. I use <s[TAB] very frequently and I > appreciate the simplicity. > > On Mon, Apr 30, 2018 at 1:37 PM, Richard Lawrence > <richard.lawrence@berkeley.edu <mailto:richard.lawrence@berkeley.edu>> > wrote: > > Jon Snader <jcs@irreal.org <mailto:jcs@irreal.org>> writes: > > I use the <s[TAB] mechanism all the time and /definitely/ want > it enabled. I don't want to have to deal with a menu and its > more complicated calling sequence > > > I feel the same! Please don't disable <s[TAB] or make it more > complicated to use. > > -- > Best, > Richard > > [-- Attachment #2: Type: text/html, Size: 2034 bytes --] ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-30 20:37 ` Richard Lawrence 2018-04-30 20:46 ` Peter Dewey Ore @ 2018-04-30 21:46 ` Jon Snader 2018-04-30 22:25 ` Tim Cross 1 sibling, 1 reply; 87+ messages in thread From: Jon Snader @ 2018-04-30 21:46 UTC (permalink / raw) To: Richard Lawrence; +Cc: bzg, emacs-orgmode Richard Lawrence <richard.lawrence@berkeley.edu> writes: > Jon Snader <jcs@irreal.org> writes: > >> I use the <s[TAB] mechanism all the time and /definitely/ want >> it >> enabled. I don't want to have to deal with a menu and its more >> complicated calling sequence > > I feel the same! Please don't disable <s[TAB] or make it more > complicated to use. You can make the case that it doesn't really matter because all that's needed is a minor adjustment to your init.el to restore the old behavior. But here's what's going to happen: A user who upgrades through ELPA is going to discover that suddenly the familiar template code is no longer working. He'll likely think it's an bug and wait for an upgrade or two for it to be fixed. When it doesn't get fixed, he'll ask the Internet what's wrong. Here's what's not going to happen: he's not going to read the ORG-NEWS file. In the first place, as Bastien says, most users don't but many users won't even know where to look. Org mode is famously Emacs' killer app and many non-technical users have been drawn to Emacs to get access to it. Many of them probably have no idea where the ELPA files are stored and even if they do they probably won't look in the etc subdirectory. Why torture our users when it's so simple to keep the old behavior enabled? If I hadn't seen Bastien's tweet pointing to this thread, I would most certainly be one of the people described above. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 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 0 siblings, 2 replies; 87+ messages in thread From: Tim Cross @ 2018-04-30 22:25 UTC (permalink / raw) To: Jon Snader; +Cc: Bastien, Org-mode [-- Attachment #1: Type: text/plain, Size: 3050 bytes --] I don't think anyone disagrees that this change comes at a cost. Change is very difficult and many people don't like change. The real question is how do we manage this change to minimise the pain while moving org forward to make it an even better solution. Many seem to believe that what is being discussed here is a loss of functionality. This isn't really the case. What we are talking about here is a change, even an enhancement, of functionality. Unfortunately, that change cannot be implemented without some impact to users. The question is how do we implement this change so that users will get to benefit from the improvements while minimising impact to those who don't want to change or cannot make the change right now and at the same time, ensure users are exposed to the new functionality so that they can gain the benefit from this change. On one side, we have those who feel the impact is too muich and will cause too much pain for users and on the other side, we ahve a concern that without some impact to users, we run the risk of inertia and unawareness of the improvements/enhancements for existing users and new users being introduced to the older, less feature rich solution rather than the enhanced version. Personally, I feel the new version should be the default and we should provide an easy way to re-enable the old version for those who wish to continue with what they are use to. The key will be how we communicate this to existing users. Tim On 1 May 2018 at 07:46, Jon Snader <jcs@irreal.org> wrote: > > Richard Lawrence <richard.lawrence@berkeley.edu> writes: > > Jon Snader <jcs@irreal.org> writes: >> >> I use the <s[TAB] mechanism all the time and /definitely/ want it >>> enabled. I don't want to have to deal with a menu and its more >>> complicated calling sequence >>> >> >> I feel the same! Please don't disable <s[TAB] or make it more >> complicated to use. >> > > You can make the case that it doesn't really matter because all that's > needed is a minor adjustment to your init.el to restore the old > behavior. But here's what's going to happen: A user who upgrades through > ELPA is going to discover that suddenly the familiar template code is no > longer working. He'll likely think it's an bug and wait for an upgrade > or two for it to be fixed. When it doesn't get fixed, he'll ask the > Internet what's wrong. > Here's what's not going to happen: he's not going to read the ORG-NEWS > file. In the first place, as Bastien says, most users don't but many > users won't even know where to look. Org mode is famously Emacs' killer > app and many non-technical users have been drawn to Emacs to get access > to it. Many of them probably have no idea where the ELPA files are > stored and even if they do they probably won't look in the etc > subdirectory. > > Why torture our users when it's so simple to keep the old behavior > enabled? If I hadn't seen Bastien's tweet pointing to this thread, I > would most certainly be one of the people described above. > > -- regards, Tim -- Tim Cross [-- Attachment #2: Type: text/html, Size: 4230 bytes --] ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-30 22:25 ` Tim Cross @ 2018-04-30 22:35 ` Cook, Malcolm 2018-04-30 22:39 ` Jon Snader 1 sibling, 0 replies; 87+ messages in thread From: Cook, Malcolm @ 2018-04-30 22:35 UTC (permalink / raw) To: Tim Cross, Jon Snader; +Cc: Bastien, Org-mode [-- Attachment #1: Type: text/plain, Size: 3840 bytes --] If the poll is still open, I vote don’t change the default. Unless I missed a prior good argument for changing it… Or, unless, upon first invocation, org-mode guided you through or prompted you to changing your defaults, or at the very least, offered/insisted upon your reading ORG-NEWS. Otherwise, I think Jon is spot on in his assessment of “what’s going to happen” to many. From: Emacs-orgmode <emacs-orgmode-bounces+mec=stowers.org@gnu.org> On Behalf Of Tim Cross Sent: Monday, April 30, 2018 5:25 PM To: Jon Snader <jcs@irreal.org> Cc: Bastien <bzg@gnu.org>; Org-mode <emacs-orgmode@gnu.org> Subject: Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") I don't think anyone disagrees that this change comes at a cost. Change is very difficult and many people don't like change. The real question is how do we manage this change to minimise the pain while moving org forward to make it an even better solution. Many seem to believe that what is being discussed here is a loss of functionality. This isn't really the case. What we are talking about here is a change, even an enhancement, of functionality. Unfortunately, that change cannot be implemented without some impact to users. The question is how do we implement this change so that users will get to benefit from the improvements while minimising impact to those who don't want to change or cannot make the change right now and at the same time, ensure users are exposed to the new functionality so that they can gain the benefit from this change. On one side, we have those who feel the impact is too muich and will cause too much pain for users and on the other side, we ahve a concern that without some impact to users, we run the risk of inertia and unawareness of the improvements/enhancements for existing users and new users being introduced to the older, less feature rich solution rather than the enhanced version. Personally, I feel the new version should be the default and we should provide an easy way to re-enable the old version for those who wish to continue with what they are use to. The key will be how we communicate this to existing users. Tim On 1 May 2018 at 07:46, Jon Snader <jcs@irreal.org<mailto:jcs@irreal.org>> wrote: Richard Lawrence <richard.lawrence@berkeley.edu<mailto:richard.lawrence@berkeley.edu>> writes: Jon Snader <jcs@irreal.org<mailto:jcs@irreal.org>> writes: I use the <s[TAB] mechanism all the time and /definitely/ want it enabled. I don't want to have to deal with a menu and its more complicated calling sequence I feel the same! Please don't disable <s[TAB] or make it more complicated to use. You can make the case that it doesn't really matter because all that's needed is a minor adjustment to your init.el to restore the old behavior. But here's what's going to happen: A user who upgrades through ELPA is going to discover that suddenly the familiar template code is no longer working. He'll likely think it's an bug and wait for an upgrade or two for it to be fixed. When it doesn't get fixed, he'll ask the Internet what's wrong. Here's what's not going to happen: he's not going to read the ORG-NEWS file. In the first place, as Bastien says, most users don't but many users won't even know where to look. Org mode is famously Emacs' killer app and many non-technical users have been drawn to Emacs to get access to it. Many of them probably have no idea where the ELPA files are stored and even if they do they probably won't look in the etc subdirectory. Why torture our users when it's so simple to keep the old behavior enabled? If I hadn't seen Bastien's tweet pointing to this thread, I would most certainly be one of the people described above. -- regards, Tim -- Tim Cross [-- Attachment #2: Type: text/html, Size: 8479 bytes --] ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 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 2:00 ` Tim Cross 1 sibling, 2 replies; 87+ messages in thread From: Jon Snader @ 2018-04-30 22:39 UTC (permalink / raw) To: Tim Cross; +Cc: Bastien, Org-mode Tim Cross <theophilusx@gmail.com> writes: >[Snip] > > Personally, I feel the new version should be the default and we > should > provide an easy way to re-enable the old version for those who > wish to > continue with what they are use to. We already have this. The problem, as you say, is > how we communicate this to existing users. But here's what I don't understand: what, exactly, is so bad about leaving the old behavior enabled by default. The new behavior is still available and naive users don't get surprised. What's not to like? ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-30 22:39 ` Jon Snader @ 2018-04-30 22:49 ` Kaushal Modi 2018-05-01 1:29 ` Alan Tyree 2018-05-01 2:00 ` Tim Cross 1 sibling, 1 reply; 87+ messages in thread From: Kaushal Modi @ 2018-04-30 22:49 UTC (permalink / raw) To: Jon Snader; +Cc: Bastien, Tim Cross, Org-mode [-- Attachment #1: Type: text/plain, Size: 606 bytes --] Hi all, I normally am all for adapting to changes, staying on bleeding edges of emacs, Org, etc. But FWIW, for this particular change to the "<s" Easy Templates, I'm in the camp of "It was working awesome, it was beautiful! Why change it?". For record, I understand the "why", but it just doesn't seem worth it in this case. But the good thing is that this is open source, and you can backport the stuff you like from the original Easy Template code into your personal Emacs config (and then later adapt to the new way of doing the similar when you have time and motivation). Kaushal -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 839 bytes --] ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-30 22:49 ` Kaushal Modi @ 2018-05-01 1:29 ` Alan Tyree 2018-05-01 14:07 ` Christophe Schockaert 0 siblings, 1 reply; 87+ messages in thread From: Alan Tyree @ 2018-05-01 1:29 UTC (permalink / raw) To: Kaushal Modi; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 1386 bytes --] I'm a non-technical user, and I've never used ysnippets, but I'm willing to give it a go with some proper instruction. I do see the argument of both sides. Here is a question: I see specialised snippet packages in the ELPA respositories. Is it possible to provide snippets that reproduce the existing "Easy Templates", maybe even keep the same key bindings so that the change is transparent to the users that are likely to have the troubles referred to by Bastien? It is a genuine question since I have no idea of the problems involved. I'll keep using org no matter what you decide! Cheers, Alan On 1 May 2018 at 08:49, Kaushal Modi <kaushal.modi@gmail.com> wrote: > Hi all, > > I normally am all for adapting to changes, staying on bleeding edges of > emacs, Org, etc. > > But FWIW, for this particular change to the "<s" Easy Templates, I'm in > the camp of "It was working awesome, it was beautiful! Why change it?". For > record, I understand the "why", but it just doesn't seem worth it in this > case. > > But the good thing is that this is open source, and you can backport the > stuff you like from the original Easy Template code into your personal > Emacs config (and then later adapt to the new way of doing the similar when > you have time and motivation). > > Kaushal > -- > > Kaushal Modi > -- Alan L Tyree http://www2.austlii.edu.au/~alan [-- Attachment #2: Type: text/html, Size: 2506 bytes --] ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-01 1:29 ` Alan Tyree @ 2018-05-01 14:07 ` Christophe Schockaert 0 siblings, 0 replies; 87+ messages in thread From: Christophe Schockaert @ 2018-05-01 14:07 UTC (permalink / raw) To: emacs-orgmode Alan Tyree writes: > [...] > > Here is a question: I see specialised snippet packages in the ELPA > respositories. Is it possible to provide snippets that reproduce the > existing "Easy Templates", maybe even keep the same key bindings so that > the change is transparent to the users that are likely to have the troubles > referred to by Bastien? By chances, I spent some spare time reading this thread, and the previous one. Well, Org is my daily-life tool, I am a bit outdated, although. And I would like to change that, by getting closer to Org upgrades. I fully understand and can value the need for improving software design and focusing towards consistent functions, as time passes by and software grows and evolves. Also, when there are breaking changes, the thing is that it's often never the right time. I mean, however small it is, when you are in your daily process, it does not necesserily fit your agenda. So, I try to carefully select times for my upgrades, and I am glad to be aware of this one. So, I am ready to adapt myself. I will probably learn the new keys if they are easy to work with. However, the existing shortcut seems so natural to remember for whom is used to markup tags. And it's easy to type. If yasnippets is the way to go, I'll use them. I never took the time yet to address them. Thus, I like Alan idea to prepare a set of shortcuts that would match the existing ones. That way, we would have a common set acting as a base for org users. I will have a look at org-tempo, too, as it exists and easy to handle. As for letting know the users, I think it's a very important part. Could the ORG-NEWS clearly identify the expected breaking changes and refer to a receipe for handling them ? Also, would it be possible to add a link to the ORG-NEWS file in the ELPA package description ? I don't think there is. I know it exists, and that's where I went for my first breaking changes, but if we can make it obvious for those would might not be long time users, that would be great :-) I any case, thank you for the awesome work you're all doing here. Cheers, Christophe > It is a genuine question since I have no idea of the problems involved. > > I'll keep using org no matter what you decide! > > Cheers, > Alan > > > On 1 May 2018 at 08:49, Kaushal Modi <kaushal.modi@gmail.com> wrote: > >> Hi all, >> >> I normally am all for adapting to changes, staying on bleeding edges of >> emacs, Org, etc. >> >> But FWIW, for this particular change to the "<s" Easy Templates, I'm in >> the camp of "It was working awesome, it was beautiful! Why change it?". For >> record, I understand the "why", but it just doesn't seem worth it in this >> case. >> >> But the good thing is that this is open source, and you can backport the >> stuff you like from the original Easy Template code into your personal >> Emacs config (and then later adapt to the new way of doing the similar when >> you have time and motivation). >> >> Kaushal >> -- >> >> Kaushal Modi >> -- ---------------> https://www.citadels.earth Once it's perfectly aimed, the flying arrow goes straight to its target. Thus, don't worry when things go right. There will be enough time to worry about if they go wrong. Then, it's time to fire a new arrow towards another direction. Don't sink. Adapt yourself ! The archer has to shoot accurately and quickly. [Words of Erenthar, the bowman ranger] <---------------<<<< ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-30 22:39 ` Jon Snader 2018-04-30 22:49 ` Kaushal Modi @ 2018-05-01 2:00 ` Tim Cross 2018-05-01 2:27 ` Steve Downey 1 sibling, 1 reply; 87+ messages in thread From: Tim Cross @ 2018-05-01 2:00 UTC (permalink / raw) To: Jon Snader; +Cc: Bastien, Org-mode [-- Attachment #1: Type: text/plain, Size: 2737 bytes --] On 1 May 2018 at 08:39, Jon Snader <jcs@irreal.org> wrote: > > Tim Cross <theophilusx@gmail.com> writes: > > [Snip] >> >> Personally, I feel the new version should be the default and we should >> provide an easy way to re-enable the old version for those who wish to >> continue with what they are use to. >> > > We already have this. The problem, as you say, is > > how we communicate this to existing users. >> > > But here's what I don't understand: what, exactly, is so bad about > leaving the old behavior enabled by default. The new behavior is still > available and naive users don't get surprised. What's not to like? > The problem is that if the old behaviour remains as the default, then that is what new users will be introduced to and the improved new functionality won't be seen. If the new behaviour is the default, there will be a small period of adjustment for existing users, but new users will be benefiting from the changes immediately. For many existing users, restoring the old behaviour is just adding a require to their setup, so it isn't a lot to ask. (I believe there will be some power users with lots of custom blocks who may be more impacted, but as I understand it, whether the new or old functionality is enabled by default doesn't really change the situation for them anyway as they will have to take additional steps to migrate their custom block settings). The real issue isn't about changing the default as much as doing whatever is possible to inform existing users of the change and how to restore previous behaviour if desired. In the past, after an org upgrade, I have seen messages in the *Messages* buffer regarding inconsistent, incompatible changes and what action needs to be taken (I think this occurred when changes were made to TODO templates). Maybe something along these lines could also be done - maybe have a message displayed when someone tries to do a '<s' expansion and does not have org-tempo loaded? Maybe this could be developed as something which could be used in the future when we make other changes. Along these same lines, maybe we need to consider adopting something similar to the Emacs obsolete/deprecated approach. In this next release, add a message to org-tempo advising that this functionality will change in the next release where org-tempo will not be loaded by default. This could include a pointer to a web page explaining the change and associated benefits and how to make the switch now if desired. While this might delay the transition, it might address concerns regarding impact to existing users and new users will be aware of the alternative etc. It would be important to have a way to silence this message of course. -- regards, Tim -- Tim Cross [-- Attachment #2: Type: text/html, Size: 3860 bytes --] ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-01 2:00 ` Tim Cross @ 2018-05-01 2:27 ` Steve Downey 2018-05-01 12:35 ` Nicolas Goaziou 0 siblings, 1 reply; 87+ messages in thread From: Steve Downey @ 2018-05-01 2:27 UTC (permalink / raw) To: Tim Cross; +Cc: Bastien, Org-mode, Jon Snader [-- Attachment #1: Type: text/plain, Size: 3208 bytes --] >> For many existing users, restoring the old behaviour is just adding a require to their setup, so it isn't a lot to ask. 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. On Mon, Apr 30, 2018 at 10:01 PM Tim Cross <theophilusx@gmail.com> wrote: > > On 1 May 2018 at 08:39, Jon Snader <jcs@irreal.org> wrote: > >> >> Tim Cross <theophilusx@gmail.com> writes: >> >> [Snip] >>> >>> Personally, I feel the new version should be the default and we should >>> provide an easy way to re-enable the old version for those who wish to >>> continue with what they are use to. >>> >> >> We already have this. The problem, as you say, is >> >> how we communicate this to existing users. >>> >> >> But here's what I don't understand: what, exactly, is so bad about >> leaving the old behavior enabled by default. The new behavior is still >> available and naive users don't get surprised. What's not to like? >> > > The problem is that if the old behaviour remains as the default, then that > is what new users will be introduced to and the improved new functionality > won't be seen. If the new behaviour is the default, there will be a small > period of adjustment for existing users, but new users will be benefiting > from the changes immediately. For many existing users, restoring the old > behaviour is just adding a require to their setup, so it isn't a lot to > ask. (I believe there will be some power users with lots of custom blocks > who may be more impacted, but as I understand it, whether the new or old > functionality is enabled by default doesn't really change the situation for > them anyway as they will have to take additional steps to migrate their > custom block settings). The real issue isn't about changing the default as > much as doing whatever is possible to inform existing users of the change > and how to restore previous behaviour if desired. > > In the past, after an org upgrade, I have seen messages in the *Messages* > buffer regarding inconsistent, incompatible changes and what action needs > to be taken (I think this occurred when changes were made to TODO > templates). Maybe something along these lines could also be done - maybe > have a message displayed when someone tries to do a '<s' expansion and does > not have org-tempo loaded? Maybe this could be developed as something which > could be used in the future when we make other changes. > > Along these same lines, maybe we need to consider adopting something > similar to the Emacs obsolete/deprecated approach. In this next release, > add a message to org-tempo advising that this functionality will change in > the next release where org-tempo will not be loaded by default. This could > include a pointer to a web page explaining the change and associated > benefits and how to make the switch now if desired. While this might delay > the transition, it might address concerns regarding impact to existing > users and new users will be aware of the alternative etc. It would be > important to have a way to silence this message of course. > > > > -- > regards, > > Tim > > -- > Tim Cross > > [-- Attachment #2: Type: text/html, Size: 4670 bytes --] ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-01 2:27 ` Steve Downey @ 2018-05-01 12:35 ` Nicolas Goaziou 2018-05-01 16:28 ` Aaron Ecay ` (4 more replies) 0 siblings, 5 replies; 87+ messages in thread From: Nicolas Goaziou @ 2018-05-01 12:35 UTC (permalink / raw) To: Steve Downey; +Cc: Bastien, Tim Cross, Org-mode, Jon Snader 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 ;) ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-01 12:35 ` Nicolas Goaziou @ 2018-05-01 16:28 ` Aaron Ecay 2018-05-05 18:07 ` Rasmus 2018-05-01 16:54 ` Cook, Malcolm ` (3 subsequent siblings) 4 siblings, 1 reply; 87+ messages in thread From: Aaron Ecay @ 2018-05-01 16:28 UTC (permalink / raw) To: Nicolas Goaziou, Steve Downey; +Cc: Bastien, Tim Cross, Org-mode, Jon Snader 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-01 16:28 ` Aaron Ecay @ 2018-05-05 18:07 ` Rasmus 2018-05-06 20:34 ` Aaron Ecay 0 siblings, 1 reply; 87+ messages in thread From: Rasmus @ 2018-05-05 18:07 UTC (permalink / raw) To: emacs-orgmode Aaron Ecay <aaronecay@gmail.com> writes: >> 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. Cool, I at least did not know that one. Can you a reproducible way to try it out? Without having to make my own templates etc. Rasmus -- Not everything that goes around comes back around, you know ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 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 0 siblings, 2 replies; 87+ messages in thread From: Aaron Ecay @ 2018-05-06 20:34 UTC (permalink / raw) To: Rasmus, emacs-orgmode Hi Rasmus, 2018ko maiatzak 5an, Rasmus-ek idatzi zuen: > Cool, I at least did not know that one. > Can you a reproducible way to try it out? > Without having to make my own templates etc. I havenʼt done anything with it myself. You can open up a blank .el file and test out some of emacsʼs built-in templates. M-x srecode-minor-mode, and then “C-c / /” will prompt you for the name of a template to insert. Entering file:major-mode at the resulting prompt might be the most interesting one. Certain keys are bound to common templates, examples are “C-c / f” for inserting a function and “C-c / v” for a variable The template file corresponding to this is located at $YOUR_EMACS_INSTALL_DIR/etc/srecode/el.srt. Just as an aside, I have now also learned that emacs also includes skeleton.el, which is yet a third template expansion library. Sigh. -- Aaron Ecay ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-06 20:34 ` Aaron Ecay @ 2018-05-06 22:11 ` Tim Cross 2018-05-07 22:30 ` Rasmus 1 sibling, 0 replies; 87+ messages in thread From: Tim Cross @ 2018-05-06 22:11 UTC (permalink / raw) To: Aaron Ecay; +Cc: emacs-orgmode, Rasmus > Just as an aside, I have now also learned that emacs also includes > skeleton.el, which is yet a third template expansion library. Sigh. also why we have yasnippets (yet another snippet for emacs). If lisp languages have a flaw, this is probably it - often, people find it easier to re-write functionality in a new library rather than spending time learning the API and underlying philosophy/mindset of a 3rp party. Understandable as we all prefer coding to reading manuals and APIs! I guess this is also one of the motivations to not implement yet another template system if it can be avoided. I have used both tempo and skeleton mode in the past. From memory, skeleton's strength was with fairly static templates e.g. copyright notice (though there is a mode for that as well!). Tempo was the one I used most often, but have to say, writing tempo templates is a bit of a pain and they are awfully ugly (at least mine were!). These days, I seem to be using yasnippets most of the time. It isn't because it is the best template solution, but rather it is because it seems to be incorporated into many other modes I use and I can often just install a package which has 80% of the snippets I need for a specific mode. I suspect it is a bit of a VHS v Betamax situation - yasnippets may not be the best solution, but it seems to have grabbed largest market share! Tim -- Tim Cross ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 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 1 sibling, 1 reply; 87+ messages in thread From: Rasmus @ 2018-05-07 22:30 UTC (permalink / raw) To: emacs-orgmode Aaron Ecay <aaronecay@gmail.com> writes: > Hi Rasmus, > > 2018ko maiatzak 5an, Rasmus-ek idatzi zuen: > >> Cool, I at least did not know that one. >> Can you a reproducible way to try it out? >> Without having to make my own templates etc. > > I havenʼt done anything with it myself. > > You can open up a blank .el file and test out some of emacsʼs built-in > templates. M-x srecode-minor-mode, and then “C-c / /” will prompt you for > the name of a template to insert. Entering file:major-mode at the > resulting prompt might be the most interesting one. Certain keys are > bound to common templates, examples are “C-c / f” for inserting a function > and “C-c / v” for a variable Srecode seems pretty neat, though it might only work in file buffers. Other than being shipped with Emacs, does it have any advantage over yas? Are there any plans to merge the two or make them more compatible? > Just as an aside, I have now also learned that emacs also includes > skeleton.el, which is yet a third template expansion library. Sigh. I think it was too restrictive. I think I also tried abbrev and found it not sufficient. Rasmus -- It was you, Jezebel, it was you ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 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 0 siblings, 2 replies; 87+ messages in thread From: Aaron Ecay @ 2018-05-08 0:25 UTC (permalink / raw) To: Rasmus, emacs-orgmode Hi Rasmus, 2018ko maiatzak 7an, Rasmus-ek idatzi zuen: > Srecode seems pretty neat, though it might only work in file buffers. > Other than being shipped with Emacs, does it have any advantage over yas? > Are there any plans to merge the two or make them more compatible? Not AFAIK (to both questions). Yasnippet is in GNU ELPA, so the barrier to it becoming integrated into emacs (in whatever way) is low (or at least, not dominated by questions of copyright assignment). > > I think [skeleton.el] was too restrictive. I think I also tried > abbrev and found it not sufficient. Itʼs a pity. In an ideal world emacs would have only one built-in template expansion system which we could build on, instead of 3-4 (depending on whether you count abbrev). But, this is the world we live in. (This is certainly not a criticism of org-tempo btw!) From another message in the thread: > Thanks. I guess it would be enough to check if the elements of the alist > are cons (newer Orgs) or lists (older orgs). A more "complex" procedure > could look for at the content of the ca?dr, I guess, but I don’t know if > that’s necessary. AIUI the change was from a cons of (character, template string) to a cons of (string, template string). The relevant commit is b56df73. -- Aaron Ecay ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-08 0:25 ` Aaron Ecay @ 2018-05-08 7:36 ` Bastien 2018-05-13 20:52 ` Rasmus 1 sibling, 0 replies; 87+ messages in thread From: Bastien @ 2018-05-08 7:36 UTC (permalink / raw) To: Aaron Ecay; +Cc: emacs-orgmode, Rasmus Hi Aaron, Aaron Ecay <aaronecay@gmail.com> writes: > Not AFAIK (to both questions). Yasnippet is in GNU ELPA, so the barrier > to it becoming integrated into emacs (in whatever way) is low (or at > least, not dominated by questions of copyright assignment). I think the barrier is pretty high, because the general trend is rather to move things *out* of Emacs. -- Bastien ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-08 0:25 ` Aaron Ecay 2018-05-08 7:36 ` Bastien @ 2018-05-13 20:52 ` Rasmus 1 sibling, 0 replies; 87+ messages in thread From: Rasmus @ 2018-05-13 20:52 UTC (permalink / raw) To: emacs-orgmode Aaron Ecay <aaronecay@gmail.com> writes: > AIUI the change was from a cons of (character, template string) to a > cons of (string, template string). The relevant commit is b56df73. That’s an irrelevant change as neither of those formats has been published. The "old" format (9.1 and earlier) is a list of (key template-string), e.g. ("s" "#+BEGIN_SRC ? #+END_SRC") The new is something like ("s" . "src") Rasmus -- I feel emotional landscapes they puzzle me ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-01 12:35 ` Nicolas Goaziou 2018-05-01 16:28 ` Aaron Ecay @ 2018-05-01 16:54 ` Cook, Malcolm 2018-05-05 18:01 ` Rasmus ` (2 subsequent siblings) 4 siblings, 0 replies; 87+ messages in thread From: Cook, Malcolm @ 2018-05-01 16:54 UTC (permalink / raw) To: Nicolas Goaziou, Steve Downey; +Cc: Bastien, Tim Cross, Org-mode, Jon Snader Thanks for the re-cap. I'm changing my vote. Make the change! Change the default! And make lots of noise advertising it (make more prominent https://orgmode.org/Changes.html , etc). Someone suggested going to v10.x Is there a case for this? Thx of org! > -----Original Message----- > From: Emacs-orgmode <emacs-orgmode- > bounces+mec=stowers.org@gnu.org> On Behalf Of Nicolas Goaziou > Sent: Tuesday, May 01, 2018 7:36 AM > 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: [O] [POLL] Should Org tempo be enabled by default? (expand > templates thru e.g. "<s[TAB]") > > 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 ;) ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-01 12:35 ` Nicolas Goaziou 2018-05-01 16:28 ` Aaron Ecay 2018-05-01 16:54 ` Cook, Malcolm @ 2018-05-05 18:01 ` Rasmus 2018-05-06 5:00 ` Carsten Dominik 2018-05-08 7:37 ` Bastien 2018-05-05 23:26 ` Adrian Bradd 2018-05-08 7:31 ` Bastien 4 siblings, 2 replies; 87+ messages in thread From: Rasmus @ 2018-05-05 18:01 UTC (permalink / raw) To: emacs-orgmode Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > 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. Nicolas, I have been wondering about something, reading all these posts, irrespective of whether tempo is loaded by default or not (I don’t care). Do you think org-tempo should try to detect "old" versions of org-structure-template-alist and give a better error if it sees one? I don’t know what the "best practice" is this case... Thanks, Rasmus -- When in doubt, do it! ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 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 1 sibling, 1 reply; 87+ messages in thread From: Carsten Dominik @ 2018-05-06 5:00 UTC (permalink / raw) To: Rasmus; +Cc: org-mode list [-- Attachment #1: Type: text/plain, Size: 1754 bytes --] On Sat, May 5, 2018 at 8:02 PM Rasmus <rasmus@gmx.us> wrote: > Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > > > 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. > > Nicolas, I have been wondering about something, reading all these posts, > irrespective of whether tempo is loaded by default or not (I don’t care). > > Do you think org-tempo should try to detect "old" versions of > org-structure-template-alist and give a better error if it sees one? I > don’t know what the "best practice" is this case... > Yes, it absolutely should. Carsten > > Thanks, > Rasmus > > -- > When in doubt, do it! > > > [-- Attachment #2: Type: text/html, Size: 2550 bytes --] ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-06 5:00 ` Carsten Dominik @ 2018-05-07 22:33 ` Rasmus 0 siblings, 0 replies; 87+ messages in thread From: Rasmus @ 2018-05-07 22:33 UTC (permalink / raw) To: emacs-orgmode Carsten Dominik <dominik@uva.nl> writes: > On Sat, May 5, 2018 at 8:02 PM Rasmus <rasmus@gmx.us> wrote: > >> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: >> >> > 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. >> >> Nicolas, I have been wondering about something, reading all these posts, >> irrespective of whether tempo is loaded by default or not (I don’t care). >> >> Do you think org-tempo should try to detect "old" versions of >> org-structure-template-alist and give a better error if it sees one? I >> don’t know what the "best practice" is this case... >> > > Yes, it absolutely should. Thanks. I guess it would be enough to check if the elements of the alist are cons (newer Orgs) or lists (older orgs). A more "complex" procedure could look for at the content of the ca?dr, I guess, but I don’t know if that’s necessary. Rasmus -- I feel emotional landscapes they puzzle me ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-05 18:01 ` Rasmus 2018-05-06 5:00 ` Carsten Dominik @ 2018-05-08 7:37 ` Bastien 2018-05-21 14:35 ` Rasmus 1 sibling, 1 reply; 87+ messages in thread From: Bastien @ 2018-05-08 7:37 UTC (permalink / raw) To: Rasmus; +Cc: emacs-orgmode Hi Rasmus, Rasmus <rasmus@gmx.us> writes: > Do you think org-tempo should try to detect "old" versions of > org-structure-template-alist and give a better error if it sees one? Yes, it definitely should detect old format and fix it. -- Bastien ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-08 7:37 ` Bastien @ 2018-05-21 14:35 ` Rasmus 0 siblings, 0 replies; 87+ messages in thread From: Rasmus @ 2018-05-21 14:35 UTC (permalink / raw) To: emacs-orgmode Bastien <bzg@gnu.org> writes: > Hi Rasmus, > > Rasmus <rasmus@gmx.us> writes: > >> Do you think org-tempo should try to detect "old" versions of >> org-structure-template-alist and give a better error if it sees one? > > Yes, it definitely should detect old format and fix it. I don’t remember if I replied to this or not. In any case, it will not be able to "fix" an old template, as it can be much more complex than the new syntax. I would simply raise an error with a helpful text if the "old" format is detected. Rasmus -- m-mm-mmm-mmmm bacon! ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-01 12:35 ` Nicolas Goaziou ` (2 preceding siblings ...) 2018-05-05 18:01 ` Rasmus @ 2018-05-05 23:26 ` Adrian Bradd 2018-05-05 23:37 ` Josiah Schwab 2018-05-08 7:31 ` Bastien 4 siblings, 1 reply; 87+ messages in thread From: Adrian Bradd @ 2018-05-05 23:26 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Org-mode > 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. I believe this was for the Magit Kickstarter fundraiser. A message was displayed to notify users and direct them to the page. This message stayed in place until the Kickstarter was completed, but could be disabled prematurely by altering a variable. I can't speak to its success or failure overall, but there were some complaints about the method [1]. > We could also make the <https://orgmode.org/Changes.html> page > more > prominent in the summary displayed along with the package. This seems like a step in the right direction. Perhaps adding a section to the Introduction in the manual about the changes page or ORG-NEWS and their importance with major or .X releases might help. My experience as a newcomer to org with the 8.x to 9.x transition was that most of the posts relating to org at the time (on reddit at least) mentioned breaking changes and the ORG-NEWS file. With regard to the poll, I don't have a strong opinion as I am now using yasnippet with org. When I was using org-tempo I didn't see any issue with having to require it in my init. So I suppose my vote would be that disabling by default is fine. `org-insert-structure-template' bound to a key seems like a reasonable alternative especially since it operates on regions. Cheers, [1] https://github.com/magit/magit/issues/3174 -- Adrian ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-05 23:26 ` Adrian Bradd @ 2018-05-05 23:37 ` Josiah Schwab 0 siblings, 0 replies; 87+ messages in thread From: Josiah Schwab @ 2018-05-05 23:37 UTC (permalink / raw) To: Adrian Bradd; +Cc: Org-mode, Nicolas Goaziou On 5 May 2018 at 16:26 PDT, Adrian Bradd wrote: >> 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. > > I believe this was for the Magit Kickstarter fundraiser. A message was > displayed to notify users and direct them to the page. No, I believe what was being referenced was this: https://github.com/magit/magit/issues/1803 Josiah ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-01 12:35 ` Nicolas Goaziou ` (3 preceding siblings ...) 2018-05-05 23:26 ` Adrian Bradd @ 2018-05-08 7:31 ` Bastien 4 siblings, 0 replies; 87+ messages in thread From: Bastien @ 2018-05-08 7:31 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Tim Cross, Org-mode, Jon Snader, Steve Downey Hi Nicolas, Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > 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. I propose to make it 100% backward-compatible. > - It will break because there are 9 other incompatible changes between > 9.1 and 9.2. It is not because many things will break that we should not fix that one thing - quite on the contrary: it's because we think "that thing can break, it's okay" that many things will break. > 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. Quoting RMS exact words: Org mode is an example of how Emacs development went astray. https://lists.gnu.org/archive/html/emacs-devel/2016-06/msg00272.html FWIW I agree with John's answer: However, the super-tight coupling of Org-mode's features allows them to cooperate in ways that are usually "to the point", and sometimes elegant. https://lists.gnu.org/archive/html/emacs-devel/2016-06/msg00273.html > 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. Sometimes we will need to externalize an Org feature to not reinvent the wheel unnecessarily and to provide it as a separate package, and orgalist.el is a good example of that. Sometimes we will add functionalities in Org's core by reusing core Emacs features. Using tempo.el to let Org easily insert templates is a natural thing to do, especially because Org *has* structures like #+begin...#+end that exactly match the need for template insertion. Vim users like to make fun of Emacs because it does too much. But Emacs users don't understand why this would be laughable... because Emacs *rocks*. I'd like Org to keep the same level of awesomeness. -- Bastien ^ permalink raw reply [flat|nested] 87+ messages in thread
* [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
@ 2018-04-29 10:24 Bastien
2018-04-29 10:50 ` Nicolas Goaziou
2018-04-30 16:36 ` Steve Downey
0 siblings, 2 replies; 87+ messages in thread
From: Bastien @ 2018-04-29 10:24 UTC (permalink / raw)
To: emacs-orgmode
Hi Nicolas,
I enabled org-tempo by default in commit 71ad7d1 ("org.el: Add
org-tempo to the list of default modules") and I completed the
commit message with this explanation:
"Template expansion is likely to be expected by many users, as it was
on by default in previous releases. Let's load org-tempo by default
and let users remove it. If needed, we can remove this in future
releases."
I meant "Template expansion through typing <sTAB" of course.
You seem to disagree as you just disabled Org tempo in commit 4c13d0a
("Do not load Org Tempo by default"), saying:
"Org Tempo is a backward compatible substitute for the new expansion
mechanism. It is only available for either die-hard "<s" users or
power users that need advanced templates."
So we seem to disagree here. I think org-tempo should be enabled by
default because "<s" is really much more convenient than having to pop
up a big menu from a new keybinding and select a key there. Also, I
don't think what's inconvenient in enabling this by default and I see
how users of 9.2 will be confused by losing the "<s" feature.
I wonder what users on this list think, maybe I'm wrong.
Should the old expansion mechanism "<s" be enabled by default?
--
Bastien
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 10:24 Bastien @ 2018-04-29 10:50 ` Nicolas Goaziou 2018-04-29 11:05 ` Bastien 2018-04-29 20:25 ` Rasmus 2018-04-30 16:36 ` Steve Downey 1 sibling, 2 replies; 87+ messages in thread From: Nicolas Goaziou @ 2018-04-29 10:50 UTC (permalink / raw) To: Bastien; +Cc: emacs-orgmode Hello, Bastien <bzg@gnu.org> writes: > You seem to disagree as you just disabled Org tempo in commit 4c13d0a > ("Do not load Org Tempo by default"), saying: You disagreed with me in the first place with commit 71ad7b1. It was my original intent to not load Org Tempo by default. > I wonder what users on this list think, maybe I'm wrong. > > Should the old expansion mechanism "<s" be enabled by default? Some history first. We introduced a new expansion mechanism, recently bound to `C-c C-,'. This mechanism is more in line with usual Org functions: it operates on regions like, say, `org-insert-drawer'. It is an obvious default expansion mechanism. If the big menu, we could however improve it with an "expert" UI, like we already do for export and tags. Now, some users are used to "<s" constructs, and are not willing to switch to that expansion mechanism. Fair enough. I first suggested to use Yasnippets, which is powerful enough and easy to use. Some users still didn't want to use that. Well. I suggested Tempo, but, admittedly, out of the box, it is not really usable. Then Rasmus wrote Org Tempo. Even though Org Tempo is probably useful for a part of users, it is yet another occurrence of NIH in Org mode. Instead of using already available, and fitting, libraries for a task, we implement one. Also, it will probably prevent the default expansion mechanism to receive feedback, and therefore, improvements (even though it is better for basic uses) because users will not even notice the new mechanism if the old one works out of the box. IMO, Org Tempo should live outside of Org core, like many other Org-related libraries. Some die-hard "<s" users might be annoyed if they had to install an external library. So asking for a "(require 'org-tempo)" was an acceptable compromise, until your disagreement. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 10:50 ` Nicolas Goaziou @ 2018-04-29 11:05 ` Bastien 2018-04-29 12:01 ` Nicolas Goaziou ` (5 more replies) 2018-04-29 20:25 ` Rasmus 1 sibling, 6 replies; 87+ messages in thread From: Bastien @ 2018-04-29 11:05 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: emacs-orgmode Hi Nicolas, Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > You disagreed with me in the first place with commit 71ad7b1. It was my > original intent to not load Org Tempo by default. Sorry if I missed the statement where you explicitely said you thought org-tempo should not be enabled by default, I thought it was just an oversight and I didn't realize I was in a disagreement with you when I pushed this commit -- if I thought so, I'd write to you on the list to raise the topic instead of forcing a change through a commit. Again, I may be wrong in thinking disabling this will cause trouble to many users. Let's just take a moment to see what users think. Thanks, -- Bastien ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 11:05 ` Bastien @ 2018-04-29 12:01 ` Nicolas Goaziou 2018-04-29 13:22 ` Bastien 2018-05-08 8:37 ` Bastien 2018-04-29 13:24 ` Christian Moe ` (4 subsequent siblings) 5 siblings, 2 replies; 87+ messages in thread From: Nicolas Goaziou @ 2018-04-29 12:01 UTC (permalink / raw) To: Bastien; +Cc: emacs-orgmode Bastien <bzg@gnu.org> writes: > Again, I may be wrong in thinking disabling this will cause trouble to > many users. Let's just take a moment to see what users think. It will case trouble during the time necessary to read ORG-NEWS incompatible changes section or ask the mailing list, and then adding (require 'org-tempo) to their configuration file. It seems nonsensical to let Org handle expansion templates. Dedicated packages do it way better than what we provide, and the task is really out of our scope. Worse, we would provide two different ways to expand blocks /by default/. Dying a little, ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 12:01 ` Nicolas Goaziou @ 2018-04-29 13:22 ` Bastien 2018-04-29 17:40 ` Thomas S. Dye ` (2 more replies) 2018-05-08 8:37 ` Bastien 1 sibling, 3 replies; 87+ messages in thread From: Bastien @ 2018-04-29 13:22 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: emacs-orgmode Hi Nicolas, Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > Bastien <bzg@gnu.org> writes: > >> Again, I may be wrong in thinking disabling this will cause trouble to >> many users. Let's just take a moment to see what users think. > > It will case trouble during the time necessary to read ORG-NEWS > incompatible changes section or ask the mailing list, and then adding > (require 'org-tempo) to their configuration file. I wish I'd be as optimistic as you are and assume every user reads ORG-NEWS! I seriously doubt a majority of users do. Those installing Org from ELPA cannot possibly know where to find ORG-NEWS, Org gives no indication where it lives: IOW, it's not even because users are lazy or what. > It seems nonsensical to let Org handle expansion templates. Dedicated > packages do it way better than what we provide, and the task is really > out of our scope. I can't remember anybody complaining Org's expansion mechanism. > Worse, we would provide two different ways to expand blocks /by > default/. I see it differently. You and Rasmus (and those participating to the discussion) cleanly separated two functionalities: one is to *insert* templates the other one is to *expand* them. M-x org-insert-structure-template RET is good for discovery as it lets users see what templates are availables and <[KEY][TAB] is good for fast inline expansion. Both complete each other IMO, and both deserve to be in Org's core. But again, I might be wrong, I just don't want this to be a discussion between us two :) -- Bastien ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 13:22 ` Bastien @ 2018-04-29 17:40 ` Thomas S. Dye 2018-04-29 20:56 ` Bastien 2018-04-29 22:27 ` Tim Cross 2018-04-30 8:47 ` Eric S Fraga 2 siblings, 1 reply; 87+ messages in thread From: Thomas S. Dye @ 2018-04-29 17:40 UTC (permalink / raw) To: Bastien; +Cc: emacs-orgmode, Nicolas Goaziou Bastien writes: > I wish I'd be as optimistic as you are and assume every user > reads > ORG-NEWS! I seriously doubt a majority of users do. Those > installing > Org from ELPA cannot possibly know where to find ORG-NEWS, Org > gives > no indication where it lives: IOW, it's not even because users > are > lazy or what. Would it be difficult to add an ORG-NEWS option to the Documentation section of the Org drop-down menu? It's an interesting document. Re: org tempo. I really appreciate all the work done to preserve backward compatibility with the expansion mechanism. I use Org for almost all my work nowadays and I hate to put my other work on hold to re-implement some Org mode functionality that I rely on. That said, I didn't find the addition of (require org-tempo) to my configuration onerous. I admire the kind of thinking that simplifies in order to make complexity possible. Keep it up! All the best, Tom -- Thomas S. Dye http://www.tsdye.com ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 17:40 ` Thomas S. Dye @ 2018-04-29 20:56 ` Bastien 2018-04-29 22:05 ` Tim Cross 0 siblings, 1 reply; 87+ messages in thread From: Bastien @ 2018-04-29 20:56 UTC (permalink / raw) To: Thomas S. Dye; +Cc: emacs-orgmode, Nicolas Goaziou Hi Thomas, "Thomas S. Dye" <tsd@tsdye.com> writes: > Would it be difficult to add an ORG-NEWS option to the Documentation > section of the Org drop-down menu? It's an interesting document. Yes, I see why this how this could be useful, but there are problems: - ORG-NEWS is not in the ELPA and ELPAPLUS package for now; - Do we want the whole ORG-NEWS or just the first section? - We could point to several web pages instead of the file: https://orgmode.org/Changes.html https://code.orgmode.org/bzg/org-mode/src/master/etc/ORG-NEWS ... I'm not sure what direction is best. Ideas welcome! > Re: org tempo. I really appreciate all the work done to preserve > backward compatibility with the expansion mechanism. I use Org for > almost all my work nowadays and I hate to put my other work on hold to > re-implement some Org mode functionality that I rely on. > > That said, I didn't find the addition of (require org-tempo) to my > configuration onerous. I admire the kind of thinking that simplifies > in order to make complexity possible. Keep it up! Thanks for your feedback, -- Bastien ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 20:56 ` Bastien @ 2018-04-29 22:05 ` Tim Cross 2018-04-29 22:31 ` Bastien 0 siblings, 1 reply; 87+ messages in thread From: Tim Cross @ 2018-04-29 22:05 UTC (permalink / raw) To: Bastien; +Cc: emacs-orgmode, Nicolas Goaziou Bastien <bzg@gnu.org> writes: > "Thomas S. Dye" <tsd@tsdye.com> writes: > >> Would it be difficult to add an ORG-NEWS option to the Documentation >> section of the Org drop-down menu? It's an interesting document. > > Yes, I see why this how this could be useful, but there are problems: > > - ORG-NEWS is not in the ELPA and ELPAPLUS package for now; > > - Do we want the whole ORG-NEWS or just the first section? > > - We could point to several web pages instead of the file: > https://orgmode.org/Changes.html > https://code.orgmode.org/bzg/org-mode/src/master/etc/ORG-NEWS > > ... I'm not sure what direction is best. Ideas welcome! > Given that Emacs has eww, linking to a web page for NEWS from the menu seems to be OK. However, I just noticed that org-plus-contrib and org from the org repos do have NEWS.org, so for consistency, shouldn't they be added to elpa's versions? -- Tim Cross ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 22:05 ` Tim Cross @ 2018-04-29 22:31 ` Bastien 0 siblings, 0 replies; 87+ messages in thread From: Bastien @ 2018-04-29 22:31 UTC (permalink / raw) To: Tim Cross; +Cc: emacs-orgmode, Nicolas Goaziou Hi Tim, Tim Cross <theophilusx@gmail.com> writes: > Given that Emacs has eww, linking to a web page for NEWS from the menu > seems to be OK. I added a new menu entry "Org Browse News" which takes the user to https://orgmode.org/Changes.html > However, I just noticed that org-plus-contrib and org > from the org repos do have NEWS.org, so for consistency, shouldn't they > be added to elpa's versions? Yes, we can do that as well. Thanks! -- Bastien ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 13:22 ` Bastien 2018-04-29 17:40 ` Thomas S. Dye @ 2018-04-29 22:27 ` Tim Cross 2018-04-29 23:03 ` Bastien 2018-05-01 15:49 ` Aaron Ecay 2018-04-30 8:47 ` Eric S Fraga 2 siblings, 2 replies; 87+ messages in thread From: Tim Cross @ 2018-04-29 22:27 UTC (permalink / raw) To: Bastien; +Cc: emacs-orgmode, Nicolas Goaziou Bastien <bzg@gnu.org> writes: > Hi Nicolas, > > Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > >> Bastien <bzg@gnu.org> writes: >> >>> Again, I may be wrong in thinking disabling this will cause trouble to >>> many users. Let's just take a moment to see what users think. >> >> It will case trouble during the time necessary to read ORG-NEWS >> incompatible changes section or ask the mailing list, and then adding >> (require 'org-tempo) to their configuration file. > > I wish I'd be as optimistic as you are and assume every user reads > ORG-NEWS! I seriously doubt a majority of users do. Those installing > Org from ELPA cannot possibly know where to find ORG-NEWS, Org gives > no indication where it lives: IOW, it's not even because users are > lazy or what. > >> It seems nonsensical to let Org handle expansion templates. Dedicated >> packages do it way better than what we provide, and the task is really >> out of our scope. > > I can't remember anybody complaining Org's expansion mechanism. > >> Worse, we would provide two different ways to expand blocks /by >> default/. > > I see it differently. You and Rasmus (and those participating to the > discussion) cleanly separated two functionalities: one is to *insert* > templates the other one is to *expand* them. > > M-x org-insert-structure-template RET is good for discovery as it lets > users see what templates are availables and <[KEY][TAB] is good for > fast inline expansion. > > Both complete each other IMO, and both deserve to be in Org's core. > > But again, I might be wrong, I just don't want this to be a discussion > between us two :) The problem here is two competing objectives. I agree with Nicholas' position that overall, org should not reproduce/re-invent/duplicate functionality already provided by Emacs or well established Emacs packages like ysnippets etc. On the other hand, Bastien's concern regarding impact on users and basic change management concerns are very valid. There is no solution which will make everyone happy. However, as a long term org user who hopes to continue using org for many more years, I tend to come down on the side of whatever will make org easier to maintain in the long term. 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. So while some of the changes Nicholas has proposed may have some short term inconvenience, I agree with his approach and I agree that if we enable org-tempo by default, we are unlikely to see people switch and org-tempo will end up being another module needing to be maintained as part of core. While the switch will be a little inconvenient for me while I learn to re-train my fingers, I think what I'm really doing is undoing a bad habit learned because of the original '<s' expansion. I recall being a little frustrated when I first started using org that I had to learn another expansion key binding just for org mode. Consequently, I'm not going to enable org-tempo, instead going for re-training of my fingers to use the new C-c ' binding. I agree with Thomas that adding an org-tempo require is an easy addition for those who do not have the time/inclination to make the change immediately. So in basic terms, I agree with Nicholas' position. Having said that, I do feel he is being optimistic/pragmatic and Bastien's concerns are very valid. I don't think people will read the NEWS file and I do expect we will see numerous posts about org templates not working. However, this should only be a short term bit of pain and I don't see it can be avoided. The tempo solution will go a long way to reduce that pain for those who don't have time to deal with the change right now. Most reasonable people will understand why this change is occurring provided we can make the rationale clear and easy to find, so information on the org web site, to relevant mail lists and any other forum would be a good idea. Tim -- Tim Cross ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 22:27 ` Tim Cross @ 2018-04-29 23:03 ` Bastien 2018-04-30 10:29 ` Nicolas Goaziou ` (2 more replies) 2018-05-01 15:49 ` Aaron Ecay 1 sibling, 3 replies; 87+ messages in thread From: Bastien @ 2018-04-29 23:03 UTC (permalink / raw) To: Tim Cross; +Cc: emacs-orgmode, Nicolas Goaziou Hi Tim, thanks for your thorough and balanced feedback. Tim Cross <theophilusx@gmail.com> writes: > There is no solution which will make everyone happy. However, as a long > term org user who hopes to continue using org for many more years, I > tend to come down on the side of whatever will make org easier to > maintain in the long term. For org-tempo, Rasmus wrote it so I'm inclined to listen quite carefully at his opinion. > I think org itself should provide a very stable core and avoid > incorporating too many add on enhancements. I agree too. But outline would have stayed something that nobody cares about until Org came, enhancing the outline experience. And I guess tempo.el, something that RMS wrote in 1995, would stay unknown until more users are exposed through it via org-tempo.el... So I don't see org-tempo.el as something that adds extra burden: it is a reasonable reuse of some core (underknown) Emacs functionality. > Consequently, I'm not going to enable org-tempo, instead going for > re-training of my fingers to use the new C-c ' binding. You certainly mean C-c C-, :) > So in basic terms, I agree with Nicholas' position. Having said that, I > do feel he is being optimistic/pragmatic and Bastien's concerns are very > valid. To give some context: I've run a few Emacs friendly workshops in Paris (France) since the last few months. French readers can check them here: https://www.emacs-doctor.com/emacs-paris-user-group/ All the discussions have been really eye-opening to me in terms of usability. I could not believe Emacs users with 10 years of Emacs-fu would not know text-scale-increase, or M-<left/right> in Org's table, or whatever. They could not believe I was ignoring X, Y, Z. And *many* of them were so frustrated with Org's installation experience and some "missing" features from one version to another... hearing these complaints face to face face something. Yes, from an individual point of view, adding (require 'org-tempo) is nothing but I've tangible feedback of the pain such change can induce for other users. Here is what the experience can look like: - Upgrading Emacs or Org (hurray!!) - Trying to hit <s as usual one month after the upgrade - Thinking your stupid - Bisecting your configuration file to see if something changed - Trying to remember to name of the command for <[key][tab] - Not finding the name of the command - Thinking your stupid - Remembering you upgraded Org - Not remembering whether you updated Org or Emacs or both - Guessing it was just Org - Running M-x org-version RET - Looking for the email annoncement of 9.2 - Finding a one-liner saying "Enjoy!" (#ðßðđłßðđ!!) - Remembering there is an orgmode.org website - Feeling a bit annoyed by the 7 years old cheesy design - Finding the "See the release note" after three minutes - Adding a TODO task "Read Org's release notes..." - Reading them and not remembering what you're looking for - Thinking your stupid - Realizing you're looking for why <sTAB is gone - Wondering how to call <sTAB: completion? expansion? extension? - Finding entries in ORG-NEWS a bit boring to read (youth is gone) - Not being entirely sure to understand what it says as english is not your your mother tongue (happens to the best of us!) - Guessing through the lines that you need (require 'org-tempo) - Wondering whether you'll learn salsa by adding this (tempo??) - Thinking your stupid - Testing and celebrating <sTAB is back - WONDERING WHY YOU HAD TO DO ALL THIS - Remembering the years when such victories boosted your mood - Feeling you're now too old for this - Or perhaps you're just stupid - Anyway, it works now! - Adding ;;;;;;;;;;;;;;;;;;;;;;;;; on top of (require 'org-tempo) to make sure you never delete it by accident. ... Was it a boring list to read? Even more boring to live. In fact, I'm inclined to ask the real question: if org-tempo is on by default, who will have good reasons to turn it off and why? Good night all! -- Bastien ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 23:03 ` Bastien @ 2018-04-30 10:29 ` Nicolas Goaziou 2018-04-30 14:03 ` Kevin Foley 2018-05-02 12:43 ` Bernt Hansen 2018-05-05 17:17 ` Rasmus 2 siblings, 1 reply; 87+ messages in thread From: Nicolas Goaziou @ 2018-04-30 10:29 UTC (permalink / raw) To: Bastien; +Cc: Tim Cross, emacs-orgmode Hello, Bastien <bzg@gnu.org> writes: > Here is what the experience can look like: > > - Upgrading Emacs or Org (hurray!!) > - Trying to hit <s as usual one month after the upgrade > - Thinking your stupid [...] I have an issue with this argument: it can be opposed to virtually any backward-incompatible change we make. There are actually 10 such changes in Org 9.2. Would it makes sense to remove them because some users, unfortunately, will encounter a workflow break upon updating Org? I totally agree this is an issue, yet, we have to move forward. We can make UX consistent across releases, but we cannot guarantee 100% compatibility at each step. As a data point, I don't know any software that preserves the exact same UX after each release -- Firefox, Gnome, I'm looking at you! There are unavoidable gotchas. This just means Org is still vivid. > In fact, I'm inclined to ask the real question: if org-tempo is on by > default, who will have good reasons to turn it off and why? This is one problem: only a few will have a reason (good or bad, who cares?) to turn it off, e.g., because expansion gets in the way with other templating systems. Possibly even fewer will actually turn it off. As a consequence, the vast majority of users will keep using "<s" -- and put maintenance burden on us -- instead of trying, and improving something else. Inertia... I already stated the following, sorry for re-iterating. Marking a region and wrapping it in some environment is a basic operation Org is expected to provide. We already did with `org-emphasize'. Implementing programmable templates, even though we are re-using what Emacs ships with, is another story. Org Tempo is a nice tool. I'm not questioning this. It is also almost 100% compatible with previous feature. Yet, it competes with external Emacs libraries, as capable as itself. Since it is not a feature mandatory in Org, why forcing it onto the users? I'm inclined to think we shouldn't. Regards, -- Nicolas Goaziou 0x80A93738 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 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 0 siblings, 2 replies; 87+ messages in thread From: Kevin Foley @ 2018-04-30 14:03 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: bzg, theophilusx, emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 3380 bytes --] Bastien <bzg@gnu.org> writes: > Here is what the experience can look like: > > - Upgrading Emacs or Org (hurray!!) > - Trying to hit <s as usual one month after the upgrade > - Thinking your stupid [...] I have to admit that Bastien's list describes my experience almost perfectly. It look me a long time to figure out something that in the end seemed very simple. At the time I wasn't familiar with the NEWS file and it didn't come up in any of my online searches. It also didn't help that site still documented the old behavior (and apparently still does https://orgmode.org/manual/Easy-templates.html). After reading Nicolas' points, I see the argument for moving people away from org-tempo, actually I'm very excited to start using yasnippet. I've been putting off incorporating it into my workflow for a while but this thread has finally convinced me to start. However, I do think the transition could be made a lot smoother for new users. The biggest step would be updating the easy-templates page to let users know they now need to use org-tempo and should consider alternatives such as yasnippet for more functionality. Regards, Kevin On Mon, Apr 30, 2018 at 6:29 AM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote: > Hello, > > Bastien <bzg@gnu.org> writes: > > > Here is what the experience can look like: > > > > - Upgrading Emacs or Org (hurray!!) > > - Trying to hit <s as usual one month after the upgrade > > - Thinking your stupid > > [...] > > I have an issue with this argument: it can be opposed to virtually any > backward-incompatible change we make. There are actually 10 such changes > in Org 9.2. Would it makes sense to remove them because some users, > unfortunately, will encounter a workflow break upon updating Org? > > I totally agree this is an issue, yet, we have to move forward. We can > make UX consistent across releases, but we cannot guarantee 100% > compatibility at each step. As a data point, I don't know any software > that preserves the exact same UX after each release -- Firefox, Gnome, > I'm looking at you! There are unavoidable gotchas. This just means Org > is still vivid. > > > In fact, I'm inclined to ask the real question: if org-tempo is on by > > default, who will have good reasons to turn it off and why? > > This is one problem: only a few will have a reason (good or bad, who > cares?) to turn it off, e.g., because expansion gets in the way with > other templating systems. Possibly even fewer will actually turn it off. > As a consequence, the vast majority of users will keep using "<s" -- and > put maintenance burden on us -- instead of trying, and improving > something else. Inertia... > > I already stated the following, sorry for re-iterating. Marking a region > and wrapping it in some environment is a basic operation Org is expected > to provide. We already did with `org-emphasize'. Implementing > programmable templates, even though we are re-using what Emacs ships > with, is another story. > > Org Tempo is a nice tool. I'm not questioning this. It is also almost > 100% compatible with previous feature. Yet, it competes with external > Emacs libraries, as capable as itself. Since it is not a feature > mandatory in Org, why forcing it onto the users? I'm inclined to think > we shouldn't. > > Regards, > > -- > Nicolas Goaziou 0x80A93738 > > [-- Attachment #2: Type: text/html, Size: 13893 bytes --] ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-30 14:03 ` Kevin Foley @ 2018-04-30 14:17 ` Kevin Foley 2018-05-05 17:20 ` Rasmus 1 sibling, 0 replies; 87+ messages in thread From: Kevin Foley @ 2018-04-30 14:17 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: bzg, theophilusx, emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 1032 bytes --] I should add that one issue with org-tempo is it doesn't seem to be backwards compatible with old templates. For example packages such as ob-sql-mode and org-reveal have easy templates based on the old format such as : (add-to-list 'org-structure-template-alist `(,org-babel-sql-mode-template-selector "#+BEGIN_SRC sql-mode ?\n\n#+END_SRC" "#+BEGIN_SRC sql-mode ?\n\n#+END_SRC")) https://github.com/nikclayton/ob-sql-mode/blob/8d36d312bec4a742bec8890373948a888cac18de/ob-sql-mode.el#L187 This causes the cryptic error "File mode specification error: (error Format specifier doesn’t match argument type)" when trying to load org-mode which took me ages to figure out and could potentially turn someone new to org-mode/emacs off forever. I think this would be a good reason to not enable org-tempo at least for the time being until either it can handle templates in the old format, or produces a less cryptic error for users. Regards, Kevin [-- Attachment #2: Type: text/html, Size: 1402 bytes --] ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-30 14:03 ` Kevin Foley 2018-04-30 14:17 ` Kevin Foley @ 2018-05-05 17:20 ` Rasmus 1 sibling, 0 replies; 87+ messages in thread From: Rasmus @ 2018-05-05 17:20 UTC (permalink / raw) To: emacs-orgmode Kevin Foley <kfoley15@gmail.com> writes: > Bastien <bzg@gnu.org> writes: > > I have to admit that Bastien's list describes my experience almost > perfectly. It look me a long time to figure out something that in the end > seemed very simple. At the time I wasn't familiar with the NEWS file and > it didn't come up in any of my online searches. It also didn't help that > site still documented the old behavior (and apparently still does > https://orgmode.org/manual/Easy-templates.html). AFAIK the maint manual is published online. Rasmus -- The right to be left alone is a human right ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 23:03 ` Bastien 2018-04-30 10:29 ` Nicolas Goaziou @ 2018-05-02 12:43 ` Bernt Hansen 2018-05-08 6:23 ` Bastien 2018-05-05 17:17 ` Rasmus 2 siblings, 1 reply; 87+ messages in thread From: Bernt Hansen @ 2018-05-02 12:43 UTC (permalink / raw) To: Bastien; +Cc: Tim Cross, emacs-orgmode, Nicolas Goaziou Hi, I think there is a typo in ORG-NEWS Bastien <bzg@gnu.org> writes: > > Tim Cross <theophilusx@gmail.com> writes: > > >> Consequently, I'm not going to enable org-tempo, instead going for >> re-training of my fingers to use the new C-c ' binding. > > You certainly mean C-c C-, :) > -------------------------------------------------------------------------------- *** Change in the structure template expansion Org 9.2 comes with a new template expansion mechanism, combining ~org-insert-structure-template~ bound to ~C-c C-'~. -------------------------------------------------------------------------------- Shouldn't this be ~C-c C-,~ ? Thanks, Bernt ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-02 12:43 ` Bernt Hansen @ 2018-05-08 6:23 ` Bastien 0 siblings, 0 replies; 87+ messages in thread From: Bastien @ 2018-05-08 6:23 UTC (permalink / raw) To: Bernt Hansen; +Cc: Tim Cross, emacs-orgmode, Nicolas Goaziou Hi Bernt, Bernt Hansen <bernt@norang.ca> writes: > -------------------------------------------------------------------------------- > *** Change in the structure template expansion > > Org 9.2 comes with a new template expansion mechanism, combining > ~org-insert-structure-template~ bound to ~C-c C-'~. > -------------------------------------------------------------------------------- > > Shouldn't this be ~C-c C-,~ ? Indeed, thanks - Nicolas fixed it yesterday. Best, -- Bastien ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 23:03 ` Bastien 2018-04-30 10:29 ` Nicolas Goaziou 2018-05-02 12:43 ` Bernt Hansen @ 2018-05-05 17:17 ` Rasmus 2018-05-08 6:27 ` Bastien 2 siblings, 1 reply; 87+ messages in thread From: Rasmus @ 2018-05-05 17:17 UTC (permalink / raw) To: emacs-orgmode Bastien <bzg@gnu.org> writes: > Hi Tim, > > thanks for your thorough and balanced feedback. > > Tim Cross <theophilusx@gmail.com> writes: > >> There is no solution which will make everyone happy. However, as a long >> term org user who hopes to continue using org for many more years, I >> tend to come down on the side of whatever will make org easier to >> maintain in the long term. > > For org-tempo, Rasmus wrote it so I'm inclined to listen quite > carefully at his opinion. Please don’t. I have not really made any policy decisions of sort. I only missed "<s" once it was cleaned away, and I only "improved/changed" "C-c C-," to better suit my taste. I am not a designer, I just type on my keyboard until it "stuff" works again... Anyhow, my general opinion on these matters is that I wouldn’t want to remove any batteries. I like included batteries... > ... > In fact, I'm inclined to ask the real question: if org-tempo is on by > default, who will have good reasons to turn it off and why? I certainly won’t be :) Rasmus -- However beautiful the theory, one should occasionally look at the evidence ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-05 17:17 ` Rasmus @ 2018-05-08 6:27 ` Bastien 0 siblings, 0 replies; 87+ messages in thread From: Bastien @ 2018-05-08 6:27 UTC (permalink / raw) To: Rasmus; +Cc: emacs-orgmode Hi Rasmus, Rasmus <rasmus@gmx.us> writes: >> For org-tempo, Rasmus wrote it so I'm inclined to listen quite >> carefully at his opinion. > > Please don’t. Done :) > I have not really made any policy decisions of sort. I only missed > "<s" once it was cleaned away, and I only "improved/changed" "C-c > C-," to better suit my taste. I am not a designer, I just type on > my keyboard until it "stuff" works again... I'm glad you triggered this enhancement, so *thanks* ! And I'm glad Nicolas and others helped you polish it. We just need ato polish it a bit more, and it's good to have Aaron hacking around. -- Bastien ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 22:27 ` Tim Cross 2018-04-29 23:03 ` Bastien @ 2018-05-01 15:49 ` Aaron Ecay 2018-05-01 19:31 ` Eric S Fraga ` (2 more replies) 1 sibling, 3 replies; 87+ messages in thread From: Aaron Ecay @ 2018-05-01 15:49 UTC (permalink / raw) To: Tim Cross, Bastien; +Cc: emacs-orgmode, Rasmus, Nicolas Goaziou [-- 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 ^ permalink raw reply related [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 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-08 6:34 ` Bastien 2 siblings, 0 replies; 87+ messages in thread From: Eric S Fraga @ 2018-05-01 19:31 UTC (permalink / raw) To: Tim Cross; +Cc: Bastien, emacs-orgmode, Rasmus, Nicolas Goaziou [-- Attachment #1: Type: text/plain, Size: 761 bytes --] On Tuesday, 1 May 2018 at 16:49, Aaron Ecay wrote: [...] > On the other hand, as an org user breaking changes are inconvenient. We should be clear that there are two different kinds of changes and your post had references to both types: 1. changes to the user interface, e.g. what is being proposed here. 2. changes to the actual structure of org files, e.g. begin_latex becoming begin_export latex. The first are inconvenient but usually (?) only for a short period of time until finger memory has adapted. The second can be much more serious, leading to impact over quite a period of time, especially for those that have accumulated many org files over years. -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-474-g92785f [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 194 bytes --] ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 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-08 6:34 ` Bastien 2 siblings, 1 reply; 87+ messages in thread From: Rasmus Pank Roulund @ 2018-05-02 9:10 UTC (permalink / raw) To: theophilusx; +Cc: bzg, emacs-orgmode, mail Aaron Ecay <aaronecay@gmail.com> writes: > 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. The work on org-tempo and C-c C-, took the change of org-structure-template-alist as a given. > 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. I agree. Rasmus -- The right to be left alone is a human right ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-02 9:10 ` Rasmus Pank Roulund @ 2018-05-02 17:12 ` Aaron Ecay 2018-05-05 17:29 ` Rasmus 0 siblings, 1 reply; 87+ messages in thread From: Aaron Ecay @ 2018-05-02 17:12 UTC (permalink / raw) To: Rasmus Pank Roulund; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 1171 bytes --] Hi Rasmus, 2018ko maiatzak 2an, Rasmus Pank Roulund-ek idatzi zuen: >> 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. > > I agree. OK, thatʼs good to know. Iʼve held off on any pushing of the patch to master until everything is worked out. In the meantime, Iʼve put it in a branch “org-tempo”. I also added a second commit to that branch which implements my vision of the upgrade path (deprecation warnings, etc.) For convenience, that patch is also attached to this email. One remaining decision to make is: what is the future of org-tempo? I am sympathetic to the idea that the best place for it eventually would be org-contrib or GNU ELPA, and not org core. If that is decided now, then we can include that information in the upgrade message (i.e. that users who opt in to org-tempo will eventually have to install it specifically). -- Aaron Ecay [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0002-Add-compatibility-code-to-org-tempo.patch --] [-- Type: text/x-patch, Size: 2857 bytes --] From 414503d59b2129c24e95e1e57b54d5662a17308b Mon Sep 17 00:00:00 2001 From: Aaron Ecay <aaronecay@gmail.com> Date: Wed, 2 May 2018 17:48:18 +0100 Subject: [PATCH 2/2] Add compatibility code to org-tempo This will warn users of <X style templates and prompt them to update their .emacs if they want to continue using the feature. --- lisp/org-tempo.el | 40 +++++++++++++++++++++++++++++++++++++++- lisp/org.el | 6 ++++++ 2 files changed, 45 insertions(+), 1 deletion(-) diff --git a/lisp/org-tempo.el b/lisp/org-tempo.el index 2feed24dc..9923fe769 100644 --- a/lisp/org-tempo.el +++ b/lisp/org-tempo.el @@ -40,7 +40,6 @@ (require 'tempo) (require 'cl-lib) -(require 'org) (defvar org-structure-template-alist) @@ -193,6 +192,45 @@ templates are defined." (define-global-minor-mode org-tempo-global-mode org-tempo-mode org-tempo-mode--activate-in-buffer) +\f +;;; Compatibility code + +;;; The code in this section can be removed in the next major release +;;; after org-tempo was released (currently projected to land in Org +;;; 9.2, therefore removal after Org 10). At that time, the code +;;; activating org-tempo-global-mode should also be removed from +;;; org.el, and (require 'org) should be added to the top of this +;;; file. + +(defvar org-tempo--user-activated nil + "This will be set to t when we detect that the user has +activated org-tempo in their .emacs.") + +(advice-add 'org-tempo-global-mode :after + (lambda (&rest _) + (setq org-tempo--user-activated t))) + +;;; TODO: should we also try to detect the case when the user adds +;;; org-tempo-mode to org-mode-hook? + +(advice-add 'org-tempo-complete-tag :after + (lambda (&rest _) + (unless org-tempo--user-activated + (org-display-warning + (substitute-command-keys "It looks like you have \ +expanded a <X style structure template. + +That feature will be removed from Org in the next major release. +If you would like to continue using it, you should +add `(org-tempo-global-mode 1)' to your emacs initialization +file (which will also disable this warning message). +\\<org-mode-map> +Alternatively, you may wish to use the new template expansion +facility `org-insert-structure-template', which is bound to +\\[org-insert-structure-template] in org-mode buffers."))))) + +\f + (provide 'org-tempo) ;;; org-tempo.el ends here diff --git a/lisp/org.el b/lisp/org.el index 0b8e62357..c67c8d2c5 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -23582,6 +23582,12 @@ when non-nil, is a regexp matching keywords names." (lambda () (add-hook 'change-major-mode-hook 'org-show-all 'append 'local))) +;; For compatibility; remove in Org 10 +(require 'org-tempo) +(defvar org-tempo--user-activated) +(let (org-tempo--user-activated) + (org-tempo-global-mode 1)) + (provide 'org) (run-hooks 'org-load-hook) -- 2.17.0 ^ permalink raw reply related [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-02 17:12 ` Aaron Ecay @ 2018-05-05 17:29 ` Rasmus 2018-05-06 20:02 ` Aaron Ecay 2018-05-08 6:52 ` Bastien 0 siblings, 2 replies; 87+ messages in thread From: Rasmus @ 2018-05-05 17:29 UTC (permalink / raw) To: emacs-orgmode Aaron Ecay <aaronecay@gmail.com> writes: > Hi Rasmus, > > 2018ko maiatzak 2an, Rasmus Pank Roulund-ek idatzi zuen: >>> 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. >> >> I agree. > > OK, thatʼs good to know. Iʼve held off on any pushing of the patch to > master until everything is worked out. In the meantime, Iʼve put it in > a branch “org-tempo”. > > I also added a second commit to that branch which implements my vision > of the upgrade path (deprecation warnings, etc.) For convenience, that > patch is also attached to this email. I don’t like it, I’m afraid. It’s a bit nagging. There’s tools to mark thinks as obsolete in Emacs should we need to. > One remaining decision to make is: what is the future of org-tempo? I am > sympathetic to the idea that the best place for it eventually would be > org-contrib or GNU ELPA, and not org core. We don’t have make that decision now, do we? Rasmus -- This message is brought to you by the department of redundant departments ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-05 17:29 ` Rasmus @ 2018-05-06 20:02 ` Aaron Ecay 2018-05-07 22:53 ` Rasmus 2018-05-08 6:52 ` Bastien 1 sibling, 1 reply; 87+ messages in thread From: Aaron Ecay @ 2018-05-06 20:02 UTC (permalink / raw) To: Rasmus, emacs-orgmode Hi Rasmus, 2018ko maiatzak 5an, Rasmus-ek idatzi zuen: > I don’t like it, I’m afraid. Iʼm sorry to hear that. > It’s a bit nagging. I wouldnʼt call it nagging. The user presses “<s[TAB]” expecting something special to happen. The status quo is that nothing at all happens. My proposal is to make something special happen. Itʼs different than what the user expected, but it informs them of what has changed and how to get the old behavior back if they want. Note that the only circumstance when the “nagging” happens is when a user presses “<s[TAB]”, and it goes away when either they add “(org-tempo-global-mode)” to their .emacs or learn a new habit of pressing C-c C-, instead of <s[TAB] (We could make the warning appear only once per emacs session, if that seems like a better balance.) (The patch I posted on the mailing list had a bug, which would trigger the warning more often than it should be. If you installed and tested the patch from my email message, you would have seen that bug. I pushed a followup commit to the org-tempo branch in the repo that fixes the bug.) > There’s tools to mark thinks as obsolete in Emacs should we need to. There are tools to mark functions and variables obsolete when they are used in elisp code. There is no way of warning a user about non-code changes to the user experience, like (in this case) a changed key binding. > > >> One remaining decision to make is: what is the future of org-tempo? I am >> sympathetic to the idea that the best place for it eventually would be >> org-contrib or GNU ELPA, and not org core. > > We don’t have make that decision now, do we? We donʼt strictly have to. Obviously one approach to making the decision is to wait and see whether org-tempo is widely adopted/used, and remove it from core if not. But if we* can already decide on principle that something like org-tempo belongs best in contrib or ELPA, then we can communicate the relevant info all at once when 9.2 is released, rather than for 9.2: “now add (require 'org-tempo) to .emacs to keep using <s[TAB]” [...time passes, a new org release is born...] “now you also have to install org-tempo from somewhere else.” *Here Iʼm using “we” loosely, I imagine it will mostly be up to you with input from Nicolas and Bastien and perhaps others. -- Aaron Ecay ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-06 20:02 ` Aaron Ecay @ 2018-05-07 22:53 ` Rasmus 2018-05-08 0:57 ` Aaron Ecay 0 siblings, 1 reply; 87+ messages in thread From: Rasmus @ 2018-05-07 22:53 UTC (permalink / raw) To: emacs-orgmode Hi Aaron, Thanks for the reply. Aaron Ecay <aaronecay@gmail.com> writes: > I wouldnʼt call it nagging. The user presses “<s[TAB]” expecting > something special to happen. The status quo is that nothing at all > happens. My proposal is to make something special happen. Itʼs > different than what the user expected, but it informs them of what has > changed and how to get the old behavior back if they want. They’d already have the "old" behavior if it’s enabled by default in org.el. Perhaps I’m too cruel or harsh after many years of dealing with the Emacs-way, but I do think that such as change is adequatly documented in ORG-NEWS and the manual. (Days after a new release there will also be a stackoverflow question for the Googlers). I sometimes open many new Emacs on any given day, sometimes loading my init.el sometimes not. I imagine the message would get old quickly. > Note that the only circumstance when the “nagging” happens is when a > user presses “<s[TAB]”, and it goes away when either they add > “(org-tempo-global-mode)” to their .emacs or learn a new habit of > pressing C-c C-, instead of <s[TAB] I’m perfectly happy with my (Emacs) habits :) > (We could make the warning appear only once per emacs session, if that > seems like a better balance.) Yes, that would be a must. >> There’s tools to mark thinks as obsolete in Emacs should we need to. > > There are tools to mark functions and variables obsolete when they are > used in elisp code. There is no way of warning a user about non-code > changes to the user experience, like (in this case) a changed key > binding. Customize-changed would bring up the changes to org-structure-template-alist, which mentions Org Tempo. ORG-NEWS as well. But now I’m going in circles. > We donʼt strictly have to. Obviously one approach to making the > decision is to wait and see whether org-tempo is widely adopted/used, > and remove it from core if not. But if we* can already decide on > principle that something like org-tempo belongs best in contrib or > ELPA, then we can communicate the relevant info all at once when 9.2 > is released, rather than for 9.2: “now add (require 'org-tempo) to > .emacs to keep using <s[TAB]” [...time passes, a new org release is > born...] “now you also have to install org-tempo from somewhere > else.” Perhaps. As I said, I like batteries included, but it’s not for me to decide. > *Here Iʼm using “we” loosely, I imagine it will mostly be up to you with > input from Nicolas and Bastien and perhaps others. I like the looser definition! Rasmus -- Dung makes an excellent fertilizer ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 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 0 siblings, 2 replies; 87+ messages in thread From: Aaron Ecay @ 2018-05-08 0:57 UTC (permalink / raw) To: Rasmus, emacs-orgmode Hi Rasmus, 2018ko maiatzak 7an, Rasmus-ek idatzi zuen: > > They’d already have the "old" behavior if it’s enabled by default in > org.el. Indeed, my suggestion is not an alternative to keeping (what is now called) org-tempo turned on by default indefinitely. It is an alternative to turning org-tempo off suddenly. > Perhaps I’m too cruel or harsh after many years of dealing with the > Emacs-way, but I do think that such as change is adequatly documented > in ORG-NEWS and the manual. (Days after a new release there will also > be a stackoverflow question for the Googlers). Here I am much more conservative than you: I think that puzzling users so that they ask questions on stack overflow is an outcome that should be avoided if possible. I also think experience shows that ORG-NEWS is missed by a significant fraction of users. Besides, I am a programmer not a writer so I believe in the power of code over prose :P [...] > > Customize-changed would bring up the changes to > org-structure-template-alist, which mentions Org Tempo. Interesting. I didnʼt know about that function. I just tried M-x customize-changed RET Org 9.0 RET. That gives an error; it seems to only work based on emacs versions and not package versions. Thatʼs unfortunate, it would have been nice if people who install org from ELPA could use the function to keep up with org changes independently from their emacs version. (In fact, I just sent this as a feature request to the emacs bug tracker, #31383) -- Aaron Ecay ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-08 0:57 ` Aaron Ecay @ 2018-05-08 6:56 ` Bastien 2018-05-21 14:24 ` Rasmus 1 sibling, 0 replies; 87+ messages in thread From: Bastien @ 2018-05-08 6:56 UTC (permalink / raw) To: Aaron Ecay; +Cc: emacs-orgmode, Rasmus Hi Aaron, Aaron Ecay <aaronecay@gmail.com> writes: > Interesting. I didnʼt know about that function. I just tried M-x > customize-changed RET Org 9.0 RET. That gives an error; it seems to > only work based on emacs versions and not package versions. Thatʼs > unfortunate, it would have been nice if people who install org from ELPA > could use the function to keep up with org changes independently from > their emacs version. (In fact, I just sent this as a feature request to > the emacs bug tracker, #31383) Nice move, I hope someone will implement this as we certainly need it. -- Bastien ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-08 0:57 ` Aaron Ecay 2018-05-08 6:56 ` Bastien @ 2018-05-21 14:24 ` Rasmus 1 sibling, 0 replies; 87+ messages in thread From: Rasmus @ 2018-05-21 14:24 UTC (permalink / raw) To: emacs-orgmode Hi, Aaron Ecay <aaronecay@gmail.com> writes: > Hi Rasmus, > > 2018ko maiatzak 7an, Rasmus-ek idatzi zuen: > >> >> They’d already have the "old" behavior if it’s enabled by default in >> org.el. > > Indeed, my suggestion is not an alternative to keeping (what is now > called) org-tempo turned on by default indefinitely. It is an > alternative to turning org-tempo off suddenly. > >> Perhaps I’m too cruel or harsh after many years of dealing with the >> Emacs-way, but I do think that such as change is adequatly documented >> in ORG-NEWS and the manual. (Days after a new release there will also >> be a stackoverflow question for the Googlers). > > Here I am much more conservative than you: I think that puzzling users > so that they ask questions on stack overflow is an outcome that should > be avoided if possible. I also think experience shows that ORG-NEWS is > missed by a significant fraction of users. That is a nice thought, at least in theory. I guess my worry is about the "costs" of implementing such practices. Perhaps we could ask people if they want to have the ORG-NEWS file displayed when a new version of Org is installed. :) > Besides, I am a programmer not a writer so I believe in the power of > code over prose :P I am not a programmer, so perhaps therein lies the difference. >> Customize-changed would bring up the changes to >> org-structure-template-alist, which mentions Org Tempo. > > Interesting. I didnʼt know about that function. I just tried M-x > customize-changed RET Org 9.0 RET. That gives an error; it seems to > only work based on emacs versions and not package versions. Thatʼs > unfortunate, it would have been nice if people who install org from ELPA > could use the function to keep up with org changes independently from > their emacs version. (In fact, I just sent this as a feature request to > the emacs bug tracker, #31383) I did not know that. Thanks. Rasmus -- Dobbelt-A ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-05 17:29 ` Rasmus 2018-05-06 20:02 ` Aaron Ecay @ 2018-05-08 6:52 ` Bastien 2018-05-21 14:19 ` Rasmus 1 sibling, 1 reply; 87+ messages in thread From: Bastien @ 2018-05-08 6:52 UTC (permalink / raw) To: Rasmus; +Cc: emacs-orgmode Hi Rasmus, Rasmus <rasmus@gmx.us> writes: > There’s tools to mark thinks as obsolete in Emacs should we need to. One problem is that those tools (I'm thinking of define-obsolote-*) are more developer-oriented than user-oriented. E.g. AFAIK there is no "tool" to tell a user that a command accepts a new argument. Or is there? >> One remaining decision to make is: what is the future of org-tempo? I am >> sympathetic to the idea that the best place for it eventually would be >> org-contrib or GNU ELPA, and not org core. > > We don’t have make that decision now, do we? No. For now I'd like to get back to your original "trigger" and continue to enhance the org-tempo code so that it allows to wrap regions around templates. -- Bastien ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-08 6:52 ` Bastien @ 2018-05-21 14:19 ` Rasmus 0 siblings, 0 replies; 87+ messages in thread From: Rasmus @ 2018-05-21 14:19 UTC (permalink / raw) To: bzg; +Cc: emacs-orgmode Hi, Bastien <bzg@gnu.org> writes: >>> One remaining decision to make is: what is the future of org-tempo? I am >>> sympathetic to the idea that the best place for it eventually would be >>> org-contrib or GNU ELPA, and not org core. >> >> We don’t have make that decision now, do we? > > No. For now I'd like to get back to your original "trigger" and > continue to enhance the org-tempo code so that it allows to wrap > regions around templates. How would that work? A snippet is at the beginning of the line? Also, if I have delete-selection-mode on it might not make sense to try and "save" region when expanding a tempo snippet. Rasmus -- Evidence suggests Snowden used a powerful tool called monospaced fonts ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 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-08 6:34 ` Bastien 2 siblings, 0 replies; 87+ messages in thread From: Bastien @ 2018-05-08 6:34 UTC (permalink / raw) To: Aaron Ecay; +Cc: Tim Cross, emacs-orgmode, Nicolas Goaziou, Rasmus Hi Aaron, Aaron Ecay <aaronecay@gmail.com> writes: > 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. I fully agree with the above. I will summarize what I suggest as the next move for this particular feature. Thanks, -- Bastien ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 13:22 ` Bastien 2018-04-29 17:40 ` Thomas S. Dye 2018-04-29 22:27 ` Tim Cross @ 2018-04-30 8:47 ` Eric S Fraga 2 siblings, 0 replies; 87+ messages in thread From: Eric S Fraga @ 2018-04-30 8:47 UTC (permalink / raw) To: Bastien; +Cc: emacs-orgmode, Nicolas Goaziou [-- Attachment #1: Type: text/plain, Size: 693 bytes --] On Sunday, 29 Apr 2018 at 15:22, Bastien wrote: [...] > But again, I might be wrong, I just don't want this to be a discussion > between us two :) The new system seems more powerful and works better for me as it doesn't conflict with predictive texting that also uses the TAB key. I'm am tending to side with the view put forward by Nicolas on this one: one well supported solution is better than 2. However, Emacs is infamous for having >n (with n large) solutions to any problem... So I don't have any fundamental problems with both being available per se so long as they do not conflict. My 2¢. -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.7-475-g3ffc7d [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 194 bytes --] ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 12:01 ` Nicolas Goaziou 2018-04-29 13:22 ` Bastien @ 2018-05-08 8:37 ` Bastien 1 sibling, 0 replies; 87+ messages in thread From: Bastien @ 2018-05-08 8:37 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: emacs-orgmode Hi Nicolas, Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > It seems nonsensical to let Org handle expansion templates. Not to me, because Org syntax include default structured templates. > Dedicated packages do it way better than what we provide, and the > task is really out of our scope. I think we are going in the right direction by reusing features from Emacs core. As long as tempo.el is in Emacs, it means to me that we are encouraged to use it in other core Emacs features like Org. -- Bastien ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 11:05 ` Bastien 2018-04-29 12:01 ` Nicolas Goaziou @ 2018-04-29 13:24 ` Christian Moe 2018-04-29 13:55 ` Charles Millar ` (3 subsequent siblings) 5 siblings, 0 replies; 87+ messages in thread From: Christian Moe @ 2018-04-29 13:24 UTC (permalink / raw) To: Bastien; +Cc: emacs-orgmode, Nicolas Goaziou So, user feedback: I'm fine with not enabling by default. I don't use any of these, but it sounds like the new default expansion mechanism Nicolas mentioned might suit me if I ever switch from my homemade insert-block function (which does prompts and regions). Yours, Christian Bastien writes: > Hi Nicolas, > > Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > >> You disagreed with me in the first place with commit 71ad7b1. It was my >> original intent to not load Org Tempo by default. > > Sorry if I missed the statement where you explicitely said you thought > org-tempo should not be enabled by default, I thought it was just an > oversight and I didn't realize I was in a disagreement with you when I > pushed this commit -- if I thought so, I'd write to you on the list to > raise the topic instead of forcing a change through a commit. > > Again, I may be wrong in thinking disabling this will cause trouble to > many users. Let's just take a moment to see what users think. > > Thanks, ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 11:05 ` Bastien 2018-04-29 12:01 ` Nicolas Goaziou 2018-04-29 13:24 ` Christian Moe @ 2018-04-29 13:55 ` Charles Millar 2018-04-29 19:08 ` Diego Zamboni ` (2 subsequent siblings) 5 siblings, 0 replies; 87+ messages in thread From: Charles Millar @ 2018-04-29 13:55 UTC (permalink / raw) To: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 1021 bytes --] Hi all, On 04/29/2018 07:05 AM, Bastien wrote: > Hi Nicolas, > > Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: Let's just take a moment to see what users think. I was aware of tempo.el and tempo from postings to the list. However It was not until I upgraded to version 9.1.12 from 9.1.11 that I realized that tempo was the default; I thought that it was optional. With 9.1.12 installed I could not open any of my org files because of the blocks that I added through the years to the org-structure-template-alist. I used the previous feature merely to insert blocks, which were not necessarily for coding; the first block I added was obtained from Dan Doherty, on this list, about six years ago and it had nothing to do with coding but to insert a debit and credit columns into a document. I will adapt if I must, but I suspect that there are other users such as I who merely used the feature to insert a block of text or something else other than code. Charlie Millar [-- Attachment #2: Type: text/html, Size: 1615 bytes --] ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 11:05 ` Bastien ` (2 preceding siblings ...) 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-01 11:57 ` Nick Helm 5 siblings, 2 replies; 87+ messages in thread From: Diego Zamboni @ 2018-04-29 19:08 UTC (permalink / raw) To: Bastien; +Cc: Diego Zamboni, emacs-orgmode, Nicolas Goaziou [-- Attachment #1: Type: text/plain, Size: 1230 bytes --] Hi, > On 29 Apr 2018, at 13:05, Bastien <bzg@gnu.org> wrote: > Again, I may be wrong in thinking disabling this will cause trouble to > many users. Let's just take a moment to see what users think. Here’s my 2 cents: I’ve only been using org-mode for a few months now, but almost from the beginning I learned about org-tempo and the “<s" expansions, so I got used to them. I find it very natural and quick to type. At some point it became necessary to add "(require org-tempo)" to my init file, which didn’t bother me. Since a few weeks ago (around 9.1.10-11, maybe?) the “<s" expansion seems a bit broken - if I try to use it in the middle of a file and there is a block of the same type further down in the file, then only the opening line of the block is inserted. So I’ve been using "C-c C-," more, which seems to work fine. I just now realized (thanks to Nicolas’ comment) that it works on regions, which is nice (I had been using "org-babel-demarcate-block” - “C-c C-v d” for that). So, to summarize: I don’t mind having to load org-tempo explicitly, but it wold be nice to make the change visible (maybe make ORG-NEWS more visible) and to fix the bug I mentioned. Best, —Diego [-- Attachment #2: Type: text/html, Size: 3151 bytes --] ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 19:08 ` Diego Zamboni @ 2018-04-29 20:30 ` Rasmus 2018-04-29 20:44 ` Bastien 1 sibling, 0 replies; 87+ messages in thread From: Rasmus @ 2018-04-29 20:30 UTC (permalink / raw) To: emacs-orgmode Hi, Diego Zamboni <diego@zzamboni.org> writes: > Since a few weeks ago (around 9.1.10-11, maybe?) the “<s" expansion > seems a bit broken - if I try to use it in the middle of a file and > there is a block of the same type further down in the file, then only > the opening line of the block is inserted. So I’ve been using "C-c > C-," more, which seems to work fine. I just now realized (thanks to > Nicolas’ comment) that it works on regions, which is nice (I had been > using "org-babel-demarcate-block” - “C-c C-v d” for that). Would it be possible to send a reproducible bug-report, starting from "emacs -q"? Thanks, Rasmus -- May contains speling mistake ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 19:08 ` Diego Zamboni 2018-04-29 20:30 ` Rasmus @ 2018-04-29 20:44 ` Bastien 1 sibling, 0 replies; 87+ messages in thread From: Bastien @ 2018-04-29 20:44 UTC (permalink / raw) To: Diego Zamboni; +Cc: emacs-orgmode, Nicolas Goaziou Hi Diego, thanks for your input. Zamboni <diego@zzamboni.org> writes: > So, to summarize: I don’t mind having to load org-tempo explicitly, > but it wold be nice to make the change visible (maybe make ORG-NEWS > more visible) and to fix the bug I mentioned. Can you give a recipe on how to reproduce the bug? And more details on your configuration (M-x org-version RET)? I cannot find a way to trigger a bug for this. Thanks! -- Bastien ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 11:05 ` Bastien ` (3 preceding siblings ...) 2018-04-29 19:08 ` Diego Zamboni @ 2018-04-29 23:32 ` Bernt Hansen 2018-05-02 20:24 ` Bernt Hansen 2018-05-01 11:57 ` Nick Helm 5 siblings, 1 reply; 87+ messages in thread From: Bernt Hansen @ 2018-04-29 23:32 UTC (permalink / raw) To: Bastien, Nicolas Goaziou; +Cc: emacs-orgmode, Rasmus Bastien <bzg@gnu.org> writes: > Hi Nicolas, > > Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > >> You disagreed with me in the first place with commit 71ad7b1. It was my >> original intent to not load Org Tempo by default. > > Sorry if I missed the statement where you explicitely said you thought > org-tempo should not be enabled by default, I thought it was just an > oversight and I didn't realize I was in a disagreement with you when I > pushed this commit -- if I thought so, I'd write to you on the list to > raise the topic instead of forcing a change through a commit. > > Again, I may be wrong in thinking disabling this will cause trouble to > many users. Let's just take a moment to see what users think. > > Thanks, Hi Bastien, Nicolas, Rasmus, and list! So here is my take on this. org-tempo is the reason I am here on master right now and participating in this conversation. I am not really for or against enabling org-tempo by default. If it's not enabled by default and a clear path is documented for how to achieve the same thing in ORG-NEWS using yasnippet or some other expansion system then that is perfectly okay with me. If I can't use <e and <s anymore I'll just have to retrain my fingers which have been using this for 10 years now -- it's doable it will just take me some time :) Right now using yasnippet is what I would be setting up if org-tempo was not enabled in my configuration. I just need a refresher on how to write my yasnippet templates since I haven't done that in years. If I rewrite the few templates I use all the time in yasnippet then I don't need this require for org-tempo in my configuration anymore (Thanks for creating org-tempo Rasmus!). I added it simply to restore the <e and <s expansions in the master branch and I don't really know what other capabilities it has. I agree with Nicholas that if it just works users don't have to put any thought or effort into learning anything new and thus they won't be contributing feedback on the new functions as they won't be aware of them or using them. When I switched from 8.3 to the latest maint branch a few weeks back I went through ORG-NEWS to deal with major errors I received on emacs startup from my existing 8.3 config. I admit I didn't read ORG-NEWS top to bottom for every change between the versions. I only addressed obvious failures at startup to see if I could overcome them quickly and easily since I wanted to get back to real work ASAP. <s and <e still worked in maint (but that was probably after it was enabled by default specifically in that branch). Then when I switched to the master branch at work to try things out the expansions didn't work. I use these all the time and simply switched back to maint immediately so as not to adversely impact productivity at work. It never occurred to me to go look in ORG-NEWS to see if this had changed -- I just assumed it was a bug -- until I caught up to the thread on the mailing list. I have no problem with switching to yasnippet or some other templating/expansion system to achieve the same (or better) result as I already enjoy in org-mode -- all I would need for that is clear instructions on how to achieve it. Writing yasnippet expansions will work just fine for me, I just need to create the templates -- I am already using yasnippet in my configuration. I wasn't aware of the new expansion system that Nicholas is referring to (and still don't know what it is or how/if I will be using it) -- I just need some time to review and play with it. Currently I prefer short key expansions without complicated keystrokes. I'm using abbrev mode to insert people's names from their initials quickly while taking meeting notes (like 'ibh' becomes 'Bernt Hansen') and <s and <e fit in nicely with my easy typing replacement in my workflows. If I have to slow down with complicated keystrokes I can't keep up with the details of meetings. How exactly they expand and who provides the functionality ultimately isn't important to me -- as long as they work :) Regards, Bernt ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 23:32 ` Bernt Hansen @ 2018-05-02 20:24 ` Bernt Hansen 2018-05-03 9:44 ` Carsten Dominik 0 siblings, 1 reply; 87+ messages in thread From: Bernt Hansen @ 2018-05-02 20:24 UTC (permalink / raw) To: Bastien; +Cc: emacs-orgmode, Rasmus, Nicolas Goaziou Bernt Hansen <bernt@norang.ca> writes: > I am not really for or against enabling org-tempo by default. If it's > not enabled by default and a clear path is documented for how to achieve > the same thing in ORG-NEWS using yasnippet or some other expansion > system then that is perfectly okay with me. If I can't use <e and <s > anymore I'll just have to retrain my fingers which have been using this > for 10 years now -- it's doable it will just take me some time :)) So I'm changing my vote :) I've disabled org-tempo and am in the process of learning to use C-c C-, instead of <s and <e and I like it a lot better already. It wraps selected regions in the e and s templates and works great! :) Thanks Nicolas! Regards, Bernt ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-02 20:24 ` Bernt Hansen @ 2018-05-03 9:44 ` Carsten Dominik 2018-05-03 13:30 ` William Denton 0 siblings, 1 reply; 87+ messages in thread From: Carsten Dominik @ 2018-05-03 9:44 UTC (permalink / raw) To: bernt; +Cc: Bastien, org-mode list, Nicolas Goaziou, Rasmus [-- Attachment #1: Type: text/plain, Size: 1103 bytes --] Dear all, after initial doubt about this issue, I am now siding with Nicolas on this one. I have started to use C-c C-, , and it works very well. In particular, as Bernt says, the wrapping makes a very big difference, I have always missed this. Carsten On Wed, May 2, 2018 at 10:26 PM Bernt Hansen <bernt@norang.ca> wrote: > Bernt Hansen <bernt@norang.ca> writes: > > > I am not really for or against enabling org-tempo by default. If it's > > not enabled by default and a clear path is documented for how to achieve > > the same thing in ORG-NEWS using yasnippet or some other expansion > > system then that is perfectly okay with me. If I can't use <e and <s > > anymore I'll just have to retrain my fingers which have been using this > > for 10 years now -- it's doable it will just take me some time :)) > > So I'm changing my vote :) > I've disabled org-tempo and am in the process of learning to use C-c C-, > instead of <s and <e and I like it a lot better already. > > It wraps selected regions in the e and s templates and works great! :) > > Thanks Nicolas! > > Regards, > Bernt > > [-- Attachment #2: Type: text/html, Size: 1587 bytes --] ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-03 9:44 ` Carsten Dominik @ 2018-05-03 13:30 ` William Denton 2018-05-04 7:34 ` Neil Jerram 0 siblings, 1 reply; 87+ messages in thread From: William Denton @ 2018-05-03 13:30 UTC (permalink / raw) To: org-mode list On 3 May 2018, Carsten Dominik wrote: > after initial doubt about this issue, I am now siding with Nicolas on this > one. I have started to use C-c C-, , and it works very well. In > particular, as Bernt says, the wrapping makes a very big difference, I have > always missed this. I feel the same. I'd set up ya-snippets to get the old behaviour, but I've been trying this and am going to switch over permanently. (That said, it might make sense to do this in version 10.) M-x three-cheers-for-org-mode, Bill -- William Denton :: Toronto, Canada --- Listening to Art: https://listeningtoart.org/ https://www.miskatonic.org/ --- GHG.EARTH: http://ghg.earth/ Caveat lector. --- STAPLR: http://staplr.org/ ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-03 13:30 ` William Denton @ 2018-05-04 7:34 ` Neil Jerram 2018-05-04 7:45 ` Bastien 0 siblings, 1 reply; 87+ messages in thread From: Neil Jerram @ 2018-05-04 7:34 UTC (permalink / raw) To: William Denton, org-mode list William Denton <wtd@pobox.com> writes: > On 3 May 2018, Carsten Dominik wrote: > >> after initial doubt about this issue, I am now siding with Nicolas on this >> one. I have started to use C-c C-, , and it works very well. In >> particular, as Bernt says, the wrapping makes a very big difference, I have >> always missed this. > > I feel the same. I'd set up ya-snippets to get the old behaviour, but I've been > trying this and am going to switch over permanently. (That said, it might make > sense to do this in version 10.) How can I see and try this famous C-c C-, ? I'm running: Org mode version 9.1.12 (9.1.12-1-g388254-elpa @ /home/neil/.emacs.d/elpa/org-20180430/) but apparently that is still not new enough: C-c C-, is undefined > M-x three-cheers-for-org-mode, Hip hip! Many thanks - Neil ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-04 7:34 ` Neil Jerram @ 2018-05-04 7:45 ` Bastien 2018-05-05 1:37 ` Samuel Wales 0 siblings, 1 reply; 87+ messages in thread From: Bastien @ 2018-05-04 7:45 UTC (permalink / raw) To: Neil Jerram; +Cc: William Denton, org-mode list Hi Neil, Neil Jerram <neil@ossau.homelinux.net> writes: > How can I see and try this famous C-c C-, ? I'm running: > > Org mode version 9.1.12 (9.1.12-1-g388254-elpa @ > /home/neil/.emacs.d/elpa/org-20180430/) The new structure template mechanism will be part of the next major Org release (9.2). You can test it by cloning the master branch of Org's repository. Check https://orgmode.org/manual/Installation.html#Installation HTH, -- Bastien ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-04 7:45 ` Bastien @ 2018-05-05 1:37 ` Samuel Wales 2018-05-05 2:16 ` Tim Cross 0 siblings, 1 reply; 87+ messages in thread From: Samuel Wales @ 2018-05-05 1:37 UTC (permalink / raw) To: Bastien; +Cc: William Denton, Neil Jerram, org-mode list is there a reason why the binding cannot be c-c '? On 5/4/18, Bastien <bzg@gnu.org> wrote: > Hi Neil, > > Neil Jerram <neil@ossau.homelinux.net> writes: > >> How can I see and try this famous C-c C-, ? I'm running: >> >> Org mode version 9.1.12 (9.1.12-1-g388254-elpa @ >> /home/neil/.emacs.d/elpa/org-20180430/) > > The new structure template mechanism will be part of the next major > Org release (9.2). You can test it by cloning the master branch of > Org's repository. > > Check https://orgmode.org/manual/Installation.html#Installation > > HTH, > > -- > Bastien > > -- The Kafka Pandemic: <http://thekafkapandemic.blogspot.com> The disease DOES progress. MANY people have died from it. And ANYBODY can get it at any time. "You’ve really gotta quit this and get moving, because this is murder by neglect." --- <http://www.meaction.net/2017/02/03/pwme-people-with-me-are-being-murdered-by-neglect>. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-05 1:37 ` Samuel Wales @ 2018-05-05 2:16 ` Tim Cross 2018-05-05 2:28 ` Samuel Wales 2018-05-05 17:33 ` Rasmus 0 siblings, 2 replies; 87+ messages in thread From: Tim Cross @ 2018-05-05 2:16 UTC (permalink / raw) To: Samuel Wales; +Cc: Bastien, William Denton, Neil Jerram, org-mode list won't that conflict with the key binding for block editing mode? Also, I think C-c , is possibly more in-line with other template/expansion commands in other modes. Of course, being emacs, anyone can change it to suit personal preferences! Samuel Wales <samologist@gmail.com> writes: > is there a reason why the binding cannot be c-c '? > > On 5/4/18, Bastien <bzg@gnu.org> wrote: >> Hi Neil, >> >> Neil Jerram <neil@ossau.homelinux.net> writes: >> >>> How can I see and try this famous C-c C-, ? I'm running: >>> >>> Org mode version 9.1.12 (9.1.12-1-g388254-elpa @ >>> /home/neil/.emacs.d/elpa/org-20180430/) >> >> The new structure template mechanism will be part of the next major >> Org release (9.2). You can test it by cloning the master branch of >> Org's repository. >> >> Check https://orgmode.org/manual/Installation.html#Installation >> >> HTH, >> >> -- >> Bastien >> >> -- Tim Cross ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-05 2:16 ` Tim Cross @ 2018-05-05 2:28 ` Samuel Wales 2018-05-05 2:37 ` Tim Cross 2018-05-05 17:33 ` Rasmus 1 sibling, 1 reply; 87+ messages in thread From: Samuel Wales @ 2018-05-05 2:28 UTC (permalink / raw) To: Tim Cross; +Cc: Bastien, William Denton, Neil Jerram, org-mode list if there is a block there, you probably don't want to create a block. if it is not there, you probably want to create one. was my thinking. incorrect? On 5/4/18, Tim Cross <theophilusx@gmail.com> wrote: > > won't that conflict with the key binding for block editing mode? > > Also, I think C-c , is possibly more in-line with other > template/expansion commands in other modes. > > Of course, being emacs, anyone can change it to suit personal > preferences! > > Samuel Wales <samologist@gmail.com> writes: > >> is there a reason why the binding cannot be c-c '? >> >> On 5/4/18, Bastien <bzg@gnu.org> wrote: >>> Hi Neil, >>> >>> Neil Jerram <neil@ossau.homelinux.net> writes: >>> >>>> How can I see and try this famous C-c C-, ? I'm running: >>>> >>>> Org mode version 9.1.12 (9.1.12-1-g388254-elpa @ >>>> /home/neil/.emacs.d/elpa/org-20180430/) >>> >>> The new structure template mechanism will be part of the next major >>> Org release (9.2). You can test it by cloning the master branch of >>> Org's repository. >>> >>> Check https://orgmode.org/manual/Installation.html#Installation >>> >>> HTH, >>> >>> -- >>> Bastien >>> >>> > > > -- > Tim Cross > -- The Kafka Pandemic: <http://thekafkapandemic.blogspot.com> The disease DOES progress. MANY people have died from it. And ANYBODY can get it at any time. "You’ve really gotta quit this and get moving, because this is murder by neglect." --- <http://www.meaction.net/2017/02/03/pwme-people-with-me-are-being-murdered-by-neglect>. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-05 2:28 ` Samuel Wales @ 2018-05-05 2:37 ` Tim Cross 2018-05-05 12:42 ` Nicolas Goaziou 0 siblings, 1 reply; 87+ messages in thread From: Tim Cross @ 2018-05-05 2:37 UTC (permalink / raw) To: Samuel Wales; +Cc: Bastien, William Denton, Neil Jerram, org-mode list I guess it is a balancing act. On one level, org's tendency to use 'smart' key bindings in which behaviour/action changes depending on context is convenient, but on the other hand, I suspect it makes things more complicated, which usually means harder to get right or maintain. The C-c , binding is in line with expansion/templates in other modes (at least in my configuration), so there is little cognitive overhead when I want to expand "something". Samuel Wales <samologist@gmail.com> writes: > if there is a block there, you probably don't want to create a block. > if it is not there, you probably want to create one. > > was my thinking. incorrect? > > On 5/4/18, Tim Cross <theophilusx@gmail.com> wrote: >> >> won't that conflict with the key binding for block editing mode? >> >> Also, I think C-c , is possibly more in-line with other >> template/expansion commands in other modes. >> >> Of course, being emacs, anyone can change it to suit personal >> preferences! >> >> Samuel Wales <samologist@gmail.com> writes: >> >>> is there a reason why the binding cannot be c-c '? >>> >>> On 5/4/18, Bastien <bzg@gnu.org> wrote: >>>> Hi Neil, >>>> >>>> Neil Jerram <neil@ossau.homelinux.net> writes: >>>> >>>>> How can I see and try this famous C-c C-, ? I'm running: >>>>> >>>>> Org mode version 9.1.12 (9.1.12-1-g388254-elpa @ >>>>> /home/neil/.emacs.d/elpa/org-20180430/) >>>> >>>> The new structure template mechanism will be part of the next major >>>> Org release (9.2). You can test it by cloning the master branch of >>>> Org's repository. >>>> >>>> Check https://orgmode.org/manual/Installation.html#Installation >>>> >>>> HTH, >>>> >>>> -- >>>> Bastien >>>> >>>> >> >> >> -- >> Tim Cross >> -- Tim Cross ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-05 2:37 ` Tim Cross @ 2018-05-05 12:42 ` Nicolas Goaziou 0 siblings, 0 replies; 87+ messages in thread From: Nicolas Goaziou @ 2018-05-05 12:42 UTC (permalink / raw) To: Tim Cross; +Cc: Bastien, William Denton, Neil Jerram, org-mode list Hello, Tim Cross <theophilusx@gmail.com> writes: > The C-c , binding is in line with expansion/templates in other modes (at > least in my configuration), so there is little cognitive overhead when I > want to expand "something". `C-c ,' is a keybinding reserved for minor modes. See (info "(elisp) Key Binding Conventions") We should avoid, if possible, to use it. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-05-05 2:16 ` Tim Cross 2018-05-05 2:28 ` Samuel Wales @ 2018-05-05 17:33 ` Rasmus 1 sibling, 0 replies; 87+ messages in thread From: Rasmus @ 2018-05-05 17:33 UTC (permalink / raw) To: emacs-orgmode Tim Cross <theophilusx@gmail.com> writes: > won't that conflict with the key binding for block editing mode? Isn’t that "C-’". Blocks are "C-c C-,". I used some program to scavenge for unused bindings in, I think, December last year and we discussed it on the list. I think the main contenders were "C-c C-." and "C-c C-," and the latter is a bit nicer on my keyboard layout... I might be have misunderstood something, if so I apologize. > Also, I think C-c , is possibly more in-line with other > template/expansion commands in other modes. Don’t know. Why? Rasmus -- Er du tosset for noge' lårt! ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 11:05 ` Bastien ` (4 preceding siblings ...) 2018-04-29 23:32 ` Bernt Hansen @ 2018-05-01 11:57 ` Nick Helm 5 siblings, 0 replies; 87+ messages in thread From: Nick Helm @ 2018-05-01 11:57 UTC (permalink / raw) To: emacs-orgmode On Sun, 29 Apr 2018 at 23:05:20 +1200, Bastien wrote: > I may be wrong in thinking disabling this will cause trouble to > many users. Let's just take a moment to see what users think. I vote to drop "<s" and adopt the new mechanism by default. "<s" always seemed a bit off to me. Convenient, yes, but rather counterintuitive. And besides, what is org doing in the templating business anyway? Doesn't this fall into the category of "basic infrastructure that Emacs should provide to all modes"? ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 10:50 ` Nicolas Goaziou 2018-04-29 11:05 ` Bastien @ 2018-04-29 20:25 ` Rasmus 2018-04-29 21:53 ` Nicolas Goaziou 1 sibling, 1 reply; 87+ messages in thread From: Rasmus @ 2018-04-29 20:25 UTC (permalink / raw) To: emacs-orgmode Hi, Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > We introduced a new expansion mechanism, recently bound to `C-c C-,'. > This mechanism is more in line with usual Org functions: it operates on > regions like, say, `org-insert-drawer'. It is an obvious default > expansion mechanism. > > If the big menu, we could however improve it with an "expert" UI, like > we already do for export and tags. Aside: At the moment key combinations are generated on the go (unless someone it was changed), so a full "expert-mode a la the export dispatcher" would likely not work. Of course, org-mks could be made nicer, as is obvious when compared to the export dispatcher. > Now, some users are used to "<s" constructs, and are not willing to > switch to that expansion mechanism. Fair enough. I first suggested to > use Yasnippets, which is powerful enough and easy to use. Some users > still didn't want to use that. Well. I suggested Tempo, but, admittedly, > out of the box, it is not really usable. Then Rasmus wrote Org Tempo. > > Even though Org Tempo is probably useful for a part of users, it is yet > another occurrence of NIH in Org mode. Instead of using already > available, and fitting, libraries for a task, we implement one. FWIW, I strongly disagree that Yasnippet is a suitable replacement. IMO it’s not at all intuitive. Why is using tempo NIH? > Also, it will probably prevent the default expansion mechanism to > receive feedback, and therefore, improvements (even though it is better > for basic uses) because users will not even notice the new mechanism if > the old one works out of the box. > IMO, Org Tempo should live outside of Org core, like many other > Org-related libraries. I disagree. > Some die-hard "<s" users might be annoyed if they > had to install an external library. So asking for a "(require > 'org-tempo)" was an acceptable compromise, until your disagreement. FWIW, I am indifferent to whether org-tempo is loaded by default or not as long as it’s included by default and documented in the manual. Rasmus -- May contains speling mistake ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 20:25 ` Rasmus @ 2018-04-29 21:53 ` Nicolas Goaziou 2018-05-02 9:03 ` Rasmus 0 siblings, 1 reply; 87+ messages in thread From: Nicolas Goaziou @ 2018-04-29 21:53 UTC (permalink / raw) To: Rasmus; +Cc: emacs-orgmode Hello, Rasmus <rasmus@gmx.us> writes: > FWIW, I strongly disagree that Yasnippet is a suitable replacement. IMO > it’s not at all intuitive. You must be kidding. Consider the following snippet: # key: <s # -- #+begin_src $1 $0 #+end_src In a buffer, "<s" and TAB lets me insert the language and possible header arguments, then another TAB puts point within the block. Note that by changing "$1" into "${1:emacs-lisp}", you can even default to emacs-lisp block if you use "<s" TAB TAB. No offense intended, but Yasnippet is more powerful and also more versatile than what we offer, since we stick to "<" prefix for historical reasons. > Why is using tempo NIH? Using Tempo is fine. But we're writing a template system on top of it, which is a different beast. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 21:53 ` Nicolas Goaziou @ 2018-05-02 9:03 ` Rasmus 0 siblings, 0 replies; 87+ messages in thread From: Rasmus @ 2018-05-02 9:03 UTC (permalink / raw) To: mail; +Cc: emacs-orgmode Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > Hello, > > Rasmus <rasmus@gmx.us> writes: > >> FWIW, I strongly disagree that Yasnippet is a suitable replacement. IMO >> it’s not at all intuitive. > > You must be kidding. Consider the following snippet: > > # key: <s > # -- > > #+begin_src $1 > $0 > #+end_src > > In a buffer, "<s" and TAB lets me insert the language and possible > header arguments, then another TAB puts point within the block. Especially the tab behavior is what "gets me" with yasnippet. It seems erratic. Some package that I use used to auto-load it a few years back and it created a horrible mess with weird highlights and the tab key not working as expected. I have not tried it for many years, but last time I used it I had a distinct distaste for its behavior. The syntax looks nice. > No offense intended, but Yasnippet is more powerful and also more > versatile than what we offer, since we stick to "<" prefix for > historical reasons. Perhaps what we offer is also more simple. >> Why is using tempo NIH? > > Using Tempo is fine. But we're writing a template system on top of it, > which is a different beast. I am not sure I would raise it to a "template system". At most a "block insertion system". Rasmus -- To err is human. To screw up 10⁶ times per second, you need a computer ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]") 2018-04-29 10:24 Bastien 2018-04-29 10:50 ` Nicolas Goaziou @ 2018-04-30 16:36 ` Steve Downey 1 sibling, 0 replies; 87+ messages in thread From: Steve Downey @ 2018-04-30 16:36 UTC (permalink / raw) To: Bastien; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 485 bytes --] Changing the UI to no longer work is a very non-emacsy thing to do. There's a lot of existing doc and tutorials explaining the org template system, as well as current users who have trained fingers. Breaking <s[tab] will be unpleasant. ELPA makes package upgrades much more transparent, which means users will not necessarily notice that Org is getting updated. And emacs has trained users that upgrading is harmless. Without intervention, emacs will behave the same as it did before. [-- Attachment #2: Type: text/html, Size: 521 bytes --] ^ permalink raw reply [flat|nested] 87+ messages in thread
end of thread, other threads:[~2018-05-21 14:35 UTC | newest] Thread overview: 87+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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).