[O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

[Bastien]

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?

[Nicolas Goaziou]

Hello,

Post by Bastien
You seem to disagree as you just disabled Org tempo in commit 4c13d0a

You disagreed with me in the first place with commit 71ad7b1. It was my
original intent to not load Org Tempo by default.

Post by Bastien
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,

[Bastien]

Hi Nicolas,

Post by Nicolas Goaziou
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,

[Nicolas Goaziou]

Post by Bastien
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,

[Bastien]

Hi Nicolas,

Post by Nicolas Goaziou

Post by Bastien
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.

Post by Nicolas Goaziou
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.

Post by Nicolas Goaziou
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 :)

[Thomas S. Dye]

Post by Bastien
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

[Bastien]

Hi Thomas,

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,

[Tim Cross]

Post by Bastien

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.

- ORG-NEWS is not in the ELPA and ELPAPLUS package for now;
- Do we want the whole ORG-NEWS or just the first section?
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?

[Bastien]

Hi Tim,

Post by Tim Cross
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

Post by Tim Cross
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!

[Tim Cross]

Post by Bastien
Hi Nicolas,

Post by Nicolas Goaziou

Post by Bastien
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.

Post by Nicolas Goaziou
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.

Post by Nicolas Goaziou
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

[Bastien]

Hi Tim,

thanks for your thorough and balanced feedback.

Post by Tim Cross
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.

Post by Tim Cross
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.

Post by Tim Cross
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-, :)

Post by Tim Cross
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!

[Nicolas Goaziou]

Hello,

Post by Bastien
- 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.

Post by Bastien
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,

[Kevin Foley]

Post by Bastien
- 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

Post by Bastien
Hello,

Post by Bastien
- 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.

Post by Bastien
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

[Kevin Foley]

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

[Rasmus]

Post by Kevin Foley
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

[Bernt Hansen]

Hi,

I think there is a typo in ORG-NEWS

Post by Bastien

Post by Tim Cross
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

[Rasmus]

Post by Bastien
Hi Tim,
thanks for your thorough and balanced feedback.

Post by Tim Cross
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...

Post by Bastien
...
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

[Aaron Ecay]

This post might be inappropriate. Click to display it.

[Eric S Fraga]

On Tuesday, 1 May 2018 at 16:49, Aaron Ecay wrote:

[...]

Post by Aaron Ecay
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.

[Rasmus Pank Roulund]

Post by Aaron Ecay
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.

Post by Aaron Ecay
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

[Aaron Ecay]

Hi Rasmus,

Post by Rasmus Pank Roulund

Post by Aaron Ecay
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).

[Rasmus]

Post by Aaron Ecay
Hi Rasmus,

Post by Rasmus Pank Roulund

Post by Aaron Ecay
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.

Post by Aaron Ecay
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

[Aaron Ecay]

Hi Rasmus,

Post by Rasmus
I don’t like it, I’m afraid.

Iʼm sorry to hear that.

Post by Rasmus
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.)

Post by Rasmus
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.

Post by Rasmus

Post by Aaron Ecay
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.

[Eric S Fraga]

On Sunday, 29 Apr 2018 at 15:22, Bastien wrote:

[...]

Post by Bastien
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¢.

[Christian Moe]

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

Post by Bastien
Hi Nicolas,

Post by Nicolas Goaziou
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,

[Charles Millar]

Hi all,

Post by Bastien
Hi Nicolas,

    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

[Diego Zamboni]

Hi,

Post by Bastien
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

[Rasmus]

Hi,

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

[Bastien]

Hi Diego,

thanks for your input.

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!

[Bernt Hansen]

Post by Bastien
Hi Nicolas,

Post by Nicolas Goaziou
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

[Bernt Hansen]

Post by Bernt Hansen
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

[Carsten Dominik]

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

Post by Bernt Hansen

Post by Bernt Hansen
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

[William Denton]

Post by Carsten Dominik
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/

[Neil Jerram]

Post by William Denton

Post by Carsten Dominik
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

Post by William Denton
M-x three-cheers-for-org-mode,

Hip hip!

Many thanks - Neil

[Bastien]

Hi Neil,

Post by Neil Jerram
/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,

[Samuel Wales]

is there a reason why the binding cannot be c-c '?

Post by Bastien
Hi Neil,

Post by Neil Jerram
/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]

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!

Post by Samuel Wales
is there a reason why the binding cannot be c-c '?

Post by Bastien
Hi Neil,

Post by Neil Jerram
/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

[Samuel Wales]

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?

Post by Tim Cross
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!

Post by Samuel Wales
is there a reason why the binding cannot be c-c '?

Post by Bastien
Hi Neil,

Post by Neil Jerram
/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]

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".

Post by Samuel Wales
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?

Post by Tim Cross
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!

Post by Samuel Wales
is there a reason why the binding cannot be c-c '?

Post by Bastien
Hi Neil,

Post by Neil Jerram
/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

[Nicolas Goaziou]

Hello,

Post by Tim Cross
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,

[Rasmus]

Post by Tim Cross
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.

Post by Tim Cross
Also, I think C-c , is possibly more in-line with other
template/expansion commands in other modes.

Don’t know. Why?

Rasmus

[Nick Helm]

Post by Bastien
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"?

[Rasmus]

Hi,

Post by Nicolas Goaziou
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.

Post by Nicolas Goaziou
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?

Post by Nicolas Goaziou
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.

Post by Nicolas Goaziou
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

[Nicolas Goaziou]

Hello,

Post by Rasmus
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.

Post by Rasmus
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,

[Rasmus]

Post by Nicolas Goaziou
Hello,

Post by Rasmus
FWIW, I strongly disagree that Yasnippet is a suitable replacement. IMO
it’s not at all intuitive.

# 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.

Post by Nicolas Goaziou
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.

Post by Nicolas Goaziou

Post by Rasmus
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

[Steve Downey]

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.

[Jon Snader]

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.

[Richard Lawrence]

Post by Jon Snader
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.

[Peter Dewey Ore]

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 <

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

[Michael Gauland]

Same here!

Post by Peter Dewey Ore
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
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

[Jon Snader]

Post by Richard Lawrence

Post by Jon Snader
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.

[Tim Cross]

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

Post by Jon Snader
I use the <s[TAB] mechanism all the time and /definitely/ want it

Post by Jon Snader
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.

[Cook, Malcolm]

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=***@gnu.org> On Behalf Of Tim Cross
Sent: Monday, April 30, 2018 5:25 PM
To: Jon Snader <***@irreal.org>
Cc: Bastien <***@gnu.org>; Org-mode <emacs-***@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 <***@irreal.org<mailto:***@irreal.org>> wrote:

Richard Lawrence <***@berkeley.edu<mailto:***@berkeley.edu>> writes:
Jon Snader <***@irreal.org<mailto:***@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.

[Jon Snader]

[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?

[Kaushal Modi]

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

[Alan Tyree]

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

Post by Charles Millar
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

[Christophe Schockaert]

Post by Alan Tyree
[...]
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

Post by Alan Tyree
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

Post by Charles Millar
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] <---------------<<<<

[Tim Cross]

[Snip]

Post by Tim Cross
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.

[Steve Downey]

Post by Tim Cross

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.

Post by Tim Cross

[Snip]

Post by Tim Cross
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

[Nicolas Goaziou]

Hello,

Post by Steve Downey
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,

[Aaron Ecay]

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:

[...]

Post by Nicolas Goaziou
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.


[...]

Post by Nicolas Goaziou
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.

[Rasmus]

Post by Aaron Ecay

Post by Nicolas Goaziou
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

[Aaron Ecay]

Hi Rasmus,

Post by Rasmus
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.

[Tim Cross]

Post by Aaron Ecay
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

[Rasmus]

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

[Cook, Malcolm]

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-
Sent: Tuesday, May 01, 2018 7:36 AM
Subject: Re: [O] [POLL] Should Org tempo be enabled by default? (expand
templates thru e.g. "<s[TAB]")
Hello,

Post by Steve Downey
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
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 ;)

[Rasmus]

Post by Nicolas Goaziou
Hello,

Post by Steve Downey
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

[Carsten Dominik]

Post by Rasmus

Post by Nicolas Goaziou
Hello,

Post by Steve Downey
Asking users to accept any breakage in the tool they use to get work

done

Post by Nicolas Goaziou

Post by Steve Downey
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

Post by Rasmus
Thanks,
Rasmus
--
When in doubt, do it!

[Adrian Bradd]

Post by Nicolas Goaziou
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].

Post by Nicolas Goaziou
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

[Josiah Schwab]

Post by Nicolas Goaziou
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