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

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

-- 
 Bastien

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

[Nicolas Goaziou]

Hello,

Bastien <bzg@gnu.org> writes:

> You seem to disagree as you just disabled Org tempo in commit 4c13d0a
> ("Do not load Org Tempo by default"), saying:

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

> I wonder what users on this list think, maybe I'm wrong.
>
> Should the old expansion mechanism "<s" be enabled by default?

Some history first.

We introduced a new expansion mechanism, recently bound to `C-c C-,'.
This mechanism is more in line with usual Org functions: it operates on
regions like, say, `org-insert-drawer'. It is an obvious default
expansion mechanism.

If the big menu, we could however improve it with an "expert" UI, like
we already do for export and tags.

Now, some users are used to "<s" constructs, and are not willing to
switch to that expansion mechanism. Fair enough. I first suggested to
use Yasnippets, which is powerful enough and easy to use. Some users
still didn't want to use that. Well. I suggested Tempo, but, admittedly,
out of the box, it is not really usable. Then Rasmus wrote Org Tempo.

Even though Org Tempo is probably useful for a part of users, it is yet
another occurrence of NIH in Org mode. Instead of using already
available, and fitting, libraries for a task, we implement one. Also, it
will probably prevent the default expansion mechanism to receive
feedback, and therefore, improvements (even though it is better for
basic uses) because users will not even notice the new mechanism if the
old one works out of the box.

IMO, Org Tempo should live outside of Org core, like many other
Org-related libraries. Some die-hard "<s" users might be annoyed if they
had to install an external library. So asking for a "(require
'org-tempo)" was an acceptable compromise, until your disagreement.

Regards,

-- 
Nicolas Goaziou

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

[Bastien]

Hi Nicolas,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

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

Sorry if I missed the statement where you explicitely said you thought
org-tempo should not be enabled by default, I thought it was just an
oversight and I didn't realize I was in a disagreement with you when I
pushed this commit -- if I thought so, I'd write to you on the list to
raise the topic instead of forcing a change through a commit.

Again, I may be wrong in thinking disabling this will cause trouble to
many users.  Let's just take a moment to see what users think.

Thanks,

-- 
 Bastien

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

[Nicolas Goaziou]

Bastien <bzg@gnu.org> writes:

> Again, I may be wrong in thinking disabling this will cause trouble to
> many users.  Let's just take a moment to see what users think.

It will case trouble during the time necessary to read ORG-NEWS
incompatible changes section or ask the mailing list, and then adding
(require 'org-tempo) to their configuration file.

It seems nonsensical to let Org handle expansion templates. Dedicated
packages do it way better than what we provide, and the task is really
out of our scope.

Worse, we would provide two different ways to expand blocks /by
default/.

Dying a little,

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

[Bastien]

Hi Nicolas,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Bastien <bzg@gnu.org> writes:
>
>> Again, I may be wrong in thinking disabling this will cause trouble to
>> many users.  Let's just take a moment to see what users think.
>
> It will case trouble during the time necessary to read ORG-NEWS
> incompatible changes section or ask the mailing list, and then adding
> (require 'org-tempo) to their configuration file.

I wish I'd be as optimistic as you are and assume every user reads
ORG-NEWS!  I seriously doubt a majority of users do.  Those installing
Org from ELPA cannot possibly know where to find ORG-NEWS, Org gives
no indication where it lives: IOW, it's not even because users are
lazy or what.

> It seems nonsensical to let Org handle expansion templates. Dedicated
> packages do it way better than what we provide, and the task is really
> out of our scope.

I can't remember anybody complaining Org's expansion mechanism.

> Worse, we would provide two different ways to expand blocks /by
> default/.

I see it differently.  You and Rasmus (and those participating to the
discussion) cleanly separated two functionalities: one is to *insert*
templates the other one is to *expand* them.

M-x org-insert-structure-template RET is good for discovery as it lets
users see what templates are availables and <[KEY][TAB] is good for
fast inline expansion.

Both complete each other IMO, and both deserve to be in Org's core.

But again, I might be wrong, I just don't want this to be a discussion
between us two :)

-- 
 Bastien

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

[Thomas S. Dye]

Bastien writes:

> I wish I'd be as optimistic as you are and assume every user 
> reads
> ORG-NEWS!  I seriously doubt a majority of users do.  Those 
> installing
> Org from ELPA cannot possibly know where to find ORG-NEWS, Org 
> gives
> no indication where it lives: IOW, it's not even because users 
> are
> lazy or what.

Would it be difficult to add an ORG-NEWS option to the 
Documentation section of the Org drop-down menu?  It's an 
interesting document.

Re: org tempo.  I really appreciate all the work done to preserve 
backward compatibility with the expansion mechanism.  I use Org 
for almost all my work nowadays and I hate to put my other work on 
hold to re-implement some Org mode functionality that I rely on.

That said, I didn't find the addition of (require org-tempo) to my 
configuration onerous.  I admire the kind of thinking that 
simplifies in order to make complexity possible.  Keep it up!

All the best,
Tom

--
Thomas S. Dye
http://www.tsdye.com

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

[Bastien]

Hi Thomas,

"Thomas S. Dye" <tsd@tsdye.com> writes:

> Would it be difficult to add an ORG-NEWS option to the Documentation
> section of the Org drop-down menu?  It's an interesting document.

Yes, I see why this how this could be useful, but there are problems:

- ORG-NEWS is not in the ELPA and ELPAPLUS package for now;

- Do we want the whole ORG-NEWS or just the first section?

- We could point to several web pages instead of the file:
  https://orgmode.org/Changes.html
  https://code.orgmode.org/bzg/org-mode/src/master/etc/ORG-NEWS

... I'm not sure what direction is best.  Ideas welcome!

> Re: org tempo.  I really appreciate all the work done to preserve
> backward compatibility with the expansion mechanism.  I use Org for
> almost all my work nowadays and I hate to put my other work on hold to
> re-implement some Org mode functionality that I rely on.
>
> That said, I didn't find the addition of (require org-tempo) to my
> configuration onerous.  I admire the kind of thinking that simplifies
> in order to make complexity possible.  Keep it up!

Thanks for your feedback,

-- 
 Bastien

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

[Tim Cross]

Bastien <bzg@gnu.org> writes:

> "Thomas S. Dye" <tsd@tsdye.com> writes:
>
>> Would it be difficult to add an ORG-NEWS option to the Documentation
>> section of the Org drop-down menu?  It's an interesting document.
>
> Yes, I see why this how this could be useful, but there are problems:
>
> - ORG-NEWS is not in the ELPA and ELPAPLUS package for now;
>
> - Do we want the whole ORG-NEWS or just the first section?
>
> - We could point to several web pages instead of the file:
>   https://orgmode.org/Changes.html
>   https://code.orgmode.org/bzg/org-mode/src/master/etc/ORG-NEWS
>
> ... I'm not sure what direction is best.  Ideas welcome!
>

Given that Emacs has eww, linking to a web page for NEWS from the menu
seems to be OK. However, I just noticed that org-plus-contrib and org
from the org repos do have NEWS.org, so for consistency, shouldn't they
be added to elpa's versions? 

-- 
Tim Cross

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

[Bastien]

Hi Tim,

Tim Cross <theophilusx@gmail.com> writes:

> Given that Emacs has eww, linking to a web page for NEWS from the menu
> seems to be OK.

I added a new menu entry "Org Browse News" which takes the user to
https://orgmode.org/Changes.html

> However, I just noticed that org-plus-contrib and org
> from the org repos do have NEWS.org, so for consistency, shouldn't they
> be added to elpa's versions?

Yes, we can do that as well.

Thanks!

-- 
 Bastien

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

[Tim Cross]

Bastien <bzg@gnu.org> writes:

> Hi Nicolas,
>
> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> Bastien <bzg@gnu.org> writes:
>>
>>> Again, I may be wrong in thinking disabling this will cause trouble to
>>> many users.  Let's just take a moment to see what users think.
>>
>> It will case trouble during the time necessary to read ORG-NEWS
>> incompatible changes section or ask the mailing list, and then adding
>> (require 'org-tempo) to their configuration file.
>
> I wish I'd be as optimistic as you are and assume every user reads
> ORG-NEWS!  I seriously doubt a majority of users do.  Those installing
> Org from ELPA cannot possibly know where to find ORG-NEWS, Org gives
> no indication where it lives: IOW, it's not even because users are
> lazy or what.
>
>> It seems nonsensical to let Org handle expansion templates. Dedicated
>> packages do it way better than what we provide, and the task is really
>> out of our scope.
>
> I can't remember anybody complaining Org's expansion mechanism.
>
>> Worse, we would provide two different ways to expand blocks /by
>> default/.
>
> I see it differently.  You and Rasmus (and those participating to the
> discussion) cleanly separated two functionalities: one is to *insert*
> templates the other one is to *expand* them.
>
> M-x org-insert-structure-template RET is good for discovery as it lets
> users see what templates are availables and <[KEY][TAB] is good for
> fast inline expansion.
>
> Both complete each other IMO, and both deserve to be in Org's core.
>
> But again, I might be wrong, I just don't want this to be a discussion
> between us two :)

The problem here is two competing objectives. I agree with Nicholas'
position that overall, org should not reproduce/re-invent/duplicate
functionality already provided by Emacs or well established Emacs
packages like ysnippets etc. On the other hand, Bastien's concern
regarding impact on users and basic change management concerns are very
valid.

There is no solution which will make everyone happy. However, as a long
term org user who hopes to continue using org for many more years, I
tend to come down on the side of whatever will make org easier to
maintain in the long term.

I think org itself should provide a very stable core and avoid
incorporating too many add on enhancements. It should be as stable as
possible to encourage others to develop and maintain such enhancements
and extensions. So while some of the changes Nicholas has proposed may
have some short term inconvenience, I agree with his approach and I
agree that if we enable org-tempo by default, we are unlikely to see
people switch and org-tempo will end up being another module needing to
be maintained as part of core.

While the switch will be a little inconvenient for me while I learn to
re-train my fingers, I think what I'm really doing is undoing a bad
habit learned because of the original '<s' expansion. I recall being a
little frustrated when I first started using org that I had to learn
another expansion key binding just for org mode. Consequently, I'm not
going to enable org-tempo, instead going for re-training of my fingers
to use the new C-c ' binding.

I agree with Thomas that adding an org-tempo require is an easy addition
for those who do not have the time/inclination to make the change
immediately. 

So in basic terms, I agree with Nicholas' position. Having said that, I
do feel he is being optimistic/pragmatic and Bastien's concerns are very
valid. I don't think people will read the NEWS file and I do expect we
will see numerous posts about org templates not working. However, this
should only be a short term bit of pain and I don't see it can be
avoided. The tempo solution will go a long way to reduce that pain for
those who don't have time to deal with the change right now. Most
reasonable people will understand why this change is occurring provided
we can make the rationale clear and easy to find, so information on the
org web site, to relevant mail lists and any other forum would be a good
idea.

Tim


--
Tim Cross

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

[Bastien]

Hi Tim,

thanks for your thorough and balanced feedback.

Tim Cross <theophilusx@gmail.com> writes:

> There is no solution which will make everyone happy. However, as a long
> term org user who hopes to continue using org for many more years, I
> tend to come down on the side of whatever will make org easier to
> maintain in the long term.

For org-tempo, Rasmus wrote it so I'm inclined to listen quite
carefully at his opinion.

> I think org itself should provide a very stable core and avoid
> incorporating too many add on enhancements.

I agree too.  But outline would have stayed something that nobody
cares about until Org came, enhancing the outline experience.  And I
guess tempo.el, something that RMS wrote in 1995, would stay unknown
until more users are exposed through it via org-tempo.el...

So I don't see org-tempo.el as something that adds extra burden: it
is a reasonable reuse of some core (underknown) Emacs functionality.

> Consequently, I'm not going to enable org-tempo, instead going for
> re-training of my fingers to use the new C-c ' binding.

You certainly mean C-c C-,  :)

> So in basic terms, I agree with Nicholas' position. Having said that, I
> do feel he is being optimistic/pragmatic and Bastien's concerns are very
> valid.

To give some context: I've run a few Emacs friendly workshops in Paris
(France) since the last few months.  French readers can check them
here: https://www.emacs-doctor.com/emacs-paris-user-group/

All the discussions have been really eye-opening to me in terms of
usability.  I could not believe Emacs users with 10 years of Emacs-fu
would not know text-scale-increase, or M-<left/right> in Org's table,
or whatever.  They could not believe I was ignoring X, Y, Z.  And
*many* of them were so frustrated with Org's installation experience
and some "missing" features from one version to another... hearing
these complaints face to face face something.

Yes, from an individual point of view, adding (require 'org-tempo) is
nothing but I've tangible feedback of the pain such change can induce
for other users.

Here is what the experience can look like:

- Upgrading Emacs or Org (hurray!!)
- Trying to hit <s as usual one month after the upgrade
- Thinking your stupid
- Bisecting your configuration file to see if something changed
- Trying to remember to name of the command for <[key][tab]
- Not finding the name of the command
- Thinking your stupid
- Remembering you upgraded Org
- Not remembering whether you updated Org or Emacs or both
- Guessing it was just Org
- Running M-x org-version RET
- Looking for the email annoncement of 9.2
- Finding a one-liner saying "Enjoy!" (#ðßðđłßðđ!!)
- Remembering there is an orgmode.org website
- Feeling a bit annoyed by the 7 years old cheesy design
- Finding the "See the release note" after three minutes
- Adding a TODO task "Read Org's release notes..."
- Reading them and not remembering what you're looking for
- Thinking your stupid
- Realizing you're looking for why <sTAB is gone
- Wondering how to call <sTAB: completion? expansion? extension?
- Finding entries in ORG-NEWS a bit boring to read (youth is gone)
- Not being entirely sure to understand what it says as english
  is not your your mother tongue (happens to the best of us!)
- Guessing through the lines that you need (require 'org-tempo)
- Wondering whether you'll learn salsa by adding this (tempo??)
- Thinking your stupid
- Testing and celebrating <sTAB is back
- WONDERING WHY YOU HAD TO DO ALL THIS
- Remembering the years when such victories boosted your mood
- Feeling you're now too old for this
- Or perhaps you're just stupid
- Anyway, it works now!
- Adding ;;;;;;;;;;;;;;;;;;;;;;;;; on top of (require 'org-tempo)
  to make sure you never delete it by accident.

...

Was it a boring list to read?  Even more boring to live.

In fact, I'm inclined to ask the real question: if org-tempo is on by
default, who will have good reasons to turn it off and why?

Good night all!

-- 
 Bastien

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

[Nicolas Goaziou]

Hello,

Bastien <bzg@gnu.org> writes:

> Here is what the experience can look like:
>
> - Upgrading Emacs or Org (hurray!!)
> - Trying to hit <s as usual one month after the upgrade
> - Thinking your stupid

[...]

I have an issue with this argument: it can be opposed to virtually any
backward-incompatible change we make. There are actually 10 such changes
in Org 9.2. Would it makes sense to remove them because some users,
unfortunately, will encounter a workflow break upon updating Org?

I totally agree this is an issue, yet, we have to move forward. We can
make UX consistent across releases, but we cannot guarantee 100%
compatibility at each step. As a data point, I don't know any software
that preserves the exact same UX after each release -- Firefox, Gnome,
I'm looking at you! There are unavoidable gotchas. This just means Org
is still vivid.

> In fact, I'm inclined to ask the real question: if org-tempo is on by
> default, who will have good reasons to turn it off and why?

This is one problem: only a few will have a reason (good or bad, who
cares?) to turn it off, e.g., because expansion gets in the way with
other templating systems. Possibly even fewer will actually turn it off.
As a consequence, the vast majority of users will keep using "<s" -- and
put maintenance burden on us -- instead of trying, and improving
something else. Inertia...

I already stated the following, sorry for re-iterating. Marking a region
and wrapping it in some environment is a basic operation Org is expected
to provide. We already did with `org-emphasize'. Implementing
programmable templates, even though we are re-using what Emacs ships
with, is another story.

Org Tempo is a nice tool. I'm not questioning this. It is also almost
100% compatible with previous feature. Yet, it competes with external
Emacs libraries, as capable as itself. Since it is not a feature
mandatory in Org, why forcing it onto the users? I'm inclined to think
we shouldn't.

Regards,

-- 
Nicolas Goaziou                                                0x80A93738

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

[Kevin Foley]

[-- Attachment #1: Type: text/plain, Size: 3380 bytes --]

Bastien <bzg@gnu.org> writes:

> Here is what the experience can look like:
>
> - Upgrading Emacs or Org (hurray!!)
> - Trying to hit <s as usual one month after the upgrade
> - Thinking your stupid

[...]

I have to admit that Bastien's list describes my experience almost
perfectly.  It look me a long time to figure out something that in the end
seemed very simple.  At the time I wasn't familiar with the NEWS file and
it didn't come up in any of my online searches.  It also didn't help that
site still documented the old behavior (and apparently still does
https://orgmode.org/manual/Easy-templates.html).

After reading Nicolas' points, I see the argument for moving people away
from org-tempo, actually I'm very excited to start using yasnippet. I've
been putting off incorporating it into my workflow for a while but this
thread has finally convinced me to start.

However, I do think the transition could be made a lot smoother for new
users.  The biggest step would be updating the easy-templates page to let
users know they now need to use org-tempo and should consider alternatives
such as yasnippet for more functionality.

Regards,
Kevin

On Mon, Apr 30, 2018 at 6:29 AM Nicolas Goaziou <mail@nicolasgoaziou.fr>
wrote:

> Hello,
>
> Bastien <bzg@gnu.org> writes:
>
> > Here is what the experience can look like:
> >
> > - Upgrading Emacs or Org (hurray!!)
> > - Trying to hit <s as usual one month after the upgrade
> > - Thinking your stupid
>
> [...]
>
> I have an issue with this argument: it can be opposed to virtually any
> backward-incompatible change we make. There are actually 10 such changes
> in Org 9.2. Would it makes sense to remove them because some users,
> unfortunately, will encounter a workflow break upon updating Org?
>
> I totally agree this is an issue, yet, we have to move forward. We can
> make UX consistent across releases, but we cannot guarantee 100%
> compatibility at each step. As a data point, I don't know any software
> that preserves the exact same UX after each release -- Firefox, Gnome,
> I'm looking at you! There are unavoidable gotchas. This just means Org
> is still vivid.
>
> > In fact, I'm inclined to ask the real question: if org-tempo is on by
> > default, who will have good reasons to turn it off and why?
>
> This is one problem: only a few will have a reason (good or bad, who
> cares?) to turn it off, e.g., because expansion gets in the way with
> other templating systems. Possibly even fewer will actually turn it off.
> As a consequence, the vast majority of users will keep using "<s" -- and
> put maintenance burden on us -- instead of trying, and improving
> something else. Inertia...
>
> I already stated the following, sorry for re-iterating. Marking a region
> and wrapping it in some environment is a basic operation Org is expected
> to provide. We already did with `org-emphasize'. Implementing
> programmable templates, even though we are re-using what Emacs ships
> with, is another story.
>
> Org Tempo is a nice tool. I'm not questioning this. It is also almost
> 100% compatible with previous feature. Yet, it competes with external
> Emacs libraries, as capable as itself. Since it is not a feature
> mandatory in Org, why forcing it onto the users? I'm inclined to think
> we shouldn't.
>
> Regards,
>
> --
> Nicolas Goaziou                                                0x80A93738
>
>

[-- Attachment #2: Type: text/html, Size: 13893 bytes --]

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

[Kevin Foley]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

I should add that one issue with org-tempo is it doesn't seem to be
backwards compatible with old templates.  For example packages such as
ob-sql-mode and org-reveal have easy templates based on the old format such
as :

    (add-to-list 'org-structure-template-alist
                  `(,org-babel-sql-mode-template-selector
                    "#+BEGIN_SRC sql-mode ?\n\n#+END_SRC"
                    "#+BEGIN_SRC sql-mode ?\n\n#+END_SRC"))

https://github.com/nikclayton/ob-sql-mode/blob/8d36d312bec4a742bec8890373948a888cac18de/ob-sql-mode.el#L187

This causes the cryptic error "File mode specification error: (error Format
specifier doesn’t match argument type)" when trying to load org-mode which
took me ages to figure out and could potentially turn someone new to
org-mode/emacs off forever.

I think this would be a good reason to not enable org-tempo at least for
the time being until either it can handle templates in the old format, or
produces a less cryptic error for users.

Regards,
Kevin

[-- Attachment #2: Type: text/html, Size: 1402 bytes --]

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

[Rasmus]

Kevin Foley <kfoley15@gmail.com> writes:

> Bastien <bzg@gnu.org> writes:
>
> I have to admit that Bastien's list describes my experience almost
> perfectly.  It look me a long time to figure out something that in the end
> seemed very simple.  At the time I wasn't familiar with the NEWS file and
> it didn't come up in any of my online searches.  It also didn't help that
> site still documented the old behavior (and apparently still does
> https://orgmode.org/manual/Easy-templates.html).

AFAIK the maint manual is published online.

Rasmus

-- 
The right to be left alone is a human right

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

[Bernt Hansen]

Hi,

I think there is a typo in ORG-NEWS


Bastien <bzg@gnu.org> writes:

>
> Tim Cross <theophilusx@gmail.com> writes:
>
>
>> Consequently, I'm not going to enable org-tempo, instead going for
>> re-training of my fingers to use the new C-c ' binding.
>
> You certainly mean C-c C-,  :)
>

--------------------------------------------------------------------------------
*** Change in the structure template expansion

Org 9.2 comes with a new template expansion mechanism, combining
~org-insert-structure-template~ bound to ~C-c C-'~.
--------------------------------------------------------------------------------

Shouldn't this be ~C-c C-,~  ?

Thanks,
Bernt

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

[Bastien]

Hi Bernt,

Bernt Hansen <bernt@norang.ca> writes:

> --------------------------------------------------------------------------------
> *** Change in the structure template expansion
>
> Org 9.2 comes with a new template expansion mechanism, combining
> ~org-insert-structure-template~ bound to ~C-c C-'~.
> --------------------------------------------------------------------------------
>
> Shouldn't this be ~C-c C-,~  ?

Indeed, thanks - Nicolas fixed it yesterday.

Best,

-- 
 Bastien

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

[Rasmus]

Bastien <bzg@gnu.org> writes:

> Hi Tim,
>
> thanks for your thorough and balanced feedback.
>
> Tim Cross <theophilusx@gmail.com> writes:
>
>> There is no solution which will make everyone happy. However, as a long
>> term org user who hopes to continue using org for many more years, I
>> tend to come down on the side of whatever will make org easier to
>> maintain in the long term.
>
> For org-tempo, Rasmus wrote it so I'm inclined to listen quite
> carefully at his opinion.

Please don’t.  I have not really made any policy decisions of sort.  I
only missed "<s" once it was cleaned away, and I only "improved/changed"
"C-c C-," to better suit my taste.  I am not a designer, I just type on my
keyboard until it "stuff" works again...

Anyhow, my general opinion on these matters is that I wouldn’t want to
remove any batteries.  I like included batteries...

> ... 
> In fact, I'm inclined to ask the real question: if org-tempo is on by
> default, who will have good reasons to turn it off and why?

I certainly won’t be :)

Rasmus

-- 
However beautiful the theory, one should occasionally look at the evidence

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

[Bastien]

Hi Rasmus,

Rasmus <rasmus@gmx.us> writes:

>> For org-tempo, Rasmus wrote it so I'm inclined to listen quite
>> carefully at his opinion.
>
> Please don’t.

Done :)

> I have not really made any policy decisions of sort.  I only missed
> "<s" once it was cleaned away, and I only "improved/changed" "C-c
> C-," to better suit my taste.  I am not a designer, I just type on
> my keyboard until it "stuff" works again...

I'm glad you triggered this enhancement, so *thanks* ! And I'm glad
Nicolas and others helped you polish it.  We just need ato polish it
a bit more, and it's good to have Aaron hacking around.

-- 
 Bastien

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

[Aaron Ecay]

[-- Attachment #1: Type: text/plain, Size: 4482 bytes --]

2018ko apirilak 29an, Tim Cross-ek idatzi zuen:

[...]

> I think org itself should provide a very stable core and avoid
> incorporating too many add on enhancements. It should be as stable as
> possible to encourage others to develop and maintain such enhancements
> and extensions. 

As someone who has worked (in a small way) on orgʼs development, I
certainly agree with the above sentiment.  Org is a many-headed
hydra, and decreasing its surface area makes for a better org (since
development efforts can be concentrated) as well as a better overall
user experience (because users can rely on packages, like in this
case yasnippet, that are better at doing something that Org tried to
do).

On the other hand, as an org user breaking changes are inconvenient.  I
have the impression that I can keep up with using org-mode only because
I follow the development list.  Whatʼs much worse, I feel like I should
not advocate the use of org-mode to my colleagues (who are often quite
computer-literate but value long-term stability of software they use),
basically because of the potential problems Bastien listed in his
message.

This situation is also inconvenient for developers...I have in mind a
change several years ago to the #+begin_src lines for shell code.  We
changed from #+begin_src shell to #+begin_src sh (or vice versa, I
canʼt remember precisely).  The result was that “bug” reports trickled
in for over a year, all of which had to be answered with the advice to
change to the new specification.  At the time I paid close attention to
babel-related bug reports because I was working on that code a lot.
Answering these reports (or even just reading them to see that they had
been answered by someone else) took away from my opportunity to do
(what I saw as) interesting things with orgʼs code.  I can only imagine
that for ML subscribers who were not as interested in babel bugs as I
was, the distraction could only have been worse.

As a general (idealized) principle, I think user-visible changes should
be phased in over at least one org major version.  I have no problem
with “intrusive” deprecation warnings, but abrupt changes in behavior
should be avoided.

Hereʼs what I imagine that could look like in the org-tempo case:

For org 9.X:
- Introduce the new functions and machinery for org-tempo as well as the
  new C-c C-, keybinding
- Enable org-tempo by default
- Show a user warning whenever a “<X” style template is being expanded,
  saying that this feature will go away in the next major version and to
  keep it, users should add “(require 'org-tempo)” to their .emacs
- Arrange matters so that users who take this step will not receive
  further warnings when expanding <X (this might require changing the
  activation trigger of org-tempo from a library to some other
  mechanism, see below)

For Org 10:
- No longer enable org-tempo by default
- Remove the logic for the deprecation warning

I would also question the decision to change the format of
org-structure-template-alist.  That has caused some errors (in the sense
of calls to the elisp ‘error’ function) for me because a third
party-library (ox-reveal) still uses the old format.  The change also
seems orthogonal to the switch from <X to C-c C-, expansion mechanism.
If itʼs really deemed to be important, I would suggest:

For org 9.X:
- Correctly handle alist keys in both new and old formats
- Show a deprecation warning if any old format keys are found in the
  alist

For Org 10:
- Remove the code to handle old-style keys and the deprecation warning.

Iʼm only too aware that this approach would increase the complexity
of developing new features, both in terms of code and needing to
coordinate addition/removal of bits of compatibility code across
multiple org versions.  It also requires some additional mental
effort since the deprecation path to follow is slightly different in
each case.  But I think this strikes a necessary balance between the
extremes of “UX must never change” and “UX can be revised at any
point”.

Finally, irrespective of which options are chosen, I think that org-tempo
would be better implemented in terms of a minor mode.  This would allow
it to be autoloaded, turned on/off for different buffer(s) in an emacs
session, and avoid duplicating the logic for activating global minor
modes.  Patch attached.

-- 
Aaron Ecay

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Use-minor-mode-machinery-for-org-tempo.patch --]
[-- Type: text/x-patch, Size: 1767 bytes --]

From 012f8d0b71c76f5d255af6bdaeb2d9c83a47cf85 Mon Sep 17 00:00:00 2001
From: Aaron Ecay <aaronecay@gmail.com>
Date: Tue, 1 May 2018 15:32:36 +0100
Subject: [PATCH] Use minor-mode machinery for org-tempo

* lisp/org-tempo.el (org-tempo-mode):
(org-tempo-global-mode): New minor modes.
(org-tempo-mode--activate-in-buffer): New function.
---
 lisp/org-tempo.el | 33 ++++++++++++++++++++++-----------
 1 file changed, 22 insertions(+), 11 deletions(-)

diff --git a/lisp/org-tempo.el b/lisp/org-tempo.el
index e1268b893..2feed24dc 100644
--- a/lisp/org-tempo.el
+++ b/lisp/org-tempo.el
@@ -170,17 +170,28 @@ didn't succeed."
 		       'org-tempo-tags)
 
 \f
-;;; Setup of Org Tempo
-;;
-;; Org Tempo is set up with each new Org buffer and potentially in the
-;; current Org buffer.
-
-(add-hook 'org-mode-hook 'org-tempo-setup)
-(add-hook 'org-tab-before-tab-emulation-hook 'org-tempo-complete-tag)
-
-;; Enable Org Tempo in all open Org buffers.
-(dolist (b (org-buffer-list 'files))
-  (with-current-buffer b (org-tempo-setup)))
+;;; Org Tempo minor mode
+
+;;;###autoload
+(define-minor-mode org-tempo-mode
+  "Expand \"<X\" style templates in org-mode buffers.
+
+See `org-tempo-keywords-alist' for more information on how
+templates are defined."
+  :lighter " tempo"
+  (if org-tempo-mode
+      (progn
+	(org-tempo-setup)
+	(add-hook 'org-tab-before-tab-emulation-hook #'org-tempo-complete-tag nil 'local))
+    (remove-hook 'org-tab-before-tab-emulation-hook #'org-tempo-complete-tag 'local)))
+
+(defun org-tempo-mode--activate-in-buffer ()
+  (when (derived-mode-p 'org-mode)
+    (org-tempo-mode 1)))
+
+;;;###autoload
+(define-global-minor-mode org-tempo-global-mode org-tempo-mode
+  org-tempo-mode--activate-in-buffer)
 
 (provide 'org-tempo)
 
-- 
2.17.0

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

[Eric S Fraga]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

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

[...]

> On the other hand, as an org user breaking changes are inconvenient.  

We should be clear that there are two different kinds of changes and
your post had references to both types:

1. changes to the user interface, e.g. what is being proposed here.
2. changes to the actual structure of org files, e.g. begin_latex
   becoming begin_export latex.

The first are inconvenient but usually (?) only for a short period of
time until finger memory has adapted.  The second can be much more
serious, leading to impact over quite a period of time, especially for
those that have accumulated many org files over years.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-474-g92785f

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

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

[Rasmus Pank Roulund]

Aaron Ecay <aaronecay@gmail.com> writes:

> I would also question the decision to change the format of
> org-structure-template-alist.  That has caused some errors (in the sense
> of calls to the elisp ‘error’ function) for me because a third
> party-library (ox-reveal) still uses the old format.  The change also
> seems orthogonal to the switch from <X to C-c C-, expansion mechanism.

The work on org-tempo and C-c C-, took the change of
org-structure-template-alist as a given.

> Finally, irrespective of which options are chosen, I think that org-tempo
> would be better implemented in terms of a minor mode.  This would allow
> it to be autoloaded, turned on/off for different buffer(s) in an emacs
> session, and avoid duplicating the logic for activating global minor
> modes.  Patch attached.

I agree.

Rasmus

-- 
The right to be left alone is a human right

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

[Aaron Ecay]

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

Hi Rasmus,

2018ko maiatzak 2an, Rasmus Pank Roulund-ek idatzi zuen:
>> Finally, irrespective of which options are chosen, I think that org-tempo
>> would be better implemented in terms of a minor mode.  This would allow
>> it to be autoloaded, turned on/off for different buffer(s) in an emacs
>> session, and avoid duplicating the logic for activating global minor
>> modes.  Patch attached.
> 
> I agree.

OK, thatʼs good to know.  Iʼve held off on any pushing of the patch to
master until everything is worked out.  In the meantime, Iʼve put it in
a branch “org-tempo”.

I also added a second commit to that branch which implements my vision
of the upgrade path (deprecation warnings, etc.)  For convenience, that
patch is also attached to this email.

One remaining decision to make is: what is the future of org-tempo?  I am
sympathetic to the idea that the best place for it eventually would be
org-contrib or GNU ELPA, and not org core.  If that is decided now, then
we can include that information in the upgrade message (i.e. that users
who opt in to org-tempo will eventually have to install it specifically).

-- 
Aaron Ecay

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0002-Add-compatibility-code-to-org-tempo.patch --]
[-- Type: text/x-patch, Size: 2857 bytes --]

From 414503d59b2129c24e95e1e57b54d5662a17308b Mon Sep 17 00:00:00 2001
From: Aaron Ecay <aaronecay@gmail.com>
Date: Wed, 2 May 2018 17:48:18 +0100
Subject: [PATCH 2/2] Add compatibility code to org-tempo

This will warn users of <X style templates and prompt them to update
their .emacs if they want to continue using the feature.
---
 lisp/org-tempo.el | 40 +++++++++++++++++++++++++++++++++++++++-
 lisp/org.el       |  6 ++++++
 2 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/lisp/org-tempo.el b/lisp/org-tempo.el
index 2feed24dc..9923fe769 100644
--- a/lisp/org-tempo.el
+++ b/lisp/org-tempo.el
@@ -40,7 +40,6 @@
 
 (require 'tempo)
 (require 'cl-lib)
-(require 'org)
 
 (defvar org-structure-template-alist)
 
@@ -193,6 +192,45 @@ templates are defined."
 (define-global-minor-mode org-tempo-global-mode org-tempo-mode
   org-tempo-mode--activate-in-buffer)
 
+\f
+;;; Compatibility code
+
+;;; The code in this section can be removed in the next major release
+;;; after org-tempo was released (currently projected to land in Org
+;;; 9.2, therefore removal after Org 10).  At that time, the code
+;;; activating org-tempo-global-mode should also be removed from
+;;; org.el, and (require 'org) should be added to the top of this
+;;; file.
+
+(defvar org-tempo--user-activated nil
+  "This will be set to t when we detect that the user has
+activated org-tempo in their .emacs.")
+
+(advice-add 'org-tempo-global-mode :after
+	    (lambda (&rest _)
+	      (setq org-tempo--user-activated t)))
+
+;;; TODO: should we also try to detect the case when the user adds
+;;; org-tempo-mode to org-mode-hook?
+
+(advice-add 'org-tempo-complete-tag :after
+	    (lambda (&rest _)
+	      (unless org-tempo--user-activated
+		(org-display-warning
+		 (substitute-command-keys "It looks like you have \
+expanded a <X style structure template.
+
+That feature will be removed from Org in the next major release.
+If you would like to continue using it, you should
+add `(org-tempo-global-mode 1)' to your emacs initialization
+file (which will also disable this warning message).
+\\<org-mode-map>
+Alternatively, you may wish to use the new template expansion
+facility `org-insert-structure-template', which is bound to
+\\[org-insert-structure-template] in org-mode buffers.")))))
+
+\f
+
 (provide 'org-tempo)
 
 ;;; org-tempo.el ends here
diff --git a/lisp/org.el b/lisp/org.el
index 0b8e62357..c67c8d2c5 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -23582,6 +23582,12 @@ when non-nil, is a regexp matching keywords names."
 	  (lambda () (add-hook 'change-major-mode-hook
 			       'org-show-all 'append 'local)))
 
+;; For compatibility; remove in Org 10
+(require 'org-tempo)
+(defvar org-tempo--user-activated)
+(let (org-tempo--user-activated)
+  (org-tempo-global-mode 1))
+
 (provide 'org)
 
 (run-hooks 'org-load-hook)
-- 
2.17.0

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

[Rasmus]

Aaron Ecay <aaronecay@gmail.com> writes:

> Hi Rasmus,
>
> 2018ko maiatzak 2an, Rasmus Pank Roulund-ek idatzi zuen:
>>> Finally, irrespective of which options are chosen, I think that org-tempo
>>> would be better implemented in terms of a minor mode.  This would allow
>>> it to be autoloaded, turned on/off for different buffer(s) in an emacs
>>> session, and avoid duplicating the logic for activating global minor
>>> modes.  Patch attached.
>> 
>> I agree.
>
> OK, thatʼs good to know.  Iʼve held off on any pushing of the patch to
> master until everything is worked out.  In the meantime, Iʼve put it in
> a branch “org-tempo”.
>
> I also added a second commit to that branch which implements my vision
> of the upgrade path (deprecation warnings, etc.)  For convenience, that
> patch is also attached to this email.

I don’t like it, I’m afraid.  It’s a bit nagging.  There’s tools to mark
thinks as obsolete in Emacs should we need to.

> One remaining decision to make is: what is the future of org-tempo?  I am
> sympathetic to the idea that the best place for it eventually would be
> org-contrib or GNU ELPA, and not org core.

We don’t have make that decision now, do we?

Rasmus

-- 
This message is brought to you by the department of redundant departments

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

[Aaron Ecay]

Hi Rasmus,

2018ko maiatzak 5an, Rasmus-ek idatzi zuen:

> I don’t like it, I’m afraid.  

Iʼm sorry to hear that.

> It’s a bit nagging.

I wouldnʼt call it nagging.  The user presses “<s[TAB]” expecting
something special to happen.  The status quo is that nothing at all
happens.  My proposal is to make something special happen.  Itʼs
different than what the user expected, but it informs them of what has
changed and how to get the old behavior back if they want.

Note that the only circumstance when the “nagging” happens is when a
user presses “<s[TAB]”, and it goes away when either they add
“(org-tempo-global-mode)” to their .emacs or learn a new habit of
pressing C-c C-, instead of <s[TAB]

(We could make the warning appear only once per emacs session, if that
seems like a better balance.)

(The patch I posted on the mailing list had a bug, which would trigger
the warning more often than it should be.  If you installed and tested
the patch from my email message, you would have seen that bug.  I pushed
a followup commit to the org-tempo branch in the repo that fixes the
bug.)

> There’s tools to mark thinks as obsolete in Emacs should we need to.

There are tools to mark functions and variables obsolete when they are
used in elisp code.  There is no way of warning a user about non-code
changes to the user experience, like (in this case) a changed key
binding.

> > 
>> One remaining decision to make is: what is the future of org-tempo?  I am
>> sympathetic to the idea that the best place for it eventually would be
>> org-contrib or GNU ELPA, and not org core.
> 
> We don’t have make that decision now, do we?

We donʼt strictly have to.  Obviously one approach to making the
decision is to wait and see whether org-tempo is widely adopted/used,
and remove it from core if not.  But if we* can already decide on
principle that something like org-tempo belongs best in contrib or
ELPA, then we can communicate the relevant info all at once when 9.2
is released, rather than for 9.2: “now add (require 'org-tempo) to
.emacs to keep using <s[TAB]” [...time passes, a new org release is
born...]  “now you also have to install org-tempo from somewhere
else.”

*Here Iʼm using “we” loosely, I imagine it will mostly be up to you with
input from Nicolas and Bastien and perhaps others.

-- 
Aaron Ecay

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

[Rasmus]

Hi Aaron,

Thanks for the reply.

Aaron Ecay <aaronecay@gmail.com> writes:

> I wouldnʼt call it nagging.  The user presses “<s[TAB]” expecting
> something special to happen.  The status quo is that nothing at all
> happens.  My proposal is to make something special happen.  Itʼs
> different than what the user expected, but it informs them of what has
> changed and how to get the old behavior back if they want.

They’d already have the "old" behavior if it’s enabled by default in
org.el.  Perhaps I’m too cruel or harsh after many years of dealing with
the Emacs-way, but I do think that such as change is adequatly documented
in ORG-NEWS and the manual.  (Days after a new release there will also be
a stackoverflow question for the Googlers).  I sometimes open many new
Emacs on any given day, sometimes loading my init.el sometimes not.  I
imagine the message would get old quickly.

> Note that the only circumstance when the “nagging” happens is when a
> user presses “<s[TAB]”, and it goes away when either they add
> “(org-tempo-global-mode)” to their .emacs or learn a new habit of
> pressing C-c C-, instead of <s[TAB]

I’m perfectly happy with my (Emacs) habits :)  

> (We could make the warning appear only once per emacs session, if that
> seems like a better balance.)

Yes, that would be a must.

>> There’s tools to mark thinks as obsolete in Emacs should we need to.
>
> There are tools to mark functions and variables obsolete when they are
> used in elisp code.  There is no way of warning a user about non-code
> changes to the user experience, like (in this case) a changed key
> binding.

Customize-changed would bring up the changes to
org-structure-template-alist, which mentions Org Tempo.

ORG-NEWS as well.

But now I’m going in circles.

> We donʼt strictly have to.  Obviously one approach to making the
> decision is to wait and see whether org-tempo is widely adopted/used,
> and remove it from core if not.  But if we* can already decide on
> principle that something like org-tempo belongs best in contrib or
> ELPA, then we can communicate the relevant info all at once when 9.2
> is released, rather than for 9.2: “now add (require 'org-tempo) to
> .emacs to keep using <s[TAB]” [...time passes, a new org release is
> born...]  “now you also have to install org-tempo from somewhere
> else.”

Perhaps.  As I said, I like batteries included, but it’s not for me to
decide.

> *Here Iʼm using “we” loosely, I imagine it will mostly be up to you with
> input from Nicolas and Bastien and perhaps others.

I like the looser definition!

Rasmus 

-- 
Dung makes an excellent fertilizer

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

[Aaron Ecay]

Hi Rasmus,

2018ko maiatzak 7an, Rasmus-ek idatzi zuen:

> 
> They’d already have the "old" behavior if it’s enabled by default in
> org.el.  

Indeed, my suggestion is not an alternative to keeping (what is now
called) org-tempo turned on by default indefinitely.  It is an
alternative to turning org-tempo off suddenly.

> Perhaps I’m too cruel or harsh after many years of dealing with the
> Emacs-way, but I do think that such as change is adequatly documented
> in ORG-NEWS and the manual.  (Days after a new release there will also
> be a stackoverflow question for the Googlers).  

Here I am much more conservative than you: I think that puzzling users
so that they ask questions on stack overflow is an outcome that should
be avoided if possible.  I also think experience shows that ORG-NEWS is
missed by a significant fraction of users.

Besides, I am a programmer not a writer so I believe in the power of
code over prose :P

[...]

> 
> Customize-changed would bring up the changes to
> org-structure-template-alist, which mentions Org Tempo.

Interesting.  I didnʼt know about that function.  I just tried M-x
customize-changed RET Org 9.0 RET.  That gives an error; it seems to
only work based on emacs versions and not package versions.  Thatʼs
unfortunate, it would have been nice if people who install org from ELPA
could use the function to keep up with org changes independently from
their emacs version.  (In fact, I just sent this as a feature request to
the emacs bug tracker, #31383)

-- 
Aaron Ecay

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

[Bastien]

Hi Aaron,

Aaron Ecay <aaronecay@gmail.com> writes:

> Interesting.  I didnʼt know about that function.  I just tried M-x
> customize-changed RET Org 9.0 RET.  That gives an error; it seems to
> only work based on emacs versions and not package versions.  Thatʼs
> unfortunate, it would have been nice if people who install org from ELPA
> could use the function to keep up with org changes independently from
> their emacs version.  (In fact, I just sent this as a feature request to
> the emacs bug tracker, #31383)

Nice move, I hope someone will implement this as we certainly need it.

-- 
 Bastien

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

[Rasmus]

Hi,

Aaron Ecay <aaronecay@gmail.com> writes:

> Hi Rasmus,
>
> 2018ko maiatzak 7an, Rasmus-ek idatzi zuen:
>
>> 
>> They’d already have the "old" behavior if it’s enabled by default in
>> org.el.  
>
> Indeed, my suggestion is not an alternative to keeping (what is now
> called) org-tempo turned on by default indefinitely.  It is an
> alternative to turning org-tempo off suddenly.
>
>> Perhaps I’m too cruel or harsh after many years of dealing with the
>> Emacs-way, but I do think that such as change is adequatly documented
>> in ORG-NEWS and the manual.  (Days after a new release there will also
>> be a stackoverflow question for the Googlers).  
>
> Here I am much more conservative than you: I think that puzzling users
> so that they ask questions on stack overflow is an outcome that should
> be avoided if possible.  I also think experience shows that ORG-NEWS is
> missed by a significant fraction of users.

That is a nice thought, at least in theory.  I guess my worry is about the
"costs" of implementing such practices.

Perhaps we could ask people if they want to have the ORG-NEWS file
displayed when a new version of Org is installed. :)

> Besides, I am a programmer not a writer so I believe in the power of
> code over prose :P

I am not a programmer, so perhaps therein lies the difference.


>> Customize-changed would bring up the changes to
>> org-structure-template-alist, which mentions Org Tempo.
>
> Interesting.  I didnʼt know about that function.  I just tried M-x
> customize-changed RET Org 9.0 RET.  That gives an error; it seems to
> only work based on emacs versions and not package versions.  Thatʼs
> unfortunate, it would have been nice if people who install org from ELPA
> could use the function to keep up with org changes independently from
> their emacs version.  (In fact, I just sent this as a feature request to
> the emacs bug tracker, #31383)

I did not know that.  Thanks.

Rasmus

-- 
Dobbelt-A

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

[Bastien]

Hi Rasmus,

Rasmus <rasmus@gmx.us> writes:

> There’s tools to mark thinks as obsolete in Emacs should we need to.

One problem is that those tools (I'm thinking of define-obsolote-*)
are more developer-oriented than user-oriented.

E.g. AFAIK there is no "tool" to tell a user that a command accepts
a new argument.  Or is there?

>> One remaining decision to make is: what is the future of org-tempo?  I am
>> sympathetic to the idea that the best place for it eventually would be
>> org-contrib or GNU ELPA, and not org core.
>
> We don’t have make that decision now, do we?

No.  For now I'd like to get back to your original "trigger" and
continue to enhance the org-tempo code so that it allows to wrap
regions around templates.

-- 
 Bastien

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

[Rasmus]

Hi,

Bastien <bzg@gnu.org> writes:

>>> One remaining decision to make is: what is the future of org-tempo?  I am
>>> sympathetic to the idea that the best place for it eventually would be
>>> org-contrib or GNU ELPA, and not org core.
>>
>> We don’t have make that decision now, do we?
>
> No.  For now I'd like to get back to your original "trigger" and
> continue to enhance the org-tempo code so that it allows to wrap
> regions around templates.

How would that work?  A snippet is at the beginning of the line?  Also, if
I have delete-selection-mode on it might not make sense to try and "save"
region when expanding a tempo snippet. 

Rasmus


-- 
Evidence suggests Snowden used a powerful tool called monospaced fonts

Smooth transition for modules (was: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]"))

[Bastien]

Hi Aaron,

Aaron Ecay <aaronecay@gmail.com> writes:

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

thanks for this.

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

Thanks -- I tested it.  I like the idea of sending a warning to the
user for backward-incompatible changes but in this case, well, we take
for granted that org-tempo will be turned off by default in the next
release... but this is not decided yet.

To be clear, the whole change still needs work for sure, and nothing
is decided so far.

But here is some food for thought on how to deprecate an Org feature
more nicely.

We have org-modules, which is an internal mechanism to load default
Org modules.  Yes, this predates Emacs package system, and yes, we
should question the usefulness of it now (I do).

But: what if we could use org-modules (or a similar mechanism) to tell
the user: "Hey! We, the AlMighty Developers of Org think this feature
is better not to be loaded by default for *every* user - but you, the
independant rebel, might think otherwise, so here is your chance to
turn it on by default in your configuration.  Proceed (y/n)?"  And
voilà!

For example, the default value of org-modules could be an alist like:

'((org-bbdb . t)
  (org-eww  . t)
  (org-tempo . 'confirm)

Then on first load, traverse this alist and prompt for confirmation
for packages marked 'confirm.

What do you think?

-- 
 Bastien

Re: Smooth transition for modules (was: [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]"))

[Aaron Ecay]

Hi Bastien,

2018ko maiatzak 8an, Bastien-ek idatzi zuen:

> Thanks -- I tested it. 

Thanks :)

> I like the idea of sending a warning to the user for
> backward-incompatible changes but in this case, well, we take for
> granted that org-tempo will be turned off by default in the next
> release... but this is not decided yet.

Indeed, the patch was written under that assumption.  If the situation
changes, (at least) some tweaks would be needed.

> 
> To be clear, the whole change still needs work for sure, and nothing
> is decided so far.
> 
> But here is some food for thought on how to deprecate an Org feature
> more nicely.
> 
> We have org-modules, which is an internal mechanism to load default
> Org modules.  Yes, this predates Emacs package system, and yes, we
> should question the usefulness of it now (I do).
> 
> But: what if [...]

I like this idea, but I also think that emacsʼ packages feature is a
better/newer way to implement something like this.  What if:

1. We donʼt include org-tempo in org releases
2. We teach GNU ELPA to include org-tempo as a package (corresponding to
   stable org releases)
3. We teach <https://orgmode.org/elpa/> to also do so (corresponding to
   nightly org releases)
4. We implement your suggested user prompt, but it will ask them if they
   want to install the org-tempo package from ELPA

In this way, users who either install org from GNU ELPA or use the
version bundled with emacs will get the latest release version of
org-tempo from GNU ELPA.  Those who install the nightly version of org
will get the corresponding nightly version of org-tempo.*

WDYT?

(An alternative to step 3 above is to cater for the nightly release
users by putting org-tempo in org-contrib.  Then we wouldnʼt have to
publish org-tempo on Org ELPA, only GNU ELPA.  But this (a) doesnʼt help
those who install nightly org as opposed to nightly org-plus-contrib,
and (b) means that org-tempo, unlike other packages in contrib, would
have to be kept copyright-clean...so Iʼm not sure it is a good choice.)

Aaron

* Those of us who install org from git might have to do something else
to make sure the right version of org-tempo is loaded, but weʼre used to
living on the edge.  :P

-- 
Aaron Ecay

Re: Smooth transition for modules

[Bastien]

Hi Aaron,

thanks for your feedback.

Ecay <aaronecay@gmail.com> writes:

> Indeed, the patch was written under that assumption.  If the situation
> changes, (at least) some tweaks would be needed.

I will think again about the whole issue and propose a change when
I have some code to show.

> I like this idea, but I also think that emacsʼ packages feature is a
> better/newer way to implement something like this.  What if:
>
> 1. We donʼt include org-tempo in org releases

(Assuming we don't want org-tempo to live in Org's core.)

> 2. We teach GNU ELPA to include org-tempo as a package (corresponding to
>    stable org releases)
> 3. We teach <https://orgmode.org/elpa/> to also do so (corresponding to
>    nightly org releases)

(I doubt https://orgmode.org/elpa/ is still very useful, it might go
away eventually.)

> 4. We implement your suggested user prompt, but it will ask them if they
>    want to install the org-tempo package from ELPA

You mean: instead of simply requiring other packages from a package,
add a new Suggest: header for packages suggestions?

I find this to be a great idea indeed, mimicking what apt-get does
when suggesting other packages to install.

On top of that, you could have an option in package.el that, when
turned on, would explicitely ask the user if she wants to install
suggested packages.

> In this way, users who either install org from GNU ELPA or use the
> version bundled with emacs will get the latest release version of
> org-tempo from GNU ELPA.

I fail to see how users who don't install Org at all and use the
version that is bundled with Emacs are asked whether they want to
install a soon-to-be-deprecated package - let me know if I missed
something.

> Those who install the nightly version of org
> will get the corresponding nightly version of org-tempo.*
>
> WDYT?

I think this discussion shows there is room for nice ideas when it
comes to enhance the user experience!

> * Those of us who install org from git might have to do something else
> to make sure the right version of org-tempo is loaded, but weʼre used to
> living on the edge.  :P

Well, I think that even experienced users would enjoy discovering new
packages when suggested by the packages they use -- and also enjoy the
fact that they are asked whether they accept to disable a feature (now
externalized as a package) when they upgrade a package.

I hope we can digg in that direction!

-- 
 Bastien

Re: Smooth transition for modules

[Aaron Ecay]

Hi Bastien,

2018ko maiatzak 8an, Bastien-ek idatzi zuen:

[...]


> 
> You mean: instead of simply requiring other packages from a package,
> add a new Suggest: header for packages suggestions?

Everything you described sounds like a wonderful idea.  What I had in
mind was much simpler.  It (I think) does not require adding any new
features to package.el.  The best way I can explain it is with the
following pseudocode, which I envision would be run when org is loaded:

(defcustom asked-already-p nil
  "docstring")

(unless asked-already-p
  (when (and (not (package-installed-p "org-tempo"))
             (y-or-n-p "Do you like <s templates? "))
    (package-install "org-tempo"))
  (custom-set-and-save-variable 'asked-already-p t))


> Well, I think that even experienced users would enjoy discovering new
> packages when suggested by the packages they use

Agreed.  My only concern was that users installing from git might not
have the right settings of package-archives etc to make the
package-install call above work correctly.  Maybe I was being
pessimistic about that, though.

-- 
Aaron Ecay

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

[Bastien]

Hi Aaron,

Aaron Ecay <aaronecay@gmail.com> writes:

> As a general (idealized) principle, I think user-visible changes should
> be phased in over at least one org major version.  I have no problem
> with “intrusive” deprecation warnings, but abrupt changes in behavior
> should be avoided.

I fully agree with the above.  I will summarize what I suggest as the
next move for this particular feature.

Thanks,

-- 
 Bastien

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

[Eric S Fraga]

[-- Attachment #1: Type: text/plain, Size: 693 bytes --]

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

[...]

> But again, I might be wrong, I just don't want this to be a discussion
> between us two :)

The new system seems more powerful and works better for me as it doesn't
conflict with predictive texting that also uses the TAB key.

I'm am tending to side with the view put forward by Nicolas on this one:
one well supported solution is better than 2.  However, Emacs is
infamous for having >n (with n large) solutions to any problem...  So I
don't have any fundamental problems with both being available per se so
long as they do not conflict.

My 2¢.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.7-475-g3ffc7d

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

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

[Bastien]

Hi Nicolas,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> It seems nonsensical to let Org handle expansion templates.

Not to me, because Org syntax include default structured templates.

> Dedicated packages do it way better than what we provide, and the
> task is really out of our scope.

I think we are going in the right direction by reusing features from
Emacs core.  As long as tempo.el is in Emacs, it means to me that we
are encouraged to use it in other core Emacs features like Org.

-- 
 Bastien

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

[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

Bastien writes:

> Hi Nicolas,
>
> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> You disagreed with me in the first place with commit 71ad7b1. It was my
>> original intent to not load Org Tempo by default.
>
> Sorry if I missed the statement where you explicitely said you thought
> org-tempo should not be enabled by default, I thought it was just an
> oversight and I didn't realize I was in a disagreement with you when I
> pushed this commit -- if I thought so, I'd write to you on the list to
> raise the topic instead of forcing a change through a commit.
>
> Again, I may be wrong in thinking disabling this will cause trouble to
> many users.  Let's just take a moment to see what users think.
>
> Thanks,

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

[Charles Millar]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

Hi all,


On 04/29/2018 07:05 AM, Bastien wrote:
> Hi Nicolas,
>
> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
     Let's just take a moment to see what users think.

I was aware of tempo.el and tempo from postings to the list. However It 
was not until I upgraded to version 9.1.12 from 9.1.11 that I realized 
that tempo was the default; I thought that it was optional. With 9.1.12 
installed I could not open any of my org files because of the blocks 
that I added through the years to the org-structure-template-alist.

I used the previous feature merely to insert blocks, which were not 
necessarily for coding; the first block I added was obtained from Dan 
Doherty, on this list, about six years ago and it had nothing to do with 
coding but to insert a debit and credit columns into a document.

I will adapt if I must, but I suspect that there are other users such as 
I who merely used the feature to insert a block of text or something 
else other than code.

Charlie Millar


[-- Attachment #2: Type: text/html, Size: 1615 bytes --]

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

[Diego Zamboni]

[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]

Hi,

> On 29 Apr 2018, at 13:05, Bastien <bzg@gnu.org> wrote:
> Again, I may be wrong in thinking disabling this will cause trouble to
> many users.  Let's just take a moment to see what users think.

Here’s my 2 cents: I’ve only been using org-mode for a few months now, but almost from the beginning I learned about org-tempo and the “<s" expansions, so I got used to them. I find it very natural and quick to type. At some point it became necessary to add "(require org-tempo)" to my init file, which didn’t bother me.

Since a few weeks ago (around 9.1.10-11, maybe?) the “<s" expansion seems a bit broken - if I try to use it in the middle of a file and there is a block of the same type further down in the file, then only the opening line of the block is inserted. So I’ve been using "C-c C-," more, which seems to work fine. I just now realized (thanks to Nicolas’ comment) that it works on regions, which is nice (I had been using "org-babel-demarcate-block” - “C-c C-v d” for that).

So, to summarize: I don’t mind having to load org-tempo explicitly, but it wold be nice to make the change visible (maybe make ORG-NEWS more visible) and to fix the bug I mentioned.

Best,
—Diego


[-- Attachment #2: Type: text/html, Size: 3151 bytes --]

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

[Rasmus]

Hi,

Diego Zamboni <diego@zzamboni.org> writes:

> Since a few weeks ago (around 9.1.10-11, maybe?) the “<s" expansion
> seems a bit broken - if I try to use it in the middle of a file and
> there is a block of the same type further down in the file, then only
> the opening line of the block is inserted. So I’ve been using "C-c
> C-," more, which seems to work fine. I just now realized (thanks to
> Nicolas’ comment) that it works on regions, which is nice (I had been
> using "org-babel-demarcate-block” - “C-c C-v d” for that).

Would it be possible to send a reproducible bug-report, starting from
"emacs -q"?

Thanks,
Rasmus

-- 
May contains speling mistake

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

[Bastien]

Hi Diego,

thanks for your input.

Zamboni <diego@zzamboni.org> writes:

> So, to summarize: I don’t mind having to load org-tempo explicitly,
> but it wold be nice to make the change visible (maybe make ORG-NEWS
> more visible) and to fix the bug I mentioned.

Can you give a recipe on how to reproduce the bug?  And more details
on your configuration (M-x org-version RET)? I cannot find a way to
trigger a bug for this.

Thanks!

-- 
 Bastien

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

[Bernt Hansen]

Bastien <bzg@gnu.org> writes:

> Hi Nicolas,
>
> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> You disagreed with me in the first place with commit 71ad7b1. It was my
>> original intent to not load Org Tempo by default.
>
> Sorry if I missed the statement where you explicitely said you thought
> org-tempo should not be enabled by default, I thought it was just an
> oversight and I didn't realize I was in a disagreement with you when I
> pushed this commit -- if I thought so, I'd write to you on the list to
> raise the topic instead of forcing a change through a commit.
>
> Again, I may be wrong in thinking disabling this will cause trouble to
> many users.  Let's just take a moment to see what users think.
>
> Thanks,

Hi Bastien, Nicolas, Rasmus, and list!

So here is my take on this.

org-tempo is the reason I am here on master right now and participating
in this conversation.

I am not really for or against enabling org-tempo by default.  If it's
not enabled by default and a clear path is documented for how to achieve
the same thing in ORG-NEWS using yasnippet or some other expansion
system then that is perfectly okay with me.  If I can't use <e and <s
anymore I'll just have to retrain my fingers which have been using this
for 10 years now -- it's doable it will just take me some time :) Right
now using yasnippet is what I would be setting up if org-tempo was not
enabled in my configuration.  I just need a refresher on how to write my
yasnippet templates since I haven't done that in years.

If I rewrite the few templates I use all the time in yasnippet then I
don't need this require for org-tempo in my configuration anymore
(Thanks for creating org-tempo Rasmus!).  I added it simply to restore
the <e and <s expansions in the master branch and I don't really know
what other capabilities it has.

I agree with Nicholas that if it just works users don't have to put any
thought or effort into learning anything new and thus they won't be
contributing feedback on the new functions as they won't be aware of
them or using them.

When I switched from 8.3 to the latest maint branch a few weeks back I
went through ORG-NEWS to deal with major errors I received on emacs
startup from my existing 8.3 config.  I admit I didn't read ORG-NEWS top
to bottom for every change between the versions.  I only addressed
obvious failures at startup to see if I could overcome them quickly and
easily since I wanted to get back to real work ASAP.

<s and <e still worked in maint (but that was probably after it was
enabled by default specifically in that branch).  Then when I switched
to the master branch at work to try things out the expansions didn't
work.  I use these all the time and simply switched back to maint
immediately so as not to adversely impact productivity at work.  It
never occurred to me to go look in ORG-NEWS to see if this had changed
-- I just assumed it was a bug -- until I caught up to the thread on the
mailing list.

I have no problem with switching to yasnippet or some other
templating/expansion system to achieve the same (or better) result as I
already enjoy in org-mode -- all I would need for that is clear
instructions on how to achieve it.  Writing yasnippet expansions will
work just fine for me, I just need to create the templates -- I am
already using yasnippet in my configuration.

I wasn't aware of the new expansion system that Nicholas is referring to
(and still don't know what it is or how/if I will be using it) -- I just
need some time to review and play with it.

Currently I prefer short key expansions without complicated keystrokes.
I'm using abbrev mode to insert people's names from their initials
quickly while taking meeting notes (like 'ibh' becomes 'Bernt Hansen')
and <s and <e fit in nicely with my easy typing replacement in my
workflows.  If I have to slow down with complicated keystrokes I can't
keep up with the details of meetings.  How exactly they expand and who
provides the functionality ultimately isn't important to me -- as long
as they work :)

Regards,
Bernt

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

[Bernt Hansen]

Bernt Hansen <bernt@norang.ca> writes:

> I am not really for or against enabling org-tempo by default.  If it's
> not enabled by default and a clear path is documented for how to achieve
> the same thing in ORG-NEWS using yasnippet or some other expansion
> system then that is perfectly okay with me.  If I can't use <e and <s
> anymore I'll just have to retrain my fingers which have been using this
> for 10 years now -- it's doable it will just take me some time :))

So I'm changing my vote :)
I've disabled org-tempo and am in the process of learning to use C-c C-,
instead of <s and <e and I like it a lot better already.

It wraps selected regions in the e and s templates and works great! :)

Thanks Nicolas!

Regards,
Bernt

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

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]

Dear all,

after initial doubt about this issue, I am now siding with Nicolas on this
one.  I have started to use C-c C-,   , and it works very well.  In
particular, as Bernt says, the wrapping makes a very big difference, I have
always missed this.

Carsten

On Wed, May 2, 2018 at 10:26 PM Bernt Hansen <bernt@norang.ca> wrote:

> Bernt Hansen <bernt@norang.ca> writes:
>
> > I am not really for or against enabling org-tempo by default.  If it's
> > not enabled by default and a clear path is documented for how to achieve
> > the same thing in ORG-NEWS using yasnippet or some other expansion
> > system then that is perfectly okay with me.  If I can't use <e and <s
> > anymore I'll just have to retrain my fingers which have been using this
> > for 10 years now -- it's doable it will just take me some time :))
>
> So I'm changing my vote :)
> I've disabled org-tempo and am in the process of learning to use C-c C-,
> instead of <s and <e and I like it a lot better already.
>
> It wraps selected regions in the e and s templates and works great! :)
>
> Thanks Nicolas!
>
> Regards,
> Bernt
>
>

[-- Attachment #2: Type: text/html, Size: 1587 bytes --]

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

[William Denton]

On 3 May 2018, Carsten Dominik wrote:

> after initial doubt about this issue, I am now siding with Nicolas on this
> one.  I have started to use C-c C-,   , and it works very well.  In
> particular, as Bernt says, the wrapping makes a very big difference, I have
> always missed this.

I feel the same.  I'd set up ya-snippets to get the old behaviour, but I've been 
trying this and am going to switch over permanently.  (That said, it might make 
sense to do this in version 10.)

M-x three-cheers-for-org-mode,

Bill
--
William Denton :: Toronto, Canada   ---   Listening to Art: https://listeningtoart.org/
https://www.miskatonic.org/         ---   GHG.EARTH: http://ghg.earth/
Caveat lector.                      ---   STAPLR: http://staplr.org/

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

[Neil Jerram]

William Denton <wtd@pobox.com> writes:

> On 3 May 2018, Carsten Dominik wrote:
>
>> after initial doubt about this issue, I am now siding with Nicolas on this
>> one.  I have started to use C-c C-,   , and it works very well.  In
>> particular, as Bernt says, the wrapping makes a very big difference, I have
>> always missed this.
>
> I feel the same.  I'd set up ya-snippets to get the old behaviour, but I've been 
> trying this and am going to switch over permanently.  (That said, it might make 
> sense to do this in version 10.)

How can I see and try this famous C-c C-, ?  I'm running:

  Org mode version 9.1.12 (9.1.12-1-g388254-elpa @ /home/neil/.emacs.d/elpa/org-20180430/)

but apparently that is still not new enough:

  C-c C-, is undefined

> M-x three-cheers-for-org-mode,

Hip hip!

Many thanks - Neil

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

[Bastien]

Hi Neil,

Neil Jerram <neil@ossau.homelinux.net> writes:

> How can I see and try this famous C-c C-, ?  I'm running:
>
>   Org mode version 9.1.12 (9.1.12-1-g388254-elpa @
>   /home/neil/.emacs.d/elpa/org-20180430/)

The new structure template mechanism will be part of the next major
Org release (9.2).  You can test it by cloning the master branch of
Org's repository.

Check https://orgmode.org/manual/Installation.html#Installation

HTH,

-- 
 Bastien

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

[Samuel Wales]

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

On 5/4/18, Bastien <bzg@gnu.org> wrote:
> Hi Neil,
>
> Neil Jerram <neil@ossau.homelinux.net> writes:
>
>> How can I see and try this famous C-c C-, ?  I'm running:
>>
>>   Org mode version 9.1.12 (9.1.12-1-g388254-elpa @
>>   /home/neil/.emacs.d/elpa/org-20180430/)
>
> The new structure template mechanism will be part of the next major
> Org release (9.2).  You can test it by cloning the master branch of
> Org's repository.
>
> Check https://orgmode.org/manual/Installation.html#Installation
>
> HTH,
>
> --
>  Bastien
>
>


-- 
The Kafka Pandemic: <http://thekafkapandemic.blogspot.com>

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

"You’ve really gotta quit this and get moving, because this is murder
by neglect." ---
<http://www.meaction.net/2017/02/03/pwme-people-with-me-are-being-murdered-by-neglect>.

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

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

Samuel Wales <samologist@gmail.com> writes:

> is there a reason why the binding cannot be c-c '?
>
> On 5/4/18, Bastien <bzg@gnu.org> wrote:
>> Hi Neil,
>>
>> Neil Jerram <neil@ossau.homelinux.net> writes:
>>
>>> How can I see and try this famous C-c C-, ?  I'm running:
>>>
>>>   Org mode version 9.1.12 (9.1.12-1-g388254-elpa @
>>>   /home/neil/.emacs.d/elpa/org-20180430/)
>>
>> The new structure template mechanism will be part of the next major
>> Org release (9.2).  You can test it by cloning the master branch of
>> Org's repository.
>>
>> Check https://orgmode.org/manual/Installation.html#Installation
>>
>> HTH,
>>
>> --
>>  Bastien
>>
>>


-- 
Tim Cross

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

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

On 5/4/18, Tim Cross <theophilusx@gmail.com> wrote:
>
> won't that conflict with the key binding for block editing mode?
>
> Also, I think C-c , is possibly more in-line with other
> template/expansion commands in other modes.
>
> Of course, being emacs, anyone can change it to suit personal
> preferences!
>
> Samuel Wales <samologist@gmail.com> writes:
>
>> is there a reason why the binding cannot be c-c '?
>>
>> On 5/4/18, Bastien <bzg@gnu.org> wrote:
>>> Hi Neil,
>>>
>>> Neil Jerram <neil@ossau.homelinux.net> writes:
>>>
>>>> How can I see and try this famous C-c C-, ?  I'm running:
>>>>
>>>>   Org mode version 9.1.12 (9.1.12-1-g388254-elpa @
>>>>   /home/neil/.emacs.d/elpa/org-20180430/)
>>>
>>> The new structure template mechanism will be part of the next major
>>> Org release (9.2).  You can test it by cloning the master branch of
>>> Org's repository.
>>>
>>> Check https://orgmode.org/manual/Installation.html#Installation
>>>
>>> HTH,
>>>
>>> --
>>>  Bastien
>>>
>>>
>
>
> --
> Tim Cross
>


-- 
The Kafka Pandemic: <http://thekafkapandemic.blogspot.com>

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

"You’ve really gotta quit this and get moving, because this is murder
by neglect." ---
<http://www.meaction.net/2017/02/03/pwme-people-with-me-are-being-murdered-by-neglect>.

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

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


Samuel Wales <samologist@gmail.com> writes:

> if there is a block there, you probably don't want to create a block.
> if it is not there, you probably want to create one.
>
> was my thinking.  incorrect?
>
> On 5/4/18, Tim Cross <theophilusx@gmail.com> wrote:
>>
>> won't that conflict with the key binding for block editing mode?
>>
>> Also, I think C-c , is possibly more in-line with other
>> template/expansion commands in other modes.
>>
>> Of course, being emacs, anyone can change it to suit personal
>> preferences!
>>
>> Samuel Wales <samologist@gmail.com> writes:
>>
>>> is there a reason why the binding cannot be c-c '?
>>>
>>> On 5/4/18, Bastien <bzg@gnu.org> wrote:
>>>> Hi Neil,
>>>>
>>>> Neil Jerram <neil@ossau.homelinux.net> writes:
>>>>
>>>>> How can I see and try this famous C-c C-, ?  I'm running:
>>>>>
>>>>>   Org mode version 9.1.12 (9.1.12-1-g388254-elpa @
>>>>>   /home/neil/.emacs.d/elpa/org-20180430/)
>>>>
>>>> The new structure template mechanism will be part of the next major
>>>> Org release (9.2).  You can test it by cloning the master branch of
>>>> Org's repository.
>>>>
>>>> Check https://orgmode.org/manual/Installation.html#Installation
>>>>
>>>> HTH,
>>>>
>>>> --
>>>>  Bastien
>>>>
>>>>
>>
>>
>> --
>> Tim Cross
>>


-- 
Tim Cross

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

[Nicolas Goaziou]

Hello,

Tim Cross <theophilusx@gmail.com> writes:

> The C-c , binding is in line with expansion/templates in other modes (at
> least in my configuration), so there is little cognitive overhead when I
> want to expand "something".

`C-c ,' is a keybinding reserved for minor modes. See (info "(elisp) Key
Binding Conventions")

We should avoid, if possible, to use it.

Regards,

-- 
Nicolas Goaziou

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

[Rasmus]

Tim Cross <theophilusx@gmail.com> writes:

> won't that conflict with the key binding for block editing mode?

Isn’t that "C-’".  Blocks are "C-c C-,".  I used some program to scavenge
for unused bindings in, I think, December last year and we discussed it on
the list.  I think the main contenders were "C-c C-." and "C-c C-," and
the latter is a bit nicer on my keyboard layout...
 
I might be have misunderstood something, if so I apologize.

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

Don’t know.  Why?

Rasmus

-- 
Er du tosset for noge' lårt!

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

[Nick Helm]

On Sun, 29 Apr 2018 at 23:05:20 +1200, Bastien wrote:

> I may be wrong in thinking disabling this will cause trouble to
> many users.  Let's just take a moment to see what users think.

I vote to drop "<s" and adopt the new mechanism by default. "<s" always
seemed a bit off to me. Convenient, yes, but rather counterintuitive.

And besides, what is org doing in the templating business anyway?
Doesn't this fall into the category of "basic infrastructure that Emacs
should provide to all modes"?

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

[Rasmus]

Hi,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> We introduced a new expansion mechanism, recently bound to `C-c C-,'.
> This mechanism is more in line with usual Org functions: it operates on
> regions like, say, `org-insert-drawer'. It is an obvious default
> expansion mechanism.
>
> If the big menu, we could however improve it with an "expert" UI, like
> we already do for export and tags.

Aside: At the moment key combinations are generated on the go (unless
someone it was changed), so a full "expert-mode a la the export
dispatcher" would likely not work.  Of course, org-mks could be made
nicer, as is obvious when compared to the export dispatcher.

> Now, some users are used to "<s" constructs, and are not willing to
> switch to that expansion mechanism. Fair enough. I first suggested to
> use Yasnippets, which is powerful enough and easy to use. Some users
> still didn't want to use that. Well. I suggested Tempo, but, admittedly,
> out of the box, it is not really usable. Then Rasmus wrote Org Tempo.
>
> Even though Org Tempo is probably useful for a part of users, it is yet
> another occurrence of NIH in Org mode. Instead of using already
> available, and fitting, libraries for a task, we implement one.

FWIW, I strongly disagree that Yasnippet is a suitable replacement.  IMO
it’s not at all intuitive.  Why is using tempo NIH?

> Also, it will probably prevent the default expansion mechanism to
> receive feedback, and therefore, improvements (even though it is better
> for basic uses) because users will not even notice the new mechanism if
> the old one works out of the box.


> IMO, Org Tempo should live outside of Org core, like many other
> Org-related libraries.

I disagree.

> Some die-hard "<s" users might be annoyed if they
> had to install an external library. So asking for a "(require
> 'org-tempo)" was an acceptable compromise, until your disagreement.

FWIW, I am indifferent to whether org-tempo is loaded by default or not as
long as it’s included by default and documented in the manual.

Rasmus


-- 
May contains speling mistake

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

[Nicolas Goaziou]

Hello,

Rasmus <rasmus@gmx.us> writes:

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

You must be kidding. Consider the following snippet:

   # key: <s
   # --
   #+begin_src $1
   $0
   #+end_src

In a buffer, "<s" and TAB lets me insert the language and possible
header arguments, then another TAB puts point within the block.

Note that by changing "$1" into "${1:emacs-lisp}", you can even default
to emacs-lisp block if you use "<s" TAB TAB.

No offense intended, but Yasnippet is more powerful and also more
versatile than what we offer, since we stick to "<" prefix for
historical reasons.

> Why is using tempo NIH?

Using Tempo is fine. But we're writing a template system on top of it,
which is a different beast.

Regards,

-- 
Nicolas Goaziou

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

[Rasmus]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Rasmus <rasmus@gmx.us> writes:
>
>> FWIW, I strongly disagree that Yasnippet is a suitable replacement.  IMO
>> it’s not at all intuitive.
>
> You must be kidding. Consider the following snippet:
>
>    # key: <s
>    # --
>
>    #+begin_src $1
>    $0
>    #+end_src
>
> In a buffer, "<s" and TAB lets me insert the language and possible
> header arguments, then another TAB puts point within the block.

Especially the tab behavior is what "gets me" with yasnippet.  It seems
erratic.  Some package that I use used to auto-load it a few years back
and it created a horrible mess with weird highlights and the tab key not
working as expected.

I have not tried it for many years, but last time I used it I had a
distinct distaste for its behavior.

The syntax looks nice.

> No offense intended, but Yasnippet is more powerful and also more
> versatile than what we offer, since we stick to "<" prefix for
> historical reasons.

Perhaps what we offer is also more simple.

>> Why is using tempo NIH?
>
> Using Tempo is fine. But we're writing a template system on top of it,
> which is a different beast.

I am not sure I would raise it to a "template system".  At most a "block
insertion system".

Rasmus

-- 
To err is human. To screw up 10⁶ times per second, you need a computer

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

[Steve Downey]

[-- Attachment #1: Type: text/plain, Size: 485 bytes --]

Changing the UI to no longer work is a very non-emacsy thing to do. There's
a lot of existing doc and tutorials explaining the org template system, as
well as current users who have trained fingers. Breaking <s[tab] will be
unpleasant.
ELPA makes package upgrades much more transparent, which means users will
not necessarily notice that Org is getting updated. And emacs has trained
users that upgrading is harmless. Without intervention, emacs will behave
the same as it did before.

[-- Attachment #2: Type: text/html, Size: 521 bytes --]

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

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

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

[Richard Lawrence]

Jon Snader <jcs@irreal.org> writes:

> I use the <s[TAB] mechanism all the time and /definitely/ want 
> it enabled. I don't want to have to deal with a menu and its 
> more complicated calling sequence

I feel the same!  Please don't disable <s[TAB] or make it more 
complicated to use.

-- 
Best,
Richard

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

[Peter Dewey Ore]

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

I second (third?) Richard and Jon. I use <s[TAB] very frequently and I
appreciate the simplicity.

On Mon, Apr 30, 2018 at 1:37 PM, Richard Lawrence <
richard.lawrence@berkeley.edu> wrote:

> Jon Snader <jcs@irreal.org> writes:
>
> I use the <s[TAB] mechanism all the time and /definitely/ want it enabled.
>> I don't want to have to deal with a menu and its more complicated calling
>> sequence
>>
>
> I feel the same!  Please don't disable <s[TAB] or make it more complicated
> to use.
>
> --
> Best,
> Richard
>
>

[-- Attachment #2: Type: text/html, Size: 1121 bytes --]

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

[Michael Gauland]

[-- Attachment #1: Type: text/plain, Size: 694 bytes --]

Same here!


On 01/05/18 08:46, Peter Dewey Ore wrote:
> I second (third?) Richard and Jon. I use <s[TAB] very frequently and I
> appreciate the simplicity.
>
> On Mon, Apr 30, 2018 at 1:37 PM, Richard Lawrence
> <richard.lawrence@berkeley.edu <mailto:richard.lawrence@berkeley.edu>>
> wrote:
>
>     Jon Snader <jcs@irreal.org <mailto:jcs@irreal.org>> writes:
>
>         I use the <s[TAB] mechanism all the time and /definitely/ want
>         it enabled. I don't want to have to deal with a menu and its
>         more complicated calling sequence
>
>
>     I feel the same!  Please don't disable <s[TAB] or make it more
>     complicated to use.
>
>     -- 
>     Best,
>     Richard
>
>


[-- Attachment #2: Type: text/html, Size: 2034 bytes --]

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

[Jon Snader]

Richard Lawrence <richard.lawrence@berkeley.edu> writes:

> Jon Snader <jcs@irreal.org> writes:
>
>> I use the <s[TAB] mechanism all the time and /definitely/ want 
>> it
>> enabled. I don't want to have to deal with a menu and its more
>> complicated calling sequence
>
> I feel the same!  Please don't disable <s[TAB] or make it more
> complicated to use.

You can make the case that it doesn't really matter because all 
that's
needed is a minor adjustment to your init.el to restore the old
behavior. But here's what's going to happen: A user who upgrades 
through
ELPA is going to discover that suddenly the familiar template code 
is no
longer working. He'll likely think it's an bug and wait for an 
upgrade
or two for it to be fixed. When it doesn't get fixed, he'll ask 
the
Internet what's wrong. 

Here's what's not going to happen: he's not going to read the 
ORG-NEWS
file. In the first place, as Bastien says, most users don't but 
many
users won't even know where to look. Org mode is famously Emacs' 
killer
app and many non-technical users have been drawn to Emacs to get 
access
to it. Many of them probably have no idea where the ELPA files are
stored and even if they do they probably won't look in the etc
subdirectory.

Why torture our users when it's so simple to keep the old behavior
enabled? If I hadn't seen Bastien's tweet pointing to this thread, 
I
would most certainly be one of the people described above.

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

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 3050 bytes --]

I don't think anyone disagrees that this change comes at a cost. Change is
very difficult and many people don't like change. The real question is how
do we manage this change to minimise the pain while moving org forward to
make it an even better solution.

Many seem to believe that what is being discussed here is a loss of
functionality. This isn't really the case. What we are talking about here
is a change, even an enhancement, of functionality. Unfortunately, that
change cannot be implemented without some impact to users.

The question is how do we implement this change so that users will get to
benefit from the improvements while minimising impact to those who don't
want to change or cannot make the change right now and at the same time,
ensure users are exposed to the new functionality so that they can gain the
benefit from this change.  On one side, we have those who feel the impact
is too muich and will cause too much pain for users and on the other side,
we ahve a concern that without some impact to users, we run the risk of
inertia and unawareness of the improvements/enhancements for existing users
and new users being introduced to the older, less feature rich solution
rather than the enhanced  version.

Personally, I feel the new version should be the default and we should
provide an easy way to re-enable the old version for those who wish to
continue with what they are use to. The key will be how we communicate this
to existing users.

Tim

On 1 May 2018 at 07:46, Jon Snader <jcs@irreal.org> wrote:

>
> Richard Lawrence <richard.lawrence@berkeley.edu> writes:
>
> Jon Snader <jcs@irreal.org> writes:
>>
>> I use the <s[TAB] mechanism all the time and /definitely/ want it
>>> enabled. I don't want to have to deal with a menu and its more
>>> complicated calling sequence
>>>
>>
>> I feel the same!  Please don't disable <s[TAB] or make it more
>> complicated to use.
>>
>
> You can make the case that it doesn't really matter because all that's
> needed is a minor adjustment to your init.el to restore the old
> behavior. But here's what's going to happen: A user who upgrades through
> ELPA is going to discover that suddenly the familiar template code is no
> longer working. He'll likely think it's an bug and wait for an upgrade
> or two for it to be fixed. When it doesn't get fixed, he'll ask the
> Internet what's wrong.
> Here's what's not going to happen: he's not going to read the ORG-NEWS
> file. In the first place, as Bastien says, most users don't but many
> users won't even know where to look. Org mode is famously Emacs' killer
> app and many non-technical users have been drawn to Emacs to get access
> to it. Many of them probably have no idea where the ELPA files are
> stored and even if they do they probably won't look in the etc
> subdirectory.
>
> Why torture our users when it's so simple to keep the old behavior
> enabled? If I hadn't seen Bastien's tweet pointing to this thread, I
> would most certainly be one of the people described above.
>
>


-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 4230 bytes --]

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

[Cook, Malcolm]

[-- Attachment #1: Type: text/plain, Size: 3840 bytes --]

If the poll is still open, I vote don’t change the default.

Unless I missed a prior good argument for changing it…

Or, unless, upon first invocation, org-mode guided you through or prompted you to changing your defaults, or at the very least, offered/insisted upon your reading ORG-NEWS.

Otherwise, I think Jon is spot on in his assessment of  “what’s going to happen” to many.


From: Emacs-orgmode <emacs-orgmode-bounces+mec=stowers.org@gnu.org> On Behalf Of Tim Cross
Sent: Monday, April 30, 2018 5:25 PM
To: Jon Snader <jcs@irreal.org>
Cc: Bastien <bzg@gnu.org>; Org-mode <emacs-orgmode@gnu.org>
Subject: Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")

I don't think anyone disagrees that this change comes at a cost. Change is very difficult and many people don't like change. The real question is how do we manage this change to minimise the pain while moving org forward to make it an even better solution.

Many seem to believe that what is being discussed here is a loss of functionality. This isn't really the case. What we are talking about here is a change, even an enhancement, of functionality. Unfortunately, that change cannot be implemented without some impact to users.

The question is how do we implement this change so that users will get to benefit from the improvements while minimising impact to those who don't want to change or cannot make the change right now and at the same time, ensure users are exposed to the new functionality so that they can gain the benefit from this change.  On one side, we have those who feel the impact is too muich and will cause too much pain for users and on the other side, we ahve a concern that without some impact to users, we run the risk of inertia and unawareness of the improvements/enhancements for existing users and new users being introduced to the older, less feature rich solution rather than the enhanced  version.

Personally, I feel the new version should be the default and we should provide an easy way to re-enable the old version for those who wish to continue with what they are use to. The key will be how we communicate this to existing users.

Tim

On 1 May 2018 at 07:46, Jon Snader <jcs@irreal.org<mailto:jcs@irreal.org>> wrote:

Richard Lawrence <richard.lawrence@berkeley.edu<mailto:richard.lawrence@berkeley.edu>> writes:
Jon Snader <jcs@irreal.org<mailto:jcs@irreal.org>> writes:
I use the <s[TAB] mechanism all the time and /definitely/ want it
enabled. I don't want to have to deal with a menu and its more
complicated calling sequence

I feel the same!  Please don't disable <s[TAB] or make it more
complicated to use.

You can make the case that it doesn't really matter because all that's
needed is a minor adjustment to your init.el to restore the old
behavior. But here's what's going to happen: A user who upgrades through
ELPA is going to discover that suddenly the familiar template code is no
longer working. He'll likely think it's an bug and wait for an upgrade
or two for it to be fixed. When it doesn't get fixed, he'll ask the
Internet what's wrong.
Here's what's not going to happen: he's not going to read the ORG-NEWS
file. In the first place, as Bastien says, most users don't but many
users won't even know where to look. Org mode is famously Emacs' killer
app and many non-technical users have been drawn to Emacs to get access
to it. Many of them probably have no idea where the ELPA files are
stored and even if they do they probably won't look in the etc
subdirectory.

Why torture our users when it's so simple to keep the old behavior
enabled? If I hadn't seen Bastien's tweet pointing to this thread, I
would most certainly be one of the people described above.



--
regards,

Tim

--
Tim Cross


[-- Attachment #2: Type: text/html, Size: 8479 bytes --]

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

[Jon Snader]

Tim Cross <theophilusx@gmail.com> writes:

>[Snip]
>
> Personally, I feel the new version should be the default and we 
> should
> provide an easy way to re-enable the old version for those who 
> wish to
> continue with what they are use to.

We already have this. The problem, as you say, is

> how we communicate this to existing users.

But here's what I don't understand: what, exactly, is so bad about
leaving the old behavior enabled by default. The new behavior is 
still
available and naive users don't get surprised. What's not to like?

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

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

Hi all,

I normally am all for adapting to changes, staying on bleeding edges of
emacs, Org, etc.

But FWIW, for this particular change to the "<s" Easy Templates, I'm in the
camp of "It was working awesome, it was beautiful! Why change it?". For
record, I understand the "why", but it just doesn't seem worth it in this
case.

But the good thing is that this is open source, and you can backport the
stuff you like from the original Easy Template code into your personal
Emacs config (and then later adapt to the new way of doing the similar when
you have time and motivation).

Kaushal
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 839 bytes --]

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

[Alan Tyree]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

I'm a non-technical user, and I've never used ysnippets, but I'm willing to
give it a go with some proper instruction.

I do see the argument of both sides.

Here is a question: I see specialised snippet packages in the ELPA
respositories. Is it possible to provide snippets that reproduce the
existing "Easy Templates", maybe even keep the same key bindings so that
the change is transparent to the users that are likely to have the troubles
referred to by Bastien?

It is a genuine question since I have no idea of the problems involved.

I'll keep using org no matter what you decide!

Cheers,
Alan


On 1 May 2018 at 08:49, Kaushal Modi <kaushal.modi@gmail.com> wrote:

> Hi all,
>
> I normally am all for adapting to changes, staying on bleeding edges of
> emacs, Org, etc.
>
> But FWIW, for this particular change to the "<s" Easy Templates, I'm in
> the camp of "It was working awesome, it was beautiful! Why change it?". For
> record, I understand the "why", but it just doesn't seem worth it in this
> case.
>
> But the good thing is that this is open source, and you can backport the
> stuff you like from the original Easy Template code into your personal
> Emacs config (and then later adapt to the new way of doing the similar when
> you have time and motivation).
>
> Kaushal
> --
>
> Kaushal Modi
>



-- 
Alan L Tyree                    http://www2.austlii.edu.au/~alan

[-- Attachment #2: Type: text/html, Size: 2506 bytes --]

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

[Christophe Schockaert]

Alan Tyree writes:

> [...]
>
> Here is a question: I see specialised snippet packages in the ELPA
> respositories. Is it possible to provide snippets that reproduce the
> existing "Easy Templates", maybe even keep the same key bindings so that
> the change is transparent to the users that are likely to have the troubles
> referred to by Bastien?

By chances, I spent some spare time reading this thread, and the
previous one.

Well, Org is my daily-life tool, I am a bit outdated, although. And I
would like to change that, by getting closer to Org upgrades.

I fully understand and can value the need for improving software design
and focusing towards consistent functions, as time passes by and
software grows and evolves.

Also, when there are breaking changes, the thing is that it's often
never the right time. I mean, however small it is, when you are in your
daily process, it does not necesserily fit your agenda. So, I try to
carefully select times for my upgrades, and I am glad to be aware of
this one.

So, I am ready to adapt myself. I will probably learn the new keys if
they are easy to work with. However, the existing shortcut seems so
natural to remember for whom is used to markup tags. And it's easy to
type.

If yasnippets is the way to go, I'll use them. I never took the time yet
to address them. Thus, I like Alan idea to prepare a set of shortcuts
that would match the existing ones. That way, we would have a common set
acting as a base for org users.

I will have a look at org-tempo, too, as it exists and easy to handle.

As for letting know the users, I think it's a very important part.
Could the ORG-NEWS clearly identify the expected breaking changes and
refer to a receipe for handling them ?

Also, would it be possible to add a link to the ORG-NEWS file in the
ELPA package description ? I don't think there is.

I know it exists, and that's where I went for my first breaking changes,
but if we can make it obvious for those would might not be long time
users, that would be great :-)


I any case, thank you for the awesome work you're all doing here.


Cheers,

Christophe


> It is a genuine question since I have no idea of the problems involved.
>
> I'll keep using org no matter what you decide!
>
> Cheers,
> Alan
>
>
> On 1 May 2018 at 08:49, Kaushal Modi <kaushal.modi@gmail.com> wrote:
>
>> Hi all,
>>
>> I normally am all for adapting to changes, staying on bleeding edges of
>> emacs, Org, etc.
>>
>> But FWIW, for this particular change to the "<s" Easy Templates, I'm in
>> the camp of "It was working awesome, it was beautiful! Why change it?". For
>> record, I understand the "why", but it just doesn't seem worth it in this
>> case.
>>
>> But the good thing is that this is open source, and you can backport the
>> stuff you like from the original Easy Template code into your personal
>> Emacs config (and then later adapt to the new way of doing the similar when
>> you have time and motivation).
>>
>> Kaushal
>> --
>>
>> Kaushal Modi
>>


--
--------------->  https://www.citadels.earth
Once it's perfectly aimed, the flying arrow goes straight to its target.
Thus, don't worry when things go right.
There will be enough time to worry about if they go wrong.
Then, it's time to fire a new arrow towards another direction.
Don't sink.  Adapt yourself !  The archer has to shoot accurately and quickly.
[Words of Erenthar, the bowman ranger] <---------------<<<<

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

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 2737 bytes --]

On 1 May 2018 at 08:39, Jon Snader <jcs@irreal.org> wrote:

>
> Tim Cross <theophilusx@gmail.com> writes:
>
> [Snip]
>>
>> Personally, I feel the new version should be the default and we should
>> provide an easy way to re-enable the old version for those who wish to
>> continue with what they are use to.
>>
>
> We already have this. The problem, as you say, is
>
> how we communicate this to existing users.
>>
>
> But here's what I don't understand: what, exactly, is so bad about
> leaving the old behavior enabled by default. The new behavior is still
> available and naive users don't get surprised. What's not to like?
>

The problem is that if the old behaviour remains as the default, then that
is what new users will be introduced to and the improved new functionality
won't be seen. If the new behaviour is the default, there will be a small
period of adjustment for existing users, but new users will be benefiting
from the changes immediately.  For many existing users, restoring the old
behaviour is just adding a require to their setup, so it isn't a lot to
ask. (I believe there will be some power users with lots of custom blocks
who may be more impacted, but as I understand it, whether the new or old
functionality is enabled by default doesn't really change the situation for
them anyway as they will have to take additional steps to migrate their
custom block settings). The real issue isn't about changing the default as
much as doing whatever is possible to inform existing users of the change
and how to restore previous behaviour if desired.

In the past, after an org upgrade, I have seen messages in the *Messages*
buffer regarding inconsistent, incompatible changes and what action needs
to be taken (I think this occurred when changes were made to TODO
templates). Maybe something along these lines could also be done - maybe
have a message displayed when someone tries to do a '<s' expansion and does
not have org-tempo loaded? Maybe this could be developed as something which
could be used in the future when we make other changes.

Along these same lines, maybe we need to consider adopting something
similar to the Emacs obsolete/deprecated  approach. In this next release,
add a message to org-tempo advising that this functionality will change in
the next release where org-tempo will not be loaded by default. This could
include a pointer to a web page explaining the change and associated
benefits and how to make the switch now if desired. While this might delay
the transition, it might address concerns regarding impact to existing
users and new users will be aware of the alternative etc. It would be
important to have a way to silence this message of course.



-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 3860 bytes --]

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

[Steve Downey]

[-- Attachment #1: Type: text/plain, Size: 3208 bytes --]

>>   For many existing users, restoring the old behaviour is just adding a
require to their setup, so it isn't a lot to ask.

Asking users to accept any breakage in the tool they use to get work done
is a lot. Changes in UI in emacs are opt-in.

Even if the change is the right thing to do.


On Mon, Apr 30, 2018 at 10:01 PM Tim Cross <theophilusx@gmail.com> wrote:

>
> On 1 May 2018 at 08:39, Jon Snader <jcs@irreal.org> wrote:
>
>>
>> Tim Cross <theophilusx@gmail.com> writes:
>>
>> [Snip]
>>>
>>> Personally, I feel the new version should be the default and we should
>>> provide an easy way to re-enable the old version for those who wish to
>>> continue with what they are use to.
>>>
>>
>> We already have this. The problem, as you say, is
>>
>> how we communicate this to existing users.
>>>
>>
>> But here's what I don't understand: what, exactly, is so bad about
>> leaving the old behavior enabled by default. The new behavior is still
>> available and naive users don't get surprised. What's not to like?
>>
>
> The problem is that if the old behaviour remains as the default, then that
> is what new users will be introduced to and the improved new functionality
> won't be seen. If the new behaviour is the default, there will be a small
> period of adjustment for existing users, but new users will be benefiting
> from the changes immediately.  For many existing users, restoring the old
> behaviour is just adding a require to their setup, so it isn't a lot to
> ask. (I believe there will be some power users with lots of custom blocks
> who may be more impacted, but as I understand it, whether the new or old
> functionality is enabled by default doesn't really change the situation for
> them anyway as they will have to take additional steps to migrate their
> custom block settings). The real issue isn't about changing the default as
> much as doing whatever is possible to inform existing users of the change
> and how to restore previous behaviour if desired.
>
> In the past, after an org upgrade, I have seen messages in the *Messages*
> buffer regarding inconsistent, incompatible changes and what action needs
> to be taken (I think this occurred when changes were made to TODO
> templates). Maybe something along these lines could also be done - maybe
> have a message displayed when someone tries to do a '<s' expansion and does
> not have org-tempo loaded? Maybe this could be developed as something which
> could be used in the future when we make other changes.
>
> Along these same lines, maybe we need to consider adopting something
> similar to the Emacs obsolete/deprecated  approach. In this next release,
> add a message to org-tempo advising that this functionality will change in
> the next release where org-tempo will not be loaded by default. This could
> include a pointer to a web page explaining the change and associated
> benefits and how to make the switch now if desired. While this might delay
> the transition, it might address concerns regarding impact to existing
> users and new users will be aware of the alternative etc. It would be
> important to have a way to silence this message of course.
>
>
>
> --
> regards,
>
> Tim
>
> --
> Tim Cross
>
>

[-- Attachment #2: Type: text/html, Size: 4670 bytes --]

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

[Nicolas Goaziou]

Hello,

Steve Downey <sdowney@gmail.com> writes:

> Asking users to accept any breakage in the tool they use to get work done
> is a lot. Changes in UI in emacs are opt-in.
>
> Even if the change is the right thing to do.

I think some of you (basically, anyone thinking we should enable "<s
TAB" by default ;)) are missing the point.


The first important thing to understand is that, even if we enable
`org-tempo' by default, next Org release /will break/ for some of us.

- It will break because `org-tempo' is only 99% backward-compatible.  So
  anyone having customizing templates is bound to change them.

- It will break because there are 9 other incompatible changes between
  9.1 and 9.2.

So, asking to load `org-tempo' by default just to avoid breaking users
set-up is a wrong argument. It will only "protect" those among us that
use "<s TAB" but didn't customize /and/ are not affected by the other
incompatible changes. IOW, updating Org from 9.1 to 9.2 will not be
smooth for everyone. No matter what `org-tempo' becomes.


The second important point is there is a general design issue at stake.
Sorry, there is no pleasure in inflicting "torture" (as I read in this
thread) to users.

    Org is too big. Its (lack of) design is wrong.

This is not from me, but from some the Emacs developers, in particular
Richard Stallman. You may want to read the thread "Differences between
Org-Mode and Hyperbole" in emacs-devel mailing list archives for the
exact quote.

Org has to be big, because it is featureful. Yet, we cannot ignore the
remark. Also, that doesn't mean we cannot do anything to improve the
situation. Actually, there are, at least, two areas in which we can make
progress:

1. externalize Org features that apply to other major modes, or drop
   them if there are equivalents to them,

2. re-using (external) Emacs facilities for Org mode features that are
   not central for us.

Not so long ago, we provided footnotes for other modes, even though
"footnote.el" had been there for a long time. This clearly felt into
(1), so we dropped the feature. Recently, I wrote "orgalist.el", which
ports Org plain lists into other modes. I moved it out of Org core
because of (1). It is now available in GNU ELPA.

Expansion templates are a great thing, but this is only sugar for Org,
which is totally usable without them. Besides, some facilities are
providing it for us. This falls into (2). By design, I'm convinced we
should not include them. I also wish that anyone involved in this thread
can take a step back to see the whole picture. 

The question is not about you using "<s TAB": you now know (require
'org-tempo) could solve this. The question is not about breaking other
configurations: there always have been breakage and there will be again.
The question is about designing Org so it fits well -- better, at
least -- in the Emacs ecosystem. This means no unreasonable feature
overlap and enough modularity to be re-usable from other parts in Emacs.


Back to the current poll. It would be more efficient to think about
solutions to make the update less painful. In particular, how can we
tell users updating from ELPA about the necessary changes involved.

I remember that Magit experimented displaying a message the first time
you used a new release; you would silence it only by setting a variable.
I don't think this is the case anymore, so it may have failed, though.
We could also make the <https://orgmode.org/Changes.html> page more
prominent in the summary displayed along with the package.


Now back to the poll.

Regards,

-- 
Nicolas Goaziou

P.S: Bastien, would you please stop lobbying in every other
communication canal out there, that's not fair ;)

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

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

[...]

> I think some of you (basically, anyone thinking we should enable "<s
> TAB" by default ;)) are missing the point.
> 
> 
> The first important thing to understand is that, even if we enable
> `org-tempo' by default, next Org release /will break/ for some of us.
> 
> - It will break because `org-tempo' is only 99% backward-compatible.  So
>   anyone having customizing templates is bound to change them.
> 
> - It will break because there are 9 other incompatible changes between
>   9.1 and 9.2.
> 
> So, asking to load `org-tempo' by default just to avoid breaking users
> set-up is a wrong argument. It will only "protect" those among us that
> use "<s TAB" but didn't customize /and/ are not affected by the other
> incompatible changes. IOW, updating Org from 9.1 to 9.2 will not be
> smooth for everyone. No matter what `org-tempo' becomes.

By this logic, since org 9.2 already contains 9 breaking changes, we can
change anything else in that version.  Make all the key bindings start
with M-S-C-e instead of C-c, sort all the headings in a file in
alphabetical order when opening it, ...

No software update will ever be entirely disruption-free, if nothing
else because bugs will always happen.  So we have to think about the
impact of (intentional) changes not in a binary Yes/No fashion, but in
terms of how many users they affect, and how bad that effect is.  In
this case, the number affected is large (as measured informally by
participation in this poll) and the disruption is severe (a specifically
documented org feature now doesnʼt work, with no obviously discoverable
reason why).  So that is a powerful argument against making the change
in this way, when we can achieve the same long-term effect in a less
disruptive way (with deprecation warnings).

I do think that breaking changes should be grouped into batches.  And
if org has as many as ten that are pending, it is a strong argument to
call the next release version 10, with all the associated fanfare (and
breakage warnings!)  Or if point releases are needed in the meantime,
hold these breaking changes on a branch that can be merged before Org
10.


[...]

> Expansion templates are a great thing, but this is only sugar for Org,
> which is totally usable without them. Besides, some facilities are
> providing it for us. This falls into (2). By design, I'm convinced we
> should not include them. I also wish that anyone involved in this thread
> can take a step back to see the whole picture.

This is a red herring.  The changes do not eliminate expansion template
code from org.  They merely substitute (incompatibly) one expansion
template mechanism for a new one.

FWIW, I do think the idea is worth exploring of getting rid of the (old
and new) template expansion code and using emacsʼs built-in SRecode
template facility.  Like most of the CEDET stuff, it looks horridly
overengineered at a first glance.  But it is also included with emacs by
default (unlike e.g. yasnippet which otherwise looks more pleasant to
program to me), and it would be (even more) responsive to the concerns
from emacs-devel that were quoted in your full message.  To be specific,
this would entail (eventually) getting rid of the
org-structure-template-alist variable entirely, as well as the menu now
bound to C-c C-,; the former would be replaced by (AFAIUI) template
files that would be included with org and/or created by users for their
custom templates; the latter would use SRecodeʼs built-in template
selection instead.

-- 
Aaron Ecay

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

[Rasmus]

Aaron Ecay <aaronecay@gmail.com> writes:

>> Expansion templates are a great thing, but this is only sugar for Org,
>> which is totally usable without them. Besides, some facilities are
>> providing it for us. This falls into (2). By design, I'm convinced we
>> should not include them. I also wish that anyone involved in this thread
>> can take a step back to see the whole picture.
>
> This is a red herring.  The changes do not eliminate expansion template
> code from org.  They merely substitute (incompatibly) one expansion
> template mechanism for a new one.
>
> FWIW, I do think the idea is worth exploring of getting rid of the (old
> and new) template expansion code and using emacsʼs built-in SRecode
> template facility.  Like most of the CEDET stuff, it looks horridly
> overengineered at a first glance.  But it is also included with emacs by
> default (unlike e.g. yasnippet which otherwise looks more pleasant to
> program to me), and it would be (even more) responsive to the concerns
> from emacs-devel that were quoted in your full message.  To be specific,
> this would entail (eventually) getting rid of the
> org-structure-template-alist variable entirely, as well as the menu now
> bound to C-c C-,; the former would be replaced by (AFAIUI) template
> files that would be included with org and/or created by users for their
> custom templates; the latter would use SRecodeʼs built-in template
> selection instead.


Cool, I at least did not know that one.
Can you a reproducible way to try it out?
Without having to make my own templates etc.

Rasmus

-- 
Not everything that goes around comes back around, you know

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

[Aaron Ecay]

Hi Rasmus,

2018ko maiatzak 5an, Rasmus-ek idatzi zuen:

> Cool, I at least did not know that one.
> Can you a reproducible way to try it out?
> Without having to make my own templates etc.

I havenʼt done anything with it myself.

You can open up a blank .el file and test out some of emacsʼs built-in
templates.  M-x srecode-minor-mode, and then “C-c / /” will prompt you for
the name of a template to insert.  Entering file:major-mode at the
resulting prompt might be the most interesting one.  Certain keys are
bound to common templates, examples are “C-c / f” for inserting a function
and “C-c / v” for a variable

The template file corresponding to this is located at
$YOUR_EMACS_INSTALL_DIR/etc/srecode/el.srt.

Just as an aside, I have now also learned that emacs also includes
skeleton.el, which is yet a third template expansion library.  Sigh.

-- 
Aaron Ecay

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

[Tim Cross]

> Just as an aside, I have now also learned that emacs also includes
> skeleton.el, which is yet a third template expansion library.  Sigh.

also why we have yasnippets (yet another snippet for emacs).

If lisp languages have a flaw, this is probably it - often, people find
it easier to re-write functionality in a new library rather than
spending time learning the API and underlying philosophy/mindset of a
3rp party. Understandable as we all prefer coding to reading manuals and
APIs! I guess this is also one of the motivations to not implement yet
another template system if it can be avoided.

I have used both tempo and skeleton mode in the past. From memory,
skeleton's strength was with fairly static templates e.g. copyright
notice (though there is a mode for that as well!). Tempo was the one I
used most often, but have to say, writing tempo templates is a bit of a
pain and they are awfully ugly (at least mine were!).

These days, I seem to be using yasnippets most of the time. It isn't
because it is the best template solution, but rather it is because it
seems to be incorporated into many other modes I use and I can often
just install a package which has 80% of the snippets I need for a
specific mode. I suspect it is a bit of a VHS v Betamax situation -
yasnippets may not be the best solution, but it seems to have grabbed
largest market share!

Tim




-- 
Tim Cross

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

[Rasmus]

Aaron Ecay <aaronecay@gmail.com> writes:

> Hi Rasmus,
>
> 2018ko maiatzak 5an, Rasmus-ek idatzi zuen:
>
>> Cool, I at least did not know that one.
>> Can you a reproducible way to try it out?
>> Without having to make my own templates etc.
>
> I havenʼt done anything with it myself.
>
> You can open up a blank .el file and test out some of emacsʼs built-in
> templates.  M-x srecode-minor-mode, and then “C-c / /” will prompt you for
> the name of a template to insert.  Entering file:major-mode at the
> resulting prompt might be the most interesting one.  Certain keys are
> bound to common templates, examples are “C-c / f” for inserting a function
> and “C-c / v” for a variable

Srecode seems pretty neat, though it might only work in file buffers.
Other than being shipped with Emacs, does it have any advantage over yas?
Are there any plans to merge the two or make them more compatible?

> Just as an aside, I have now also learned that emacs also includes
> skeleton.el, which is yet a third template expansion library.  Sigh.

I think it was too restrictive.  I think I also tried abbrev and found it
not sufficient.

Rasmus

-- 
It was you, Jezebel, it was you

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

[Aaron Ecay]

Hi Rasmus,

2018ko maiatzak 7an, Rasmus-ek idatzi zuen:
> Srecode seems pretty neat, though it might only work in file buffers.
> Other than being shipped with Emacs, does it have any advantage over yas?
> Are there any plans to merge the two or make them more compatible?

Not AFAIK (to both questions).  Yasnippet is in GNU ELPA, so the barrier
to it becoming integrated into emacs (in whatever way) is low (or at
least, not dominated by questions of copyright assignment).

> 
> I think [skeleton.el] was too restrictive.  I think I also tried
> abbrev and found it not sufficient.

Itʼs a pity.  In an ideal world emacs would have only one built-in
template expansion system which we could build on, instead of 3-4
(depending on whether you count abbrev).  But, this is the world we
live in.  (This is certainly not a criticism of org-tempo btw!)

From another message in the thread:

> Thanks.  I guess it would be enough to check if the elements of the alist
> are cons (newer Orgs) or lists (older orgs).  A more "complex" procedure
> could look for at the content of the ca?dr, I guess, but I don’t know if
> that’s necessary.

AIUI the change was from a cons of (character, template string) to a
cons of (string, template string).  The relevant commit is b56df73.

-- 
Aaron Ecay

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

[Bastien]

Hi Aaron,

Aaron Ecay <aaronecay@gmail.com> writes:

> Not AFAIK (to both questions).  Yasnippet is in GNU ELPA, so the barrier
> to it becoming integrated into emacs (in whatever way) is low (or at
> least, not dominated by questions of copyright assignment).

I think the barrier is pretty high, because the general trend is
rather to move things *out* of Emacs.

-- 
 Bastien

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

[Rasmus]

Aaron Ecay <aaronecay@gmail.com> writes:

> AIUI the change was from a cons of (character, template string) to a
> cons of (string, template string).  The relevant commit is b56df73.

That’s an irrelevant change as neither of those formats has been
published.  The "old" format (9.1 and earlier) is a list of (key
template-string), e.g.

   ("s" "#+BEGIN_SRC ?

   #+END_SRC")

The new is something like

   ("s" . "src")

Rasmus

-- 
I feel emotional landscapes they puzzle me

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

[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-
 > bounces+mec=stowers.org@gnu.org> On Behalf Of Nicolas Goaziou
 > Sent: Tuesday, May 01, 2018 7:36 AM
 > To: Steve Downey <sdowney@gmail.com>
 > Cc: Bastien <bzg@gnu.org>; Tim Cross <theophilusx@gmail.com>; Org-
 > mode <emacs-orgmode@gnu.org>; Jon Snader <jcs@irreal.org>
 > Subject: Re: [O] [POLL] Should Org tempo be enabled by default? (expand
 > templates thru e.g. "<s[TAB]")
 > 
 > Hello,
 > 
 > Steve Downey <sdowney@gmail.com> writes:
 > 
 > > Asking users to accept any breakage in the tool they use to get work done
 > > is a lot. Changes in UI in emacs are opt-in.
 > >
 > > Even if the change is the right thing to do.
 > 
 > I think some of you (basically, anyone thinking we should enable "<s
 > TAB" by default ;)) are missing the point.
 > 
 > 
 > The first important thing to understand is that, even if we enable
 > `org-tempo' by default, next Org release /will break/ for some of us.
 > 
 > - It will break because `org-tempo' is only 99% backward-compatible.  So
 >   anyone having customizing templates is bound to change them.
 > 
 > - It will break because there are 9 other incompatible changes between
 >   9.1 and 9.2.
 > 
 > So, asking to load `org-tempo' by default just to avoid breaking users
 > set-up is a wrong argument. It will only "protect" those among us that
 > use "<s TAB" but didn't customize /and/ are not affected by the other
 > incompatible changes. IOW, updating Org from 9.1 to 9.2 will not be
 > smooth for everyone. No matter what `org-tempo' becomes.
 > 
 > 
 > The second important point is there is a general design issue at stake.
 > Sorry, there is no pleasure in inflicting "torture" (as I read in this
 > thread) to users.
 > 
 >     Org is too big. Its (lack of) design is wrong.
 > 
 > This is not from me, but from some the Emacs developers, in particular
 > Richard Stallman. You may want to read the thread "Differences between
 > Org-Mode and Hyperbole" in emacs-devel mailing list archives for the
 > exact quote.
 > 
 > Org has to be big, because it is featureful. Yet, we cannot ignore the
 > remark. Also, that doesn't mean we cannot do anything to improve the
 > situation. Actually, there are, at least, two areas in which we can make
 > progress:
 > 
 > 1. externalize Org features that apply to other major modes, or drop
 >    them if there are equivalents to them,
 > 
 > 2. re-using (external) Emacs facilities for Org mode features that are
 >    not central for us.
 > 
 > Not so long ago, we provided footnotes for other modes, even though
 > "footnote.el" had been there for a long time. This clearly felt into
 > (1), so we dropped the feature. Recently, I wrote "orgalist.el", which
 > ports Org plain lists into other modes. I moved it out of Org core
 > because of (1). It is now available in GNU ELPA.
 > 
 > Expansion templates are a great thing, but this is only sugar for Org,
 > which is totally usable without them. Besides, some facilities are
 > providing it for us. This falls into (2). By design, I'm convinced we
 > should not include them. I also wish that anyone involved in this thread
 > can take a step back to see the whole picture.
 > 
 > The question is not about you using "<s TAB": you now know (require
 > 'org-tempo) could solve this. The question is not about breaking other
 > configurations: there always have been breakage and there will be again.
 > The question is about designing Org so it fits well -- better, at
 > least -- in the Emacs ecosystem. This means no unreasonable feature
 > overlap and enough modularity to be re-usable from other parts in Emacs.
 > 
 > 
 > Back to the current poll. It would be more efficient to think about
 > solutions to make the update less painful. In particular, how can we
 > tell users updating from ELPA about the necessary changes involved.
 > 
 > I remember that Magit experimented displaying a message the first time
 > you used a new release; you would silence it only by setting a variable.
 > I don't think this is the case anymore, so it may have failed, though.
 > We could also make the <https://orgmode.org/Changes.html> page more
 > prominent in the summary displayed along with the package.
 > 
 > 
 > Now back to the poll.
 > 
 > Regards,
 > 
 > --
 > Nicolas Goaziou
 > 
 > P.S: Bastien, would you please stop lobbying in every other
 > communication canal out there, that's not fair ;)

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

[Rasmus]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Steve Downey <sdowney@gmail.com> writes:
>
>> Asking users to accept any breakage in the tool they use to get work done
>> is a lot. Changes in UI in emacs are opt-in.
>>
>> Even if the change is the right thing to do.
>
> I think some of you (basically, anyone thinking we should enable "<s
> TAB" by default ;)) are missing the point.
>
>
> The first important thing to understand is that, even if we enable
> `org-tempo' by default, next Org release /will break/ for some of us.
>
> - It will break because `org-tempo' is only 99% backward-compatible.  So
>   anyone having customizing templates is bound to change them.
>
> - It will break because there are 9 other incompatible changes between
>   9.1 and 9.2.
>
> So, asking to load `org-tempo' by default just to avoid breaking users
> set-up is a wrong argument. It will only "protect" those among us that
> use "<s TAB" but didn't customize /and/ are not affected by the other
> incompatible changes. IOW, updating Org from 9.1 to 9.2 will not be
> smooth for everyone. No matter what `org-tempo' becomes.

Nicolas, I have been wondering about something, reading all these posts,
irrespective of whether tempo is loaded by default or not (I don’t care).

Do you think org-tempo should try to detect "old" versions of
org-structure-template-alist and give a better error if it sees one?  I
don’t know what the "best practice" is this case...

Thanks,
Rasmus

-- 
When in doubt, do it!

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

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 1754 bytes --]

On Sat, May 5, 2018 at 8:02 PM Rasmus <rasmus@gmx.us> wrote:

> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
> > Hello,
> >
> > Steve Downey <sdowney@gmail.com> writes:
> >
> >> Asking users to accept any breakage in the tool they use to get work
> done
> >> is a lot. Changes in UI in emacs are opt-in.
> >>
> >> Even if the change is the right thing to do.
> >
> > I think some of you (basically, anyone thinking we should enable "<s
> > TAB" by default ;)) are missing the point.
> >
> >
> > The first important thing to understand is that, even if we enable
> > `org-tempo' by default, next Org release /will break/ for some of us.
> >
> > - It will break because `org-tempo' is only 99% backward-compatible.  So
> >   anyone having customizing templates is bound to change them.
> >
> > - It will break because there are 9 other incompatible changes between
> >   9.1 and 9.2.
> >
> > So, asking to load `org-tempo' by default just to avoid breaking users
> > set-up is a wrong argument. It will only "protect" those among us that
> > use "<s TAB" but didn't customize /and/ are not affected by the other
> > incompatible changes. IOW, updating Org from 9.1 to 9.2 will not be
> > smooth for everyone. No matter what `org-tempo' becomes.
>
> Nicolas, I have been wondering about something, reading all these posts,
> irrespective of whether tempo is loaded by default or not (I don’t care).
>
> Do you think org-tempo should try to detect "old" versions of
> org-structure-template-alist and give a better error if it sees one?  I
> don’t know what the "best practice" is this case...
>

Yes, it absolutely should.

Carsten


>
> Thanks,
> Rasmus
>
> --
> When in doubt, do it!
>
>
>

[-- Attachment #2: Type: text/html, Size: 2550 bytes --]

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

[Rasmus]

Carsten Dominik <dominik@uva.nl> writes:

> On Sat, May 5, 2018 at 8:02 PM Rasmus <rasmus@gmx.us> wrote:
>
>> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>>
>> > Hello,
>> >
>> > Steve Downey <sdowney@gmail.com> writes:
>> >
>> >> Asking users to accept any breakage in the tool they use to get work
>> done
>> >> is a lot. Changes in UI in emacs are opt-in.
>> >>
>> >> Even if the change is the right thing to do.
>> >
>> > I think some of you (basically, anyone thinking we should enable "<s
>> > TAB" by default ;)) are missing the point.
>> >
>> >
>> > The first important thing to understand is that, even if we enable
>> > `org-tempo' by default, next Org release /will break/ for some of us.
>> >
>> > - It will break because `org-tempo' is only 99% backward-compatible.  So
>> >   anyone having customizing templates is bound to change them.
>> >
>> > - It will break because there are 9 other incompatible changes between
>> >   9.1 and 9.2.
>> >
>> > So, asking to load `org-tempo' by default just to avoid breaking users
>> > set-up is a wrong argument. It will only "protect" those among us that
>> > use "<s TAB" but didn't customize /and/ are not affected by the other
>> > incompatible changes. IOW, updating Org from 9.1 to 9.2 will not be
>> > smooth for everyone. No matter what `org-tempo' becomes.
>>
>> Nicolas, I have been wondering about something, reading all these posts,
>> irrespective of whether tempo is loaded by default or not (I don’t care).
>>
>> Do you think org-tempo should try to detect "old" versions of
>> org-structure-template-alist and give a better error if it sees one?  I
>> don’t know what the "best practice" is this case...
>>
>
> Yes, it absolutely should.

Thanks.  I guess it would be enough to check if the elements of the alist
are cons (newer Orgs) or lists (older orgs).  A more "complex" procedure
could look for at the content of the ca?dr, I guess, but I don’t know if
that’s necessary.

Rasmus

-- 
I feel emotional landscapes they puzzle me

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

[Bastien]

Hi Rasmus,

Rasmus <rasmus@gmx.us> writes:

> Do you think org-tempo should try to detect "old" versions of
> org-structure-template-alist and give a better error if it sees one?

Yes, it definitely should detect old format and fix it.

-- 
 Bastien

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

[Rasmus]

Bastien <bzg@gnu.org> writes:

> Hi Rasmus,
>
> Rasmus <rasmus@gmx.us> writes:
>
>> Do you think org-tempo should try to detect "old" versions of
>> org-structure-template-alist and give a better error if it sees one?
>
> Yes, it definitely should detect old format and fix it.

I don’t remember if I replied to this or not.

In any case, it will not be able to "fix" an old template, as it can be
much more complex than the new syntax.

I would simply raise an error with a helpful text if the "old" format is
detected.

Rasmus

-- 
m-mm-mmm-mmmm bacon!

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

[Adrian Bradd]

> I remember that Magit experimented displaying a message the 
> first time
> you used a new release; you would silence it only by setting a 
> variable.
> I don't think this is the case anymore, so it may have failed, 
> though.

I believe this was for the Magit Kickstarter fundraiser. A message 
was displayed to notify users and direct them to the page. This 
message stayed in place until the Kickstarter was completed, but 
could be disabled prematurely by altering a variable. I can't 
speak to its success or failure overall, but there were some 
complaints about the method [1].

> We could also make the <https://orgmode.org/Changes.html> page 
> more
> prominent in the summary displayed along with the package.

This seems like a step in the right direction. Perhaps adding a 
section to the Introduction in the manual about the changes page 
or ORG-NEWS and their importance with major or .X releases might 
help.

My experience as a newcomer to org with the 8.x to 9.x transition 
was that most of the posts relating to org at the time (on reddit 
at least) mentioned breaking changes and the ORG-NEWS file.

With regard to the poll, I don't have a strong opinion as I am now 
using yasnippet with org. When I was using org-tempo I didn't see 
any issue with having to require it in my init. So I suppose my 
vote would be that disabling by default is 
fine. `org-insert-structure-template' bound to a key seems like a 
reasonable alternative especially since it operates on regions.

Cheers,

[1] https://github.com/magit/magit/issues/3174

--
Adrian

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

[Josiah Schwab]

On  5 May 2018 at 16:26 PDT, Adrian Bradd wrote:

>> I remember that Magit experimented displaying a message the first
>> time you used a new release; you would silence it only by setting a
>> variable.  I don't think this is the case anymore, so it may have
>> failed, though.
>
> I believe this was for the Magit Kickstarter fundraiser. A message was
> displayed to notify users and direct them to the page.

No, I believe what was being referenced was this:

  https://github.com/magit/magit/issues/1803

Josiah

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

[Bastien]

Hi Nicolas,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> The first important thing to understand is that, even if we enable
> `org-tempo' by default, next Org release /will break/ for some of us.
>
> - It will break because `org-tempo' is only 99% backward-compatible.  So
>   anyone having customizing templates is bound to change them.

I propose to make it 100% backward-compatible.

> - It will break because there are 9 other incompatible changes between
>   9.1 and 9.2.

It is not because many things will break that we should not fix that
one thing - quite on the contrary: it's because we think "that thing
can break, it's okay" that many things will break.

>     Org is too big. Its (lack of) design is wrong.
>
> This is not from me, but from some the Emacs developers, in particular
> Richard Stallman. You may want to read the thread "Differences between
> Org-Mode and Hyperbole" in emacs-devel mailing list archives for the
> exact quote.

Quoting RMS exact words:

  Org mode is an example of how Emacs development went astray.

  https://lists.gnu.org/archive/html/emacs-devel/2016-06/msg00272.html

FWIW I agree with John's answer:

  However, the super-tight coupling of Org-mode's features allows them
  to cooperate in ways that are usually "to the point", and sometimes
  elegant.

  https://lists.gnu.org/archive/html/emacs-devel/2016-06/msg00273.html

> The question is about designing Org so it fits well -- better, at
> least -- in the Emacs ecosystem. This means no unreasonable feature
> overlap and enough modularity to be re-usable from other parts in
> Emacs.

Sometimes we will need to externalize an Org feature to not reinvent
the wheel unnecessarily and to provide it as a separate package, and
orgalist.el is a good example of that.

Sometimes we will add functionalities in Org's core by reusing core
Emacs features.

Using tempo.el to let Org easily insert templates is a natural thing
to do, especially because Org *has* structures like #+begin...#+end
that exactly match the need for template insertion.

Vim users like to make fun of Emacs because it does too much.  But
Emacs users don't understand why this would be laughable... because
Emacs *rocks*.

I'd like Org to keep the same level of awesomeness.

-- 
 Bastien