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

2020-03-18 Thread Norman Tovey-Walsh
Mark E. Shoulson  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 
https://nwalsh.com/

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


signature.asc
Description: PGP signature


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

2020-03-17 Thread Mark E. Shoulson

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



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

2020-02-22 Thread Archenoth
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 
wrote:

> Hello,
>
> Bastien  writes:
>
> > Archenoth  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

2020-02-22 Thread Bastien
Hi,

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

2020-02-22 Thread Nicolas Goaziou
Hello,

Bastien  writes:

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

2020-02-22 Thread Bastien
Hi,

Archenoth  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

2020-02-21 Thread Archenoth
Yes! Thank you Bastien!

On Wed, Feb 19, 2020 at 10:26 AM Bastien  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  wrote:

> Thanks Bastien for all your work!
>
> --Diego
>
>
> On Fri, Feb 21, 2020 at 4:50 PM Bastien  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
>>
>>


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

2020-02-21 Thread Diego Zamboni
Thanks Bastien for all your work!

--Diego


On Fri, Feb 21, 2020 at 4:50 PM Bastien  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
>
>


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

2020-02-21 Thread 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

2020-02-20 Thread Kaushal Modi
>
> > 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 :)


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

2020-02-19 Thread Bastien
Hi Adam,

Adam Porter  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

2020-02-19 Thread Adam Porter
Marco Wahl  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

2020-02-19 Thread 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

2020-02-19 Thread Samuel Wales
recent org stackoverexchangeflowwhatgever post queries why <* is broken.  :)

On 2/19/20, Bastien  wrote:
> Hi Vladimir,
>
> Vladimir Lomov  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

2020-02-19 Thread Bastien
Hi Vladimir,

Vladimir Lomov  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

2020-02-19 Thread Vladimir Lomov
Hello
** Bastien  [2020-02-19 18:24:43 +0100]:

> Hi Nicolas,

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


signature.asc
Description: PGP signature


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

2020-02-19 Thread 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  wrote:
> Hi Samuel and Marcin,
>
> Marcin Borkowski  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

2020-02-19 Thread Bastien
Hi Samuel and Marcin,

Marcin Borkowski  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

2020-02-19 Thread Bastien
Hi Marco,

Marco Wahl  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

2020-02-19 Thread Marcin Borkowski


On 2020-02-19, at 21:02, Samuel Wales  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

2020-02-19 Thread 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

2020-02-19 Thread 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

2020-02-19 Thread Bastien
Hi Nicolas,

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

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

2020-02-19 Thread 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

2020-02-19 Thread 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

2020-02-19 Thread Detlef Steuer
Am Wed, 19 Feb 2020 09:41:21 -0600
schrieb Matthew Lundin :

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

2020-02-19 Thread 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

2020-02-19 Thread Matthew Lundin
Bastien  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

2020-02-19 Thread Tim Cross


Hi Bastien - comments in-line below

Bastien  writes:

> Hi Tim,
>
> Tim Cross  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 > 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

2020-02-19 Thread Nicolas Goaziou
Hello,

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

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

2020-02-19 Thread Bastien
Hi Marco,

Marco Wahl  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 
> 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

2020-02-19 Thread Marco Wahl
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.

>From 49b00d2cf7ca4b8484e0a9679b39b62873ee30b6 Mon Sep 17 00:00:00 2001
From: Marco Wahl 
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

>From a81744de15f42d1817482f2209f555a959e9e66c Mon Sep 17 00:00:00 2001
From: Marco Wahl 
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

2020-02-19 Thread Bastien
Hi Tim,

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

2020-02-19 Thread AW
Am Mittwoch, 19. Februar 2020, 12:30:59 CET schrieb Nicolas Goaziou:
> Hello,
> 
> Bastien  writes:
> > - Add org-tempo to org-modules
> > 
> >   Last but not least: we had long discussions about this one in the
> >   past.  Expansion of the " >   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 "

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

2020-02-19 Thread 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  writes:

> Hello,
>
> Bastien  writes:
>
>> - Add org-tempo to org-modules
>>
>>   Last but not least: we had long discussions about this one in the
>>   past.  Expansion of the ">   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

2020-02-19 Thread Bastien
Hi Nicolas,

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

2020-02-19 Thread Bastien
Hi Marco,

Marco Wahl  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

2020-02-19 Thread Nicolas Goaziou
Hello,

Bastien  writes:

> - Add org-tempo to org-modules
>
>   Last but not least: we had long discussions about this one in the
>   past.  Expansion of the "   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

2020-02-19 Thread Marco Wahl
Bastien  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

2020-02-19 Thread Bastien
Hi Samuel,

thanks for your feedback.

Samuel Wales  writes:

> On 2/19/20, Bastien  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

2020-02-19 Thread Samuel Wales
On 2/19/20, Bastien  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