Re: Survey: changing a few default settings for Org 9.4
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
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
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
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
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
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
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
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
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
> > > 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
Survey: changing a few default settings for Org 9.4
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 "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
