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