Survey: changing a few default settings for Org 9.4

Survey: changing a few default settings for Org 9.4

[Bastien]

Hi all,

while Org 9.4 is on its way, I am considering changing a few default
settings (10 options in total).  I have created a survey here:

https://framadate.org/Ufc42EVxS2jO1Ajz

Can you take a few minutes and express your opinion there?

Here is the list of options and a line of justification - feel free to
discuss this on the mailing list too, of course.

- org-loop-over-headlines-in-active-region => t

  This option was not documented in the manual until recently.  It is
  useful to act on several headlines in the region.  When you select a
  region, it feels natural to expect some commands to act specially on
  the selected region.

- org-agenda-loop-over-headlines-in-active-region => t

  Same for the agenda: the feature has been added in Org 9.4.  It
  makes things really easier than bulk marking entries when bulking
  marking in a row.

- org-fontify-done-headline => t

  This is useful to visualize done headlines and can be easily turned
  off, while not being easily discovered for Org newcomers.

- org-hide-emphasis-markers => t
- org-hide-macro-markers => t

  The two changes proposed above will probably trigger some reactions
  as they touch something very sensitive: whether Org should try to be
  "too clever" at making things invisible.  I am all for letting Org
  newcomers enjoying these visual enhancements, while letting experts
  turning them off if needed.

- org-refile-use-cache => t

  This is a speed boost when refiling entries: if org-refile-targets
  is big, caching refile targets help refiling faster.

- org-special-ctrl-k => t

  The default value for the sister option org-special-ctrl-a is set to
  reversed and while this changes a fundamental Emacs command behavior
  it feels useful.  I'd argue this is the same for org-special-ctrl-k:
  setting it to t will feel natural.

- org-src-tab-acts-natively => t

  I believe that's the natural expectation when using TAB in a source
  block.  Things can be brittle in this area, but turning this on will
  provide a better experience to everyone.

- org-allow-promoting-top-level-subtree => t

  With the current default of nil, an error is thrown when the user
  tries to promote a top level subtree.  The new default setting would
  let users convert the top level heading to a commented heading.
  
- Add org-tempo to org-modules

  Last but not least: we had long discussions about this one in the
  past.  Expansion of the "<s" templates (and other "<*" templates) at
  the beginning of the line has been turned off.  I have IRL met with
  Org users* who just thought the feature was broken/deleted, without
  having/taking the time/knowledge/guts to look for the things they
  can turn on.  I am all for turning this on again, letting experts
  disabling the feature if they don't want it.

  * We have regular meetings with https://www.emacs-doctor.com/

Thanks in advance for your feedback.

Changing defaults is always a sensitive matter.

There are generally two points of view confronting themselves: those
who take side with the "beginners" or the "don't-have-time-to-config"
(although these are just abstract figures here), and those insisting
that default are "for everyone", beginners, non-configurers, experts.

I think both sides are correct, provided we consider Org's experience
as something *dynamic* in time, a learning process.  So good defaults
are a balance between beginners/non-configurers experience and that of
experts.

In any case, let's keep the discussion as constructive as possible.

Thanks!

-- 
 Bastien

Re: Survey: changing a few default settings for Org 9.4

[Samuel Wales]

On 2/19/20, Bastien <bzg@gnu.org> wrote:
> - org-refile-use-cache => t
>
>   This is a speed boost when refiling entries: if org-refile-targets
>   is big, caching refile targets help refiling faster.

i predict this will generate bug reports.

in particular pay close attention to restricted refile and whether
caching works for both it and unrestricted refile.

it is better to change the thing being cached to be faster if possible.

i agree speed is needed.

org's biggest issue imo is speed.  this will be increasingly apparent
as users use org for more data, moore's law falters, and emacs
continues to rely on a single core.

i am not saying don't change the default or change the default.

just saying if you do, then be careful.


-- 
The Kafka Pandemic

What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

Re: Survey: changing a few default settings for Org 9.4

[Bastien]

Hi Samuel,

thanks for your feedback.

Samuel Wales <samologist@gmail.com> writes:

> On 2/19/20, Bastien <bzg@gnu.org> wrote:
>> - org-refile-use-cache => t
>>
>>   This is a speed boost when refiling entries: if org-refile-targets
>>   is big, caching refile targets help refiling faster.
>
> i predict this will generate bug reports.

Yes, that's to be expected - for this change and maybe others.  This
is also the purpose of this proposal: help to track and fix bugs that
may not yet surface because the feature is unknown to most users.

-- 
 Bastien

Re: Survey: changing a few default settings for Org 9.4

[Samuel Wales]

just an idea but changing the subscript and superscript export feature
to ‘{}’ would reduce accidental invocation.  i have seen solecistic
subscripts on websites created with org (probably by experts who
babelize their .emacs!), and on this ml :).

i have seen it used accidentally more than i have seen it used for its
intended purpose.  {} seems more unambiguous.

that would, of course, be an issue for those who already have a lot of
the short form in their technical and scientific papers.

so there would have to be a nice regexp fixer.  or a warning.

-- 
The Kafka Pandemic

What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

Re: Survey: changing a few default settings for Org 9.4

[Marcin Borkowski]

On 2020-02-19, at 21:02, Samuel Wales <samologist@gmail.com> wrote:

> just an idea but changing the subscript and superscript export feature
> to ‘{}’ would reduce accidental invocation.  i have seen solecistic
> subscripts on websites created with org (probably by experts who
> babelize their .emacs!), and on this ml :).
>
> i have seen it used accidentally more than i have seen it used for its
> intended purpose.  {} seems more unambiguous.
>
> that would, of course, be an issue for those who already have a lot of
> the short form in their technical and scientific papers.
>
> so there would have to be a nice regexp fixer.  or a warning.

+1!!!

There is already an option for that (~org-use-sub-superscripts~).
Changing the default to `{} seems a great idea.

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: Survey: changing a few default settings for Org 9.4

[Bastien]

Hi Samuel and Marcin,

Marcin Borkowski <mbork@mbork.pl> writes:

> There is already an option for that (~org-use-sub-superscripts~).
> Changing the default to `{} seems a great idea.

I didn't identify this possible change -- other ideas for new defaults
are welcome, of course.

I'm not sure about this one: since org-pretty-entities is nil by
default, the default for org-use-sub-superscripts only affects the
user when he toggle super- and subscript fontification with M-x
org-toggle-pretty-entities RET -- or the default really a problem?

I've slightly enhanced the documentation in this area, though.

-- 
 Bastien

Re: Survey: changing a few default settings for Org 9.4

[Samuel Wales]

in my old version at least, pretty entities talks about utf-8 and \name.

and the option under discussion does not mention pretty entitities.

dunno abou the implementation or any changes since my version,
but i am arguing from empiricism.  the errors are all over the web.  :)


On 2/19/20, Bastien <bzg@gnu.org> wrote:
> Hi Samuel and Marcin,
>
> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> There is already an option for that (~org-use-sub-superscripts~).
>> Changing the default to `{} seems a great idea.
>
> I didn't identify this possible change -- other ideas for new defaults
> are welcome, of course.
>
> I'm not sure about this one: since org-pretty-entities is nil by
> default, the default for org-use-sub-superscripts only affects the
> user when he toggle super- and subscript fontification with M-x
> org-toggle-pretty-entities RET -- or the default really a problem?
>
> I've slightly enhanced the documentation in this area, though.
>
> --
>  Bastien
>


-- 
The Kafka Pandemic

What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

Re: Survey: changing a few default settings for Org 9.4

[Marco Wahl]

Bastien <bzg@gnu.org> writes:

> while Org 9.4 is on its way, I am considering changing a few default
> settings (10 options in total).  I have created a survey here:
>
> https://framadate.org/Ufc42EVxS2jO1Ajz
>
> Can you take a few minutes and express your opinion there?

Ok.  I'll go there in a minute.

> Here is the list of options and a line of justification - feel free to
> discuss this on the mailing list too, of course.

These changes look good to me.  Thanks for bringing this up.  Find a few
comments and a question below.

> - org-loop-over-headlines-in-active-region => t

I vote for => 'start-level.  Loop over headlines with same level as the
first.

> - org-agenda-loop-over-headlines-in-active-region => t
> - org-fontify-done-headline => t
> - org-hide-emphasis-markers => t
> - org-hide-macro-markers => t
> - org-refile-use-cache => t

> - org-special-ctrl-k => t
>
>   The default value for the sister option org-special-ctrl-a is set to
>   reversed and while this changes a fundamental Emacs command behavior
>   it feels useful.  I'd argue this is the same for org-special-ctrl-k:
>   setting it to t will feel natural.

AFAICS there is a contradiction between the documentation of
org-special-ctrl-k and the code!  Doc: kill the tags.  Code:
(org-align-tags).

Further I propose to delete the part " and possible the folded subtree
below the line" from the documentation.

> - org-src-tab-acts-natively => t
> - org-allow-promoting-top-level-subtree => t

Just an idea for the "reverse": provide a function to convert a comment
line to a heading (one level below the current level) and demote the
subtrees below.

> - Add org-tempo to org-modules

>   * We have regular meetings with https://www.emacs-doctor.com/

What are these meetings?


Thanks.

Re: Survey: changing a few default settings for Org 9.4

[Bastien]

Hi Marco,

Marco Wahl <marcowahlsoft@gmail.com> writes:

>> - org-loop-over-headlines-in-active-region => t
>
> I vote for => 'start-level.  Loop over headlines with same level as the
> first.

Yes, good suggestion.

>> - org-special-ctrl-k => t
>>
>>   The default value for the sister option org-special-ctrl-a is set to
>>   reversed and while this changes a fundamental Emacs command behavior
>>   it feels useful.  I'd argue this is the same for org-special-ctrl-k:
>>   setting it to t will feel natural.
>
> AFAICS there is a contradiction between the documentation of
> org-special-ctrl-k and the code!  Doc: kill the tags.  Code:
> (org-align-tags).
>
> Further I propose to delete the part " and possible the folded subtree
> below the line" from the documentation.

Can you propose a patch against the maint branch for the fixes above?

>> - org-src-tab-acts-natively => t
>> - org-allow-promoting-top-level-subtree => t
>
> Just an idea for the "reverse": provide a function to convert a comment
> line to a heading (one level below the current level) and demote the
> subtrees below.

I don't think converting a comment to a headline is a common use case.

>>   * We have regular meetings with https://www.emacs-doctor.com/
>
> What are these meetings?

We gather with fellow Emacsers in Paris once in a while.

-- 
 Bastien

Re: Survey: changing a few default settings for Org 9.4

[Marco Wahl]

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

Hi!

>>> - org-loop-over-headlines-in-active-region => t
>>
>> I vote for => 'start-level.  Loop over headlines with same level as the
>> first.
>
> Yes, good suggestion.

Let's see what others say.

>>> - org-special-ctrl-k => t
>>>
>>>   The default value for the sister option org-special-ctrl-a is set to
>>>   reversed and while this changes a fundamental Emacs command behavior
>>>   it feels useful.  I'd argue this is the same for org-special-ctrl-k:
>>>   setting it to t will feel natural.
>>
>> AFAICS there is a contradiction between the documentation of
>> org-special-ctrl-k and the code!  Doc: kill the tags.  Code:
>> (org-align-tags).
>>
>> Further I propose to delete the part " and possible the folded subtree
>> below the line" from the documentation.
>
> Can you propose a patch against the maint branch for the fixes above?

Sure.  See the attachments.

>>> - org-src-tab-acts-natively => t
>>> - org-allow-promoting-top-level-subtree => t
>>
>> Just an idea for the "reverse": provide a function to convert a comment
>> line to a heading (one level below the current level) and demote the
>> subtrees below.
>
> I don't think converting a comment to a headline is a common use case.

Ok.  That was just an idea.

>>>   * We have regular meetings with https://www.emacs-doctor.com/
>>
>> What are these meetings?
>
> We gather with fellow Emacsers in Paris once in a while.

Ahhh!  Paris!  Thanks for the information.  Paris is out of my reach, though.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-Fix-corner-case-for-org-kill-line.patch --]
[-- Type: text/x-patch, Size: 820 bytes --]

From 49b00d2cf7ca4b8484e0a9679b39b62873ee30b6 Mon Sep 17 00:00:00 2001
From: Marco Wahl <marcowahlsoft@gmail.com>
Date: Wed, 19 Feb 2020 13:48:01 +0100
Subject: [PATCH 1/2] org: Fix corner case for org-kill-line

* lisp/org.el (org-kill-line): Kill _all_ tags when the cursor is on the tags part.
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index f7547eba1..f4fe76f82 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -20392,7 +20392,7 @@ depending on context."
 		 (skip-chars-backward " \t")
 		 (point))))
       (if (<= end (point))		;on tags part
-	  (kill-region (point) (line-end-position))
+	  (kill-region end (line-end-position))
 	(kill-region (point) end)))
     (org-align-tags))
    (t (kill-region (point) (line-end-position)))))
-- 
2.25.1


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-org-Remove-irritating-documentation-line.patch --]
[-- Type: text/x-patch, Size: 928 bytes --]

From a81744de15f42d1817482f2209f555a959e9e66c Mon Sep 17 00:00:00 2001
From: Marco Wahl <marcowahlsoft@gmail.com>
Date: Wed, 19 Feb 2020 13:51:01 +0100
Subject: [PATCH 2/2] org: Remove irritating documentation line

* lisp/org.el (org-special-ctrl-k): Omit irritating documentation line.
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index f4fe76f82..7327bfe21 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -1575,7 +1575,7 @@ When nil, `C-k' will call the default `kill-line' command.
 When t, the following will happen while the cursor is in the headline:
 
 - When the cursor is at the beginning of a headline, kill the entire
-  line and possible the folded subtree below the line.
+  line.
 - When in the middle of the headline text, kill the headline up to the tags.
 - When after the headline text, kill the tags."
   :group 'org-edit-structure
-- 
2.25.1

Re: Survey: changing a few default settings for Org 9.4

[Bastien]

Hi Marco,

Marco Wahl <marcowahlsoft@gmail.com> writes:

>> Can you propose a patch against the maint branch for the fixes above?
>
> Sure.  See the attachments.

Thanks...

> From 49b00d2cf7ca4b8484e0a9679b39b62873ee30b6 Mon Sep 17 00:00:00 2001
> From: Marco Wahl <marcowahlsoft@gmail.com>
> Date: Wed, 19 Feb 2020 13:48:01 +0100
> Subject: [PATCH 1/2] org: Fix corner case for org-kill-line
>
> * lisp/org.el (org-kill-line): Kill _all_ tags when the cursor is on the tags part.

There is a problem with this patch: when on a empty heading with tags,
killing the tags will let the cursor back right after the last "*".
Not a big deal in most headlines, but when on the first headline, this
leads to an error.

I think org-kill-line should not try to do too much, and kill only
parts of the tags when the cursor is in the middle of tags is the
right thing to do.

As for the other patch, I think it's important to explain that the
whole subtree will be killed, even if not visible -- that's the whole
point of this variable after all.

So I'm sorry but these patches can't make it.

Thanks anyway!

-- 
 Bastien

Re: Survey: changing a few default settings for Org 9.4

[Marco Wahl]

Hi Bastien and all,

>> Subject: [PATCH 1/2] org: Fix corner case for org-kill-line
>>
>> * lisp/org.el (org-kill-line): Kill _all_ tags when the cursor is on the tags part.
>
> There is a problem with this patch: when on a empty heading with tags,
> killing the tags will let the cursor back right after the last "*".
> Not a big deal in most headlines, but when on the first headline, this
> leads to an error.

Okay.  Thanks for this finding.

> I think org-kill-line should not try to do too much, and kill only
> parts of the tags when the cursor is in the middle of tags is the
> right thing to do.

Fair enough.  I tried to implement the sentence "When after the headline
text, kill the tags" from the documentation for org-special-ctrl-k,
which I interpreted as kill _all_ tags.  Just to make clear my decision
for the patch.

> As for the other patch, I think it's important to explain that the
> whole subtree will be killed, even if not visible -- that's the whole
> point of this variable after all.

AFAICS the kill of a folded (invisible) subtree is also performed
without having set org-special-ctrl-k.  So I'd rather say that there is
no need for pointing out that behavior in the documentation.

> So I'm sorry but these patches can't make it.
>
> Thanks anyway!

You are welcome.  That's fine with me.


Ciao!

Re: Survey: changing a few default settings for Org 9.4

[Bastien]

Hi Marco,

Marco Wahl <marcowahlsoft@gmail.com> writes:

> Fair enough.  I tried to implement the sentence "When after the headline
> text, kill the tags" from the documentation for org-special-ctrl-k,
> which I interpreted as kill _all_ tags.  Just to make clear my decision
> for the patch.

Yes, I understand - but the implicit here is "When after the headline
text (and before the tags), kill the tags", which I think is intuitive
enough.

>> As for the other patch, I think it's important to explain that the
>> whole subtree will be killed, even if not visible -- that's the whole
>> point of this variable after all.
>
> AFAICS the kill of a folded (invisible) subtree is also performed
> without having set org-special-ctrl-k.  So I'd rather say that there is
> no need for pointing out that behavior in the documentation.

Mhh... you're right, I've updated the docstring slightly differently.

Thanks for clarifying,

-- 
 Bastien

Re: Survey: changing a few default settings for Org 9.4

[Adam Porter]

Marco Wahl <marcowahlsoft@gmail.com> writes:

>>>> - org-loop-over-headlines-in-active-region => t
>>>
>>> I vote for => 'start-level.  Loop over headlines with same level as the
>>> first.
>>
>> Yes, good suggestion.
>
> Let's see what others say.

I can see how that could be useful, but I feel like it would be less
intuitive than looping over all headings in the region.  I would be
confused by that behavior if I weren't aware of this discussion and the
option's settings.  So I would vote for t over 'start-level.

My two cents.  :)

Re: Survey: changing a few default settings for Org 9.4

[Nicolas Goaziou]

Hello,

Bastien <bzg@gnu.org> writes:

> - Add org-tempo to org-modules
>
>   Last but not least: we had long discussions about this one in the
>   past.  Expansion of the "<s" templates (and other "<*" templates) at
>   the beginning of the line has been turned off.  I have IRL met with
>   Org users* who just thought the feature was broken/deleted, without
>   having/taking the time/knowledge/guts to look for the things they
>   can turn on.  I am all for turning this on again, letting experts
>   disabling the feature if they don't want it.
>
>   * We have regular meetings with https://www.emacs-doctor.com/

This is not a good default, at least for beginners, because Org provides
a better solution out of the box. There are also better solutions
outside Org (e.g., Yasnippet).

It is only valuable for existing users, who relied on this feature, and
don't want to switch. It's perfectly understandable, but it is also fair
to assume they can add (require 'org-module) to their own configuration.
_Removing_ the module, OTOH, is subtle.

By the way, this does not belong to the same category as other
defcustoms discussed. This is only tangential to "how does Org should
look and feel by default". It relates to: should Org provide multiple
snippet extensions, knowing this is not a central feature, and Org is
often seen as bloated by Emacs devs? I don't think so, no matter how
useful this feature can be for some users.

Regards,

-- 
Nicolas Goaziou

Re: Survey: changing a few default settings for Org 9.4

[Bastien]

Hi Nicolas,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> This is not a good default, at least for beginners, because Org provides
> a better solution out of the box. There are also better solutions
> outside Org (e.g., Yasnippet).

Well, let's agree to disagree on this one.

org-tempo and C-c C- fill two different use cases: the first one for
fast block insertion while typing, the second one for e.g. when the
region is selected.

I don't think allowing org-tempo "shadows" C-c C-, in any fashion.

> It is only valuable for existing users, who relied on this feature, and
> don't want to switch. It's perfectly understandable, but it is also fair
> to assume they can add (require 'org-module) to their own configuration.
> _Removing_ the module, OTOH, is subtle.

M-x customize-option RET org-modules seems okay to me.

> By the way, this does not belong to the same category as other
> defcustoms discussed. This is only tangential to "how does Org should
> look and feel by default". It relates to: should Org provide multiple
> snippet extensions, knowing this is not a central feature, and Org is
> often seen as bloated by Emacs devs? I don't think so, no matter how
> useful this feature can be for some users.

I'll be more receptive to this argument when animate-birthday-present
is not in Emacs's core anymore :)

That said, I'm receptive to the idea that Org could be more focused to
its core functionalities.  E.g., I think we could be more minimalistic
about the ol-* and ox-* libraries in Org.  Also, we should get rid of
org-modules altogether now that Emacs has a packaging system.

I'd suggest a discussion on this for after 9.4.

-- 
 Bastien

Re: Survey: changing a few default settings for Org 9.4

[Nicolas Goaziou]

Hello,

Bastien <bzg@gnu.org> writes:

> Well, let's agree to disagree on this one.
>
> org-tempo and C-c C- fill two different use cases: the first one for
> fast block insertion while typing, the second one for e.g. when the
> region is selected.

I don't understand. C-c C-, combination is as fast as Org Tempo:

  C-c C-, s   : 3 keys
  < s TAB     : 3 keys

I can agree to disagree, but I don't buy the "fast block insertion while
typing" argument: they are as fast. We could even add an "expert"
interface that would not display the help menu for an even faster C-c
C-, experience. And, about the "while typing" part, C-c C-, can be used
anywhere amidst a line.

One true argument in favor of Org Tempo, however, is its extensibility.
IIRC, it can also insert non-block templates, e.g., "#+include:",
whereas C-c C-, cannot. Org has built-in completion for these, tho.

> M-x customize-option RET org-modules seems okay to me.

Then you may belong to the happy few that happen to find Customize
interface "okay". :>

I was speaking about "init.el" hacking. One must be cautious when
setting Org modules: it requires to be set before Org is loaded.

>> By the way, this does not belong to the same category as other
>> defcustoms discussed. This is only tangential to "how does Org should
>> look and feel by default". It relates to: should Org provide multiple
>> snippet extensions, knowing this is not a central feature, and Org is
>> often seen as bloated by Emacs devs? I don't think so, no matter how
>> useful this feature can be for some users.
>
> I'll be more receptive to this argument when animate-birthday-present
> is not in Emacs's core anymore :)

That's true. But I think they do have a point, though.

Also, my question is still open: is there any strong reason to provide,
out of the box, two template mechanisms in Org? This is genuine
question.

In any case, I don't think it is just a matter of personal preference,
like defcustoms. There should be some clear design decision behind the
answer. Let's un-bundle this issue from the rest of the poll, and think
about it separately.

> That said, I'm receptive to the idea that Org could be more focused to
> its core functionalities.  E.g., I think we could be more minimalistic
> about the ol-* and ox-* libraries in Org.

Hmmmm. This is another topic.

"ox-" are fine, IMO, even though I'm not sure about the health of
"ox-odt" these days.

"ol-*" libraries make sense as long as the suffix is bundled with Emacs.
E.g.,"ol-eww" is fine, but "ol-w3m" could be an external module.

A real issue, however, lies within "ob-*". Many of them require
libraries external to Emacs. There's a running bug report about it,
IIRC. We may not ship them with Emacs.

But, again, this is another topic.

Regards,

-- 
Nicolas Goaziou

Re: Survey: changing a few default settings for Org 9.4

[Bastien]

Hi Nicolas,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> I don't understand. C-c C-, combination is as fast as Org Tempo:
>
>   C-c C-, s   : 3 keys
>   < s TAB     : 3 keys

I'm tempted to count the number of fingers involved ;)

Which may not be *that* stupid when considering "fast" typing.
But eh, I don't want vimers to come and laugh at us.

> We could even add an "expert" interface that would not display the
> help menu for an even faster C-c C-, experience.

That's a good idea, yes.  I can even imagine that M-TAB can expand <*
using org-insert-structure-template only, and they we don't have the
problem of requiring this problematic tempo library.

>> M-x customize-option RET org-modules seems okay to me.
>
> Then you may belong to the happy few that happen to find Customize
> interface "okay". :>

Well, no, I'm not one of these happy few...

> I was speaking about "init.el" hacking. One must be cautious when
> setting Org modules: it requires to be set before Org is loaded.

Ok, fair point.

> Also, my question is still open: is there any strong reason to provide,
> out of the box, two template mechanisms in Org? This is genuine
> question.

No, there is no good reason for two template mechanism, and if we can
rely on org-insert-structure-template only, while still being able to
complete <* at the beginning of the line, that'd be perfect to me.

> In any case, I don't think it is just a matter of personal preference,
> like defcustoms. There should be some clear design decision behind the
> answer.

I get your point.  What would you think of this idea: (1) only one
function for inserting templates, but callable in two different ways,
one interactive (C-c C-, possibly with expert mode) and one by just
typing and hitting M-TAB.

In a word: I just want to add a simpler completion mechanism to the
current template insertion mechanism.  If we can get rid of org-tempo
from Org's core, that's even better.

> Let's un-bundle this issue from the rest of the poll, and think
> about it separately.

Agreed.

> Hmmmm. This is another topic.

Yes, let's raise this issue later on.

Thanks,

-- 
 Bastien

Re: Survey: changing a few default settings for Org 9.4

[Vladimir Lomov]

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

Hello
** Bastien <bzg@gnu.org> [2020-02-19 18:24:43 +0100]:

> Hi Nicolas,

> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

>> I don't understand. C-c C-, combination is as fast as Org Tempo:
>>
>>   C-c C-, s   : 3 keys
>>   < s TAB     : 3 keys

> I'm tempted to count the number of fingers involved ;)

C-c C-, s --> Ctrl  c , s
< s TAB   --> Shift , s TAB

???

> Which may not be *that* stupid when considering "fast" typing.
> But eh, I don't want vimers to come and laugh at us.

How this relate with the topic? Please, don't take decision so light (because
some people just ask on (not very well-known) channel about something that
even NOT documented), take in mind that quick solutions most of time are
troublesome in long living products (programs).

[...]

P.S. I wouldn't mention any "number of fingers" or '"fast" typing' especially
when I know that users may use different than QWERTY/QWERTZ/AZERTY keyboards
and even DVORAK layout.

---
WBR, Vladimir Lomov

-- 
When a person goes on a diet, the first thing he loses is his temper.

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

Re: Survey: changing a few default settings for Org 9.4

[Bastien]

Hi Vladimir,

Vladimir Lomov <lomov.vl@yandex.ru> writes:

>> I'm tempted to count the number of fingers involved ;)
>
> C-c C-, s --> Ctrl  c , s
> < s TAB   --> Shift , s TAB
>
> ???

I added the smiley to make it clear it was a joke.

>> Which may not be *that* stupid when considering "fast" typing.
>> But eh, I don't want vimers to come and laugh at us.
>
> How this relate with the topic?

Well, it relates to the joke.

> Please, don't take decision so light (because
> some people just ask on (not very well-known) channel about something that
> even NOT documented), take in mind that quick solutions most of time are
> troublesome in long living products (programs).

I would not spend that much time and energy in discussing these
changes if I wasn't taking them seriously.

> P.S. I wouldn't mention any "number of fingers" or '"fast" typing' especially
> when I know that users may use different than QWERTY/QWERTZ/AZERTY keyboards
> and even DVORAK layout.

Typing text is one thing, hitting keybindings is another.

Some keybindings blend more easily into typing text, others don't.
Even if "convenience" is a subjective notion, it is useful to discuss
how we can improve our collective (although distributed) experience
on these topics.

I didn't get that part of your email:

  (because some people just ask on (not very well-known) channel about
  something that even NOT documented)

If you can explain it, thanks.

-- 
 Bastien

Re: Survey: changing a few default settings for Org 9.4

[Samuel Wales]

recent org stackoverexchangeflowwhatgever post queries why <* is broken.  :)

On 2/19/20, Bastien <bzg@gnu.org> wrote:
> Hi Vladimir,
>
> Vladimir Lomov <lomov.vl@yandex.ru> writes:
>
>>> I'm tempted to count the number of fingers involved ;)
>>
>> C-c C-, s --> Ctrl  c , s
>> < s TAB   --> Shift , s TAB
>>
>> ???
>
> I added the smiley to make it clear it was a joke.
>
>>> Which may not be *that* stupid when considering "fast" typing.
>>> But eh, I don't want vimers to come and laugh at us.
>>
>> How this relate with the topic?
>
> Well, it relates to the joke.
>
>> Please, don't take decision so light (because
>> some people just ask on (not very well-known) channel about something
>> that
>> even NOT documented), take in mind that quick solutions most of time are
>> troublesome in long living products (programs).
>
> I would not spend that much time and energy in discussing these
> changes if I wasn't taking them seriously.
>
>> P.S. I wouldn't mention any "number of fingers" or '"fast" typing'
>> especially
>> when I know that users may use different than QWERTY/QWERTZ/AZERTY
>> keyboards
>> and even DVORAK layout.
>
> Typing text is one thing, hitting keybindings is another.
>
> Some keybindings blend more easily into typing text, others don't.
> Even if "convenience" is a subjective notion, it is useful to discuss
> how we can improve our collective (although distributed) experience
> on these topics.
>
> I didn't get that part of your email:
>
>   (because some people just ask on (not very well-known) channel about
>   something that even NOT documented)
>
> If you can explain it, thanks.
>
> --
>  Bastien
>
>


-- 
The Kafka Pandemic

What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

Re: Survey: changing a few default settings for Org 9.4

[Tim Cross]

I agree 100%. We have already gone through this pain and as has been
pointed out numerous times, the 'new' approach has significant benefits
over the old <x expansion. Yes, it takes a bit of effort to untrain the
old habits, but once done the new version works fine.

I also think Nicolas' point that adding (require 'org-tempo) is a lot
more trivial than removing it from the list of loaded modules.

The other poinit is that while tempo has been around for years, it is
not the easiest templating solution to use, especially for those
unfamiliar with it who may want to add their own tempo templates. Other
templating solutions, like yasnippets, are likely much easier for new
users to adopt than tempo.

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Bastien <bzg@gnu.org> writes:
>
>> - Add org-tempo to org-modules
>>
>>   Last but not least: we had long discussions about this one in the
>>   past.  Expansion of the "<s" templates (and other "<*" templates) at
>>   the beginning of the line has been turned off.  I have IRL met with
>>   Org users* who just thought the feature was broken/deleted, without
>>   having/taking the time/knowledge/guts to look for the things they
>>   can turn on.  I am all for turning this on again, letting experts
>>   disabling the feature if they don't want it.
>>
>>   * We have regular meetings with https://www.emacs-doctor.com/
>
> This is not a good default, at least for beginners, because Org provides
> a better solution out of the box. There are also better solutions
> outside Org (e.g., Yasnippet).
>
> It is only valuable for existing users, who relied on this feature, and
> don't want to switch. It's perfectly understandable, but it is also fair
> to assume they can add (require 'org-module) to their own configuration.
> _Removing_ the module, OTOH, is subtle.
>
> By the way, this does not belong to the same category as other
> defcustoms discussed. This is only tangential to "how does Org should
> look and feel by default". It relates to: should Org provide multiple
> snippet extensions, knowing this is not a central feature, and Org is
> often seen as bloated by Emacs devs? I don't think so, no matter how
> useful this feature can be for some users.
>
> Regards,


--
Tim Cross

Re: Survey: changing a few default settings for Org 9.4

[Bastien]

Hi Tim,

Tim Cross <theophilusx@gmail.com> writes:

> I agree 100%. We have already gone through this pain and as has been
> pointed out numerous times, the 'new' approach has significant benefits
> over the old <x expansion. Yes, it takes a bit of effort to untrain the
> old habits, but once done the new version works fine.

Point taken.  But as I said, I think both approaches fit different use
cases.

So my question is rather: why would it be so bad to enable org-tempo
expansion by default?

When simply use, it just allows <* expansion.

> I also think Nicolas' point that adding (require 'org-tempo) is a lot
> more trivial than removing it from the list of loaded modules.

Yes, I somehow agree, but yet: the poll so far seems to show that most
users want it back (10 on 15, as the moment, two votes against.)

Org is not poll-driven software, but this says something that we might
want to listen to.

> The other poinit is that while tempo has been around for years, it is
> not the easiest templating solution to use, especially for those
> unfamiliar with it who may want to add their own tempo templates. Other
> templating solutions, like yasnippets, are likely much easier for new
> users to adopt than tempo.

In its basic usage, <* expansion seems very simple to me.

I'm all for not enable org-tempo by default iff we can allow expansion
of <* strings at the beginning of the line.

-- 
 Bastien

Re: Survey: changing a few default settings for Org 9.4

[Tim Cross]

Hi Bastien - comments in-line below....

Bastien <bzg@gnu.org> writes:

> Hi Tim,
>
> Tim Cross <theophilusx@gmail.com> writes:
>
>> I agree 100%. We have already gone through this pain and as has been
>> pointed out numerous times, the 'new' approach has significant benefits
>> over the old <x expansion. Yes, it takes a bit of effort to untrain the
>> old habits, but once done the new version works fine.
>
> Point taken.  But as I said, I think both approaches fit different use
> cases.
>
> So my question is rather: why would it be so bad to enable org-tempo
> expansion by default?

Well I'm not convinced there are two different use cases. The number of
keystrokes required to insert a template is the same for both approaches
and with the non-tempo version, you can even bind it to a different key
with fewer keystrokes if you want. I have also had issues in the past
with the tab based expansion and the other completion setup I had
(though that was probably my mis-configuration!).

I also think having 2 different template expansion solutions will result
in confusion, especially for new users. Out of the box, I think it makes
sense to have a clear one way to do it. This can always be changed by
those who really want to (this is emacs after all).

I also don't think tempo was a good choice. I used it for many years and
while it is quite powerful, writing and debugging new templates is a
pain. It is pat of the reason other templating solutions, like
yasnippet, came into existence. I would not be surprised if we don't see
increased messages and bug reports as people try to fix/debug modified
or homebrew tempo templates. A better solution would probably have been
to provide examples of yasnippet templates as this is a common
templating system, bundled with many popular 'canned' configs like
spacemacs, purcell, prelude etc.

>
> When simply use, it just allows <* expansion.
>
>> I also think Nicolas' point that adding (require 'org-tempo) is a lot
>> more trivial than removing it from the list of loaded modules.
>
> Yes, I somehow agree, but yet: the poll so far seems to show that most
> users want it back (10 on 15, as the moment, two votes against.)
>
> Org is not poll-driven software, but this says something that we might
> want to listen to.
>

The problem with having a poll is I suspect many respondents will be
long-term users who were use to the original approach. I'm not sure how
many new users actually have any issue with the C-c C-, style and the
old users who prefer the old approach have  already added  (require
'org-tempo) to their setup, so  are not really affected by the default
change.

IMO changing defaults is about new uses more than existing users.
However, you cannot poll future users. For me, I voted based on what I
thought would have been best for me when I first started using org
rather than what I want now. (even though I will have to update my
config because of some of these changes if they occur). To some extent,
defaults should be about creating the safest envrionment with the fewest
'surprises' for new users - one reason I voted against the 'looping'
defaults - these seem like a feature which more experienced users may
want, but possibly dangerous or confusing for new users.

>> The other poinit is that while tempo has been around for years, it is
>> not the easiest templating solution to use, especially for those
>> unfamiliar with it who may want to add their own tempo templates. Other
>> templating solutions, like yasnippets, are likely much easier for new
>> users to adopt than tempo.
>
> In its basic usage, <* expansion seems very simple to me.
>
> I'm all for not enable org-tempo by default iff we can allow expansion
> of <* strings at the beginning of the line.

I don't actually get why the old <* is 'simpler'. They both seem as
simple to me and I find I really like the ease of wrapping a region in a
block. I'd be happy to have expansion on <* if I could also have region
wrapping!


--
Tim Cross

Re: Survey: changing a few default settings for Org 9.4

[AW]

Am Mittwoch, 19. Februar 2020, 12:30:59 CET schrieb Nicolas Goaziou:
> Hello,
> 
> Bastien <bzg@gnu.org> writes:
> > - Add org-tempo to org-modules
> > 
> >   Last but not least: we had long discussions about this one in the
> >   past.  Expansion of the "<s" templates (and other "<*" templates) at
> >   the beginning of the line has been turned off.  I have IRL met with
> >   Org users* who just thought the feature was broken/deleted, without
> >   having/taking the time/knowledge/guts to look for the things they
> >   can turn on.  I am all for turning this on again, letting experts
> >   disabling the feature if they don't want it.
> >   
> >   * We have regular meetings with https://www.emacs-doctor.com/
> 
> This is not a good default, at least for beginners, because Org provides
> a better solution out of the box. There are also better solutions
> outside Org (e.g., Yasnippet).
> 
> It is only valuable for existing users, who relied on this feature, and
> don't want to switch. It's perfectly understandable, but it is also fair
> to assume they can add (require 'org-module) to their own configuration.
> _Removing_ the module, OTOH, is subtle.
> 
> By the way, this does not belong to the same category as other
> defcustoms discussed. This is only tangential to "how does Org should
> look and feel by default". It relates to: should Org provide multiple
> snippet extensions, knowing this is not a central feature, and Org is
> often seen as bloated by Emacs devs? I don't think so, no matter how
> useful this feature can be for some users.
> 
> Regards,

Hello,

what Bastien suggests, doesn't that lead to two ways of getting getting e.g. a 
quote? Either with C-c C-, or again with "<q"? 

#+begin_quote
#+end_quote

If so, I'd vote to stick for the first solution and not have both. And yes, 
for larger templates there is yasnippet. 

Just my 0.2 cents.

Regards,

Alexander

Re: Survey: changing a few default settings for Org 9.4

[Matthew Lundin]

Bastien <bzg@gnu.org> writes:

> - org-fontify-done-headline => t
>
>   This is useful to visualize done headlines and can be easily turned
>   off, while not being easily discovered for Org newcomers.

I find this a bit visually distracting, but that's likely because I've
used Org mode in the "old school" way for so long. So no strong opinions
on this one.

> - org-hide-emphasis-markers => t
> - org-hide-macro-markers => t
>
>   The two changes proposed above will probably trigger some reactions
>   as they touch something very sensitive: whether Org should try to be
>   "too clever" at making things invisible.  I am all for letting Org
>   newcomers enjoying these visual enhancements, while letting experts
>   turning them off if needed.

I have a few concerns about this. I believe that markup syntax, as a
rule, should be visible. Most markdown editors do not hide markup by
default. I realize that there are some exceptions in Org (e.g., links).
But editing around the invisible boundaries of links can be in Org can
be fussy (sometimes I have to do M-x visible-mode when editing near the
edges of links). So I'd recommend not changing the default here,
especially for emphasis markers.

> - org-allow-promoting-top-level-subtree => t
>
>   With the current default of nil, an error is thrown when the user
>   tries to promote a top level subtree.  The new default setting would
>   let users convert the top level heading to a commented heading.

From my point of view, this is too destructive a default. I think it
makes it too easy accidentally to turn important TODO headlines into
commented lines (which will be buried in another entry). If I wanted to
change a first level headline to a comment, it would only take two
keystrokes (C-d #). Forcing users to type this explicitly seems
preferable to creating a risk that users will accidentally bury/lose
first-level headlines as comments in another entry.

Matt

Re: Survey: changing a few default settings for Org 9.4

[Joost Kremers]

On Wed, Feb 19 2020, Matthew Lundin wrote:
>> - org-hide-emphasis-markers => t
>> - org-hide-macro-markers => t
[...]
> I have a few concerns about this. I believe that markup syntax, 
> as a
> rule, should be visible. Most markdown editors do not hide 
> markup by
> default. I realize that there are some exceptions in Org (e.g., 
> links).
> But editing around the invisible boundaries of links can be in 
> Org can
> be fussy (sometimes I have to do M-x visible-mode when editing 
> near the
> edges of links). So I'd recommend not changing the default here,
> especially for emphasis markers.

I was going to say the same thing. I set 
`org-hide-emphasis-markers` to t when I started out using Org, but 
at some point changed it to `nil` because editing at the 
beginning/end of words in emphasis markers was just too 
unpredictable. Same with links, BTW.

What I'm wondering, though, is why Org doesn't make hidden markup 
visible when the cursor moves into it. `prettify-symbols-mode` can 
do this, and AUCTeX does it by default (IINM) in folded macros and 
preview snippets, so it's definitely doable.

So my suggestion would be to keep it off unless/until such 
make-visible-at-point functionality is implemented.

-- 
Joost Kremers
Life has its moments

Re: Survey: changing a few default settings for Org 9.4

[Bastien]

Hi Joost,

thanks for your feedback.  If you can, please add your vote to the
poll, so that we collect all votes in a single place.

Thanks,

-- 
 Bastien

Re: Survey: changing a few default settings for Org 9.4

[Detlef Steuer]

Am Wed, 19 Feb 2020 09:41:21 -0600
schrieb Matthew Lundin <mdl@imapmail.org>:

> Bastien <bzg@gnu.org> writes:
> 
> > - org-fontify-done-headline => t
> >
> >   This is useful to visualize done headlines and can be easily
> > turned off, while not being easily discovered for Org newcomers.  
> 
> I find this a bit visually distracting, but that's likely because I've
> used Org mode in the "old school" way for so long. So no strong
> opinions on this one.

Same here. No strong opinion.

> 
> > - org-hide-emphasis-markers => t
> > - org-hide-macro-markers => t
> >
> >   The two changes proposed above will probably trigger some
> > reactions as they touch something very sensitive: whether Org
> > should try to be "too clever" at making things invisible.  I am all
> > for letting Org newcomers enjoying these visual enhancements, while
> > letting experts turning them off if needed.  
> 
> I have a few concerns about this. I believe that markup syntax, as a
> rule, should be visible. Most markdown editors do not hide markup by
> default. I realize that there are some exceptions in Org (e.g.,
> links). But editing around the invisible boundaries of links can be
> in Org can be fussy (sometimes I have to do M-x visible-mode when
> editing near the edges of links). So I'd recommend not changing the
> default here, especially for emphasis markers.
>

I really dislike invisible markup as default. Org is a markup "language",
not a word-processor. Even links feel more consistent when visible.

So fully agree with Matt again.


> > - org-allow-promoting-top-level-subtree => t
> >
> >   With the current default of nil, an error is thrown when the user
> >   tries to promote a top level subtree.  The new default setting
> > would let users convert the top level heading to a commented
> > heading.  
> 
> From my point of view, this is too destructive a default. I think it
> makes it too easy accidentally to turn important TODO headlines into
> commented lines (which will be buried in another entry). If I wanted
> to change a first level headline to a comment, it would only take two
> keystrokes (C-d #). Forcing users to type this explicitly seems
> preferable to creating a risk that users will accidentally bury/lose
> first-level headlines as comments in another entry.


And again a simple +1.

Detlef

> 
> Matt
> 

Re: Survey: changing a few default settings for Org 9.4

[Bastien]

Hi Detlef,

if you can, please add your vote to the poll:
https://framadate.org/Ufc42EVxS2jO1Ajz

This is not to say that qualitative comments such as Matt's one
won't be taken into account, I read them carefull, especially when
they come from (very-)long-time users, but I hope the poll can be
representative enough.

Thanks,

-- 
 Bastien

Re: Survey: changing a few default settings for Org 9.4

[Adam Porter]

I generally approve of all of these changes.  However, hiding emphasis
and macro markers can make editing text at the boundaries of emphasized
text non-intuitive, which I can imagine might frustrate some new users,
so that should probably be carefully considered.  The other changes seem
like obvious improvements to me.  :)  Thanks for your work on this,
Bastien!

Re: Survey: changing a few default settings for Org 9.4

[Bastien]

Hi Adam,

Adam Porter <adam@alphapapa.net> writes:

> I generally approve of all of these changes.

Thanks for sharing your opinion.

> However, hiding emphasis and macro markers can make editing text at
> the boundaries of emphasized text non-intuitive, which I can imagine
> might frustrate some new users, so that should probably be carefully
> considered.

Interestingly, hiding emphasis and macro markers are the two changes
that get the *less* votes, so we probably won't change these.

Best,

-- 
 Bastien

Re: Survey: changing a few default settings for Org 9.4

[Kaushal Modi]

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

>
> > However, hiding emphasis and macro markers can make editing text at
> > the boundaries of emphasized text non-intuitive, which I can imagine
> > might frustrate some new users, so that should probably be carefully
> > considered.
>

+1e6


> Interestingly, hiding emphasis and macro markers are the two changes
> that get the *less* votes, so we probably won't change these.
>

Thank you! Hiding those will somehow take away the "Org-ness" in my humble
opinion :)

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

Re: Survey: changing a few default settings for Org 9.4

[Bastien]

Hi all,

here are the results of the survey, with *47* voters:

- 26+2 : org-loop-over-headlines-in-active-region => t
- 25+2 : org-agenda-loop-over-headlines-in-active-region => t
- 28+3 : org-fontify-done-headline => t
- 17+4 : org-hide-emphasis-markers => t
- 10+6 : org-hide-macro-markers => t
- 15+5 : org-refile-use-cache => t
- 23+6 : org-special-ctrl-k => t
- 20+6 : org-allow-promoting-top-level-subtree => t
- 22+5 : Add org-tempo to org-modules

I've changed the values of these options in master:

- 35+2 : org-src-tab-acts-natively => t
- 28+3 : org-fontify-done-headline => t
- 26+2 : org-loop-over-headlines-in-active-region => t
- 25+2 : org-agenda-loop-over-headlines-in-active-region => t

I've *not* changed the values of these options:

- 23+6 : org-special-ctrl-k => t
- 22+5 : Add org-tempo to org-modules
- 20+6 : org-allow-promoting-top-level-subtree => t
- 17+4 : org-hide-emphasis-markers => t
- 10+6 : org-hide-macro-markers => t
- 15+5 : org-refile-use-cache => t

The reason for not changing the default of org-special-ctrl-k is that
23 < 47/2.  Also, I think it was a mistake to propose this: even the
org-special- prefix should have warned me.  The org-special-* options
should be nil by default, and while org-special-ctrl-k may be useful,
it is as useful as org-special-ctrl-a/e, which sticks to nil too.

The reason for not adding org-tempo to org-modules is, on top of the
poll being 22 < 47/2, that the current discussion on the list leaves
room for improvements that may lead to move org-tempo from Org's core
anyway.

The reason for not changing the four other options is that they did
not get enough votes.

I've push the change for the three options in current master.

Thanks again for participating to the poll and to the discussions!

Best,

-- 
 Bastien

Re: Survey: changing a few default settings for Org 9.4

[Diego Zamboni]

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

Thanks Bastien for all your work!

--Diego


On Fri, Feb 21, 2020 at 4:50 PM Bastien <bzg@gnu.org> wrote:

> Hi all,
>
> here are the results of the survey, with *47* voters:
>
> - 26+2 : org-loop-over-headlines-in-active-region => t
> - 25+2 : org-agenda-loop-over-headlines-in-active-region => t
> - 28+3 : org-fontify-done-headline => t
> - 17+4 : org-hide-emphasis-markers => t
> - 10+6 : org-hide-macro-markers => t
> - 15+5 : org-refile-use-cache => t
> - 23+6 : org-special-ctrl-k => t
> - 20+6 : org-allow-promoting-top-level-subtree => t
> - 22+5 : Add org-tempo to org-modules
>
> I've changed the values of these options in master:
>
> - 35+2 : org-src-tab-acts-natively => t
> - 28+3 : org-fontify-done-headline => t
> - 26+2 : org-loop-over-headlines-in-active-region => t
> - 25+2 : org-agenda-loop-over-headlines-in-active-region => t
>
> I've *not* changed the values of these options:
>
> - 23+6 : org-special-ctrl-k => t
> - 22+5 : Add org-tempo to org-modules
> - 20+6 : org-allow-promoting-top-level-subtree => t
> - 17+4 : org-hide-emphasis-markers => t
> - 10+6 : org-hide-macro-markers => t
> - 15+5 : org-refile-use-cache => t
>
> The reason for not changing the default of org-special-ctrl-k is that
> 23 < 47/2.  Also, I think it was a mistake to propose this: even the
> org-special- prefix should have warned me.  The org-special-* options
> should be nil by default, and while org-special-ctrl-k may be useful,
> it is as useful as org-special-ctrl-a/e, which sticks to nil too.
>
> The reason for not adding org-tempo to org-modules is, on top of the
> poll being 22 < 47/2, that the current discussion on the list leaves
> room for improvements that may lead to move org-tempo from Org's core
> anyway.
>
> The reason for not changing the four other options is that they did
> not get enough votes.
>
> I've push the change for the three options in current master.
>
> Thanks again for participating to the poll and to the discussions!
>
> Best,
>
> --
>  Bastien
>
>

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

Re: Survey: changing a few default settings for Org 9.4

[Archenoth]

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

Yes! Thank you Bastien!

On Wed, Feb 19, 2020 at 10:26 AM Bastien <bzg@gnu.org> wrote:

> > Also, my question is still open: is there any strong reason to provide,
> > out of the box, two template mechanisms in Org? This is genuine
> > question.
>
> No, there is no good reason for two template mechanism, and if we can
> rely on org-insert-structure-template only, while still being able to
> complete <* at the beginning of the line, that'd be perfect to me.
>

I definitely agree with this.

I voted (slightly late) for having org-tempo in org-modules--not out of any
love of org-tempo itself, but more because it feels to me like an extremely
natural way to create blocks.
The tab key is extremely easy to hit, and having a fully formed block
created by typing a short string of characters makes the tab-completion
lizard-part of my brain happy in a way that key chord combos simply don't.

I think this is partly because I personally can't do key chords at the same
rate I can type a string of characters--even if they require technically
the same number of keystrokes.
Like, I can type a 10 character command *significantly* faster than I can
hit a number of different combinations of keys that also happen to be 10
keypresses.

I just personally find it really nice!

On Fri, Feb 21, 2020 at 12:37 PM Diego Zamboni <diego@zzamboni.org> wrote:

> Thanks Bastien for all your work!
>
> --Diego
>
>
> On Fri, Feb 21, 2020 at 4:50 PM Bastien <bzg@gnu.org> wrote:
>
>> Hi all,
>>
>> here are the results of the survey, with *47* voters:
>>
>> - 26+2 : org-loop-over-headlines-in-active-region => t
>> - 25+2 : org-agenda-loop-over-headlines-in-active-region => t
>> - 28+3 : org-fontify-done-headline => t
>> - 17+4 : org-hide-emphasis-markers => t
>> - 10+6 : org-hide-macro-markers => t
>> - 15+5 : org-refile-use-cache => t
>> - 23+6 : org-special-ctrl-k => t
>> - 20+6 : org-allow-promoting-top-level-subtree => t
>> - 22+5 : Add org-tempo to org-modules
>>
>> I've changed the values of these options in master:
>>
>> - 35+2 : org-src-tab-acts-natively => t
>> - 28+3 : org-fontify-done-headline => t
>> - 26+2 : org-loop-over-headlines-in-active-region => t
>> - 25+2 : org-agenda-loop-over-headlines-in-active-region => t
>>
>> I've *not* changed the values of these options:
>>
>> - 23+6 : org-special-ctrl-k => t
>> - 22+5 : Add org-tempo to org-modules
>> - 20+6 : org-allow-promoting-top-level-subtree => t
>> - 17+4 : org-hide-emphasis-markers => t
>> - 10+6 : org-hide-macro-markers => t
>> - 15+5 : org-refile-use-cache => t
>>
>> The reason for not changing the default of org-special-ctrl-k is that
>> 23 < 47/2.  Also, I think it was a mistake to propose this: even the
>> org-special- prefix should have warned me.  The org-special-* options
>> should be nil by default, and while org-special-ctrl-k may be useful,
>> it is as useful as org-special-ctrl-a/e, which sticks to nil too.
>>
>> The reason for not adding org-tempo to org-modules is, on top of the
>> poll being 22 < 47/2, that the current discussion on the list leaves
>> room for improvements that may lead to move org-tempo from Org's core
>> anyway.
>>
>> The reason for not changing the four other options is that they did
>> not get enough votes.
>>
>> I've push the change for the three options in current master.
>>
>> Thanks again for participating to the poll and to the discussions!
>>
>> Best,
>>
>> --
>>  Bastien
>>
>>

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

Re: Survey: changing a few default settings for Org 9.4

[Bastien]

Hi,

Archenoth <archenoth@gmail.com> writes:

> The tab key is extremely easy to hit, and having a fully formed block
> created by typing a short string of characters makes the
> tab-completion lizard-part of my brain happy in a way that key chord
> combos simply don't.

You say it better than I did - I will see if I can add a completion
mechanism to `org-insert-structure-template' that is not to hackish.
This is for after Org 9.4 though, as we will enter a short period of
feature-freeze when 0001-Do-not-leak-attachment-links.patch is in.

Thanks,

-- 
 Bastien

Re: Survey: changing a few default settings for Org 9.4

[Nicolas Goaziou]

Hello,

Bastien <bzg@gnu.org> writes:

> Archenoth <archenoth@gmail.com> writes:
>
>> The tab key is extremely easy to hit, and having a fully formed block
>> created by typing a short string of characters makes the
>> tab-completion lizard-part of my brain happy in a way that key chord
>> combos simply don't.
>
> You say it better than I did - I will see if I can add a completion
> mechanism to `org-insert-structure-template' that is not to hackish.

Note that the "the TAB is extremely easy to hit" is not really an
argument here. It is no more true than "< s TAB" is faster than "C-c C-,
s", i.e., it depends on users, as we already observed.

More generally, this discussion is not about "Is Org Tempo useful?". The
answer is simple: yes, it is for some users. No need to argue about
that. But you can also find plenty of useful Org extensions in
"contrib/", or any ELPA. This does not mean they should all ship with
Org.

Deciding if an extension should or should not go into Org proper is
usually not an easy decision. In this case, a strong argument against it
is: there is already a template mechanism available out of the box, why
would we provide two of them? I think we should focus on this topic,
rather than personal preferences.

Regards,

-- 
Nicolas Goaziou

Re: Survey: changing a few default settings for Org 9.4

[Bastien]

Hi,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> In this case, a strong argument against it is: there is already a
> template mechanism available out of the box, why would we provide
> two of them?

I bet most users of the <* completion mechanism provided by org-tempo
don't even notice it is a "template" mechanism.

Org used to provide a *completion* mechanism for <* at the beginning
of the line, then this completion mechanism was moved in org-tempo,
which names does not really speaks about _completing_ <* strings.

Anyway, I think we settled the case:

1. let's not supercharge Org's core with two template mechanismes;

2. let's try to provide a completion mechanism on top of the current
   template expansion mechanism -- an intermediary step being having
   an expert dispatch mode for org-insert-structure-template.

I'll try to do that for 9.5.

Best,

-- 
 Bastien

Re: Survey: changing a few default settings for Org 9.4

[Archenoth]

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

Oh yeah, I agree that it's redundant--and that's why I was more just
advocating for the functionality it provided rather than for the module
itself.

It's just a piece of functionality that a lot of people seem to use and
enjoy, and if there were a way to keep it without holding onto a second
templating system, I feel like there would be significantly less resistance
to disabling it.

The reasons for disabling tempo are good ones! But they also have the side
effect of effectively disabling something that a significant number of
people are already using and prefer. And unlike external modules, it
already has a pretty strong reputation for being in "vanilla" Org-mode. I
mean, I know I've already had to revise a number of Emacs Stack Exchange
answers with an explanation of why this no longer works.


On Sat, Feb 22, 2020, 5:45 AM Nicolas Goaziou <mail@nicolasgoaziou.fr>
wrote:

> Hello,
>
> Bastien <bzg@gnu.org> writes:
>
> > Archenoth <archenoth@gmail.com> writes:
> >
> >> The tab key is extremely easy to hit, and having a fully formed block
> >> created by typing a short string of characters makes the
> >> tab-completion lizard-part of my brain happy in a way that key chord
> >> combos simply don't.
> >
> > You say it better than I did - I will see if I can add a completion
> > mechanism to `org-insert-structure-template' that is not to hackish.
>
> Note that the "the TAB is extremely easy to hit" is not really an
> argument here. It is no more true than "< s TAB" is faster than "C-c C-,
> s", i.e., it depends on users, as we already observed.
>
> More generally, this discussion is not about "Is Org Tempo useful?". The
> answer is simple: yes, it is for some users. No need to argue about
> that. But you can also find plenty of useful Org extensions in
> "contrib/", or any ELPA. This does not mean they should all ship with
> Org.
>
> Deciding if an extension should or should not go into Org proper is
> usually not an easy decision. In this case, a strong argument against it
> is: there is already a template mechanism available out of the box, why
> would we provide two of them? I think we should focus on this topic,
> rather than personal preferences.
>
> Regards,
>
> --
> Nicolas Goaziou
>

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

Re: Survey: changing a few default settings for Org 9.4

[Mark E. Shoulson]

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

On 2/19/20 2:39 AM, Bastien wrote:
> - org-hide-emphasis-markers => t

Just to note: I've been working on a minor-mode in which the emphasis 
markers are "invisible" but not hidden (i.e. they still take up space, 
they're just in 'org-hide face or something similar), except when the 
point is closeby, at which point they become visible.  The extra space 
is pretty ugly, I'll grant, but this does avoid the sudden jerks as text 
shifts when characters become visible.  Also, in 
org-variable-pitch-mode, the emphasis markers are also reduced in size, 
so the extra space is not quite as obvious.  Does this sound interesting 
to anyone?  Right now the code is kind of a mess, but it could be refined.

~mark


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

Re: Survey: changing a few default settings for Org 9.4

[Norman Tovey-Walsh]

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

Mark E. Shoulson <mark@kli.org> writes:
> On 2/19/20 2:39 AM, Bastien wrote:
>> - org-hide-emphasis-markers => t
>
> Just to note: I've been working on a minor-mode in which the emphasis
> markers are "invisible" but not hidden (i.e. they still take up space,
[…]
> size, so the extra space is not quite as obvious.  Does this sound
> interesting to anyone?  Right now the code is kind of a mess, but it
> could be refined.

Sounds interesting to me.

                                        Be seeing you,
                                          norm

--
Norman Tovey-Walsh <ndw@nwalsh.com>
https://nwalsh.com/

> Why is there always money for war and not for education?

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

Hiding emphasis markers

[Mark E. Shoulson]

On 3/18/20 4:58 AM, Norman Tovey-Walsh wrote:
> Mark E. Shoulson <mark@kli.org> writes:
>> On 2/19/20 2:39 AM, Bastien wrote:
>>> - org-hide-emphasis-markers => t
>> Just to note: I've been working on a minor-mode in which the emphasis
>> markers are "invisible" but not hidden (i.e. they still take up space,
> […]
>> size, so the extra space is not quite as obvious.  Does this sound
>> interesting to anyone?  Right now the code is kind of a mess, but it
>> could be refined.
> Sounds interesting to me.
All right, then, you asked for it.  It's really very sloppy code right 
now; I'm just playing around to see what works.  Comments are kind of 
stream-of-consciousness, they may be out of date wrt what works and what 
doesn't etc.  But hey, have fun. 
https://gist.github.com/clsn/819a6463b1741eb465b310c39b4902a1


~mark

Re: Hiding emphasis markers

[Bastien]

Hi Mark,

"Mark E. Shoulson" <mark@shoulson.com> writes:

> All right, then, you asked for it.  It's really very sloppy code right
> now; I'm just playing around to see what works.  Comments are kind of 
> stream-of-consciousness, they may be out of date wrt what works and
> what doesn't etc.  But hey, have fun. 
> https://gist.github.com/clsn/819a6463b1741eb465b310c39b4902a1

If/when it gets in a share you like, maybe you can add this to
https://orgmode.org/worg/org-hacks.html ?

-- 
 Bastien