Re: Changed list indentation behavior: how to revert?
Dr. Arne Babenhauserheide writes: > Kyle Meyer writes: >> So, it seems that changing Org to honor electric-indent-mode is now >> making some users aware of org-adapt-indentation and that its default >> value is not what they want. > > I’ve seen before that increasing the depth of a headline with M-→ > indents all its content. That was mildly annoying, but nothing to worry > about. > > It’s the change to the behavior of RET that disturbs my writing flow. > Now I always have to hit RET twice, or hit RET C-a to start typing. > > It’s not just about the default, it is about long-standing muscle memory > suddenly being wrong. This breaks my workflow on an update and requires > me to start digging to find out how to get my system back into a good > state. > > That’s something which makes me nervous, because I often don’t have the > time or energy to investigate when something breaks, so when that > workflow is broken, I’m bound to operate on a broken workflow for > anything from days to months, because I cannot estimate how much time > will be required to fix it (and at work I should not just take 3 hours > off to search for some configuration value). > Hi Arne, I can completely understand your position. However, I wanted to point out that this change was documented in the org NEWS file, where all version changes are documented. When upgrading to a new version of org, everyone should look there, ideally before the upgrade or soon afterwards and definitely when you notice some changed behaviour. It will save hours of trouble shooting and often tells you how to restore previous behaviour. A very under appreciated piece of valuable documentation. Tim -- Tim Cross
Re: Changed list indentation behavior: how to revert?
Tim Cross writes: > Kyle Meyer writes: > >> Kévin Le Gouguec writes: >> >>> Detlef Steuer writes: >>> Note that indenting section bodies by default predates Org 9.4: in Org >>> 9.3, hitting TAB on the first line of text after a heading indents it to >>> column LEVEL+1. >> >> Yes, org-adapt-indentation has been around (with a default of t) since >> 4be4c5623 (version 4.12a, 2008-01-31). >> >>> IMHO, the default value of org-adapt-indentation might be the issue here >>> (made more visible by the change in 9.4): I agree that hard-indenting >>> prose should not be the default behaviour. FWIW the .dir-locals.el file >>> at the root of Org's own repository sets this variable to nil; maybe >>> that suggests that it would be a better default? >> >> Perhaps. I certainly prefer org-adapt-indentation at nil and would vote >> for that if we were introducing the option today, but this would be >> changing a longstanding default. >> >> So, it seems that changing Org to honor electric-indent-mode is now >> making some users aware of org-adapt-indentation and that its default >> value is not what they want. > > Thanks for clarifying this Kyle. > > So essentially, this change has been made to make org-mode consistent > with the rest of emacs which enabled electric-indent by default in Emacs > 24. this is a good thing. Org should be consistent with other modes. Any > differences are likely to be the source of confusion and bug reports. > > I am a little confused about the purpose of org-adapt-indentation > though. According to the org news file, to get back the old behaviour, > it says to explicity disable electric-indent mode using org-mode-hook. > There is no mention of org-adapt-indentation. > > Is this just an artefact from before and in effect, we have two methods > to disable the indentation behaviour? Is there anything functionally > different between disabling electric-indent by calling > electric-indent-local-mode -1 or setting org-adapt-indent to nil or is > the result functionally equivalent? > Following up to my own question. The two are NOT functionally equivalent in that org-adapt-indentation supports other values than t or nil. You can use this variable to tweak how the adaptive indentation works. While setting it to nil may be equivalent to turning of electric-indent mode, it can be used to adjust how adaptive indentation works as well. Tim -- Tim Cross
Re: Changed list indentation behavior: how to revert?
Kévin Le Gouguec writes: > Before being applied, this change has been discussed on emacs-devel and > emacs-orgmode; it has then been documented in ORG-NEWS. Which other > places do you think we should have reached out to? I don’t think you really had a chance to reach enough people. I’m here on the list now because I got a note about the call for help from a colleague at work. Before that I was simply happy that most things worked, wrote the occassional M-x org-submit-bug-report (actually with Ido: M-x org-bug) and dug through emacswiki or the web when something didn’t work. When missing names for some annoyance, I couldn’t do much about it, because I couldn’t search for it. Changes like these which affect existing behavior are just really hard to do in a way that doesn’t create problems. There’s a deep challenge hidden beneath this which Steve Losh wrote masterfully about: https://stevelosh.com/blog/2012/04/volatile-software/ Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: Changed list indentation behavior: how to revert?
Greg Minshall writes: > i wonder if a grid might help? i.e., contexts in which we are all > happy, others where we might disagree? below, i try; i'm sure i've > missed cases. > > question: what does do/would we like it to do when we are in? > > = > tables: next row, current column > > Org Src buffers: electric-indent per declared language major > mode rules. > > src blocks: same as in Org Src buffers (i think there have been some > very nice "recent" improvements here, which are great, and for which, > belated thanks!) > > ^^ i think we are all happy with those > = > = > vv here, i think, well, "Houston, ..." :) > > after n* heading: > column 1 > vs > column n+2 > > list entry (end of line): > column where previous "-" was (to start a new list item) > vs > two columns *after* where previous "-" was (to continue with the > current list item) > > immediately after (non-blank, non-list, non-heading) with text starting > in column n: > column 1 > vs > column n > > immediately after a blank line: > column 1 > vs > column of first non-blank character of most recent non-blank line? > = > > surveymonkey, anyone? :) not to vote, but i'm curious to what extent > we divide cleanly into two groups (in which case, maybe an option for > which "major mode indentation" style one prefers for org-mode makes > sense), or if we are uniformly distributed across the power set. :) > > btw, it seems to me that M-q (fill-paragraph) also has *something* to > say here. i.e., though *i* want from a list entry to line me up > at the previous "-", i want M-q within a list entry to add new lines > starting two columns past that point. i guess i see it as orthogonal > (and, so far, non-controversial) to the current discussion, and hope it > so stays! > > cheers, Greg Hi Greg, I think there are more than two groups. I would start by considering it as two top level groups 1. Indentation behaviour with electric-indent enabled and org-adapt-indent set to t (the current defaults) 2. Indentation behaviour with electric-indent disabled as suggested in the org NEWS file. 3. Indentation behaviour with different values for org-adaptive-indentation. Then we have the different values which org-adapt-indentation can be set to that will 'tweak' the way adaptive indentation works in different contexts. It is my guess that the majority of people can in fact have the behaviour they want either by turning of electric indent mode or by setting org-adaptive-indentation to one of the supported values. I would encourage anyone who is not happy with the default to look at the different supported values for org-adaptive-indentation to see if the tweaking it provides might make org indentation work closer to what they like (as opposed to turning all automatic indentation off). There are probably a few edge cases, but to identify those, we need to first eliminate all the cases which can be 'resolved' with existing configuration options. Tim -- Tim Cross
Re: Changed list indentation behavior: how to revert?
Kyle Meyer writes: > So, it seems that changing Org to honor electric-indent-mode is now > making some users aware of org-adapt-indentation and that its default > value is not what they want. I’ve seen before that increasing the depth of a headline with M-→ indents all its content. That was mildly annoying, but nothing to worry about. It’s the change to the behavior of RET that disturbs my writing flow. Now I always have to hit RET twice, or hit RET C-a to start typing. It’s not just about the default, it is about long-standing muscle memory suddenly being wrong. This breaks my workflow on an update and requires me to start digging to find out how to get my system back into a good state. That’s something which makes me nervous, because I often don’t have the time or energy to investigate when something breaks, so when that workflow is broken, I’m bound to operate on a broken workflow for anything from days to months, because I cannot estimate how much time will be required to fix it (and at work I should not just take 3 hours off to search for some configuration value). Best wishes, Arne PS: I started to donate to org-mode a few weeks ago when I realized just how central it is to my workflows. If it’s the same for you, please join up: https://liberapay.com/bzg Creating reliable funding for development of essential Free Software tools is one of the critical tasks for spreading Free Software. -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: Changed list indentation behavior: how to revert?
i wonder if a grid might help? i.e., contexts in which we are all happy, others where we might disagree? below, i try; i'm sure i've missed cases. question: what does do/would we like it to do when we are in? = tables: next row, current column Org Src buffers: electric-indent per declared language major mode rules. src blocks: same as in Org Src buffers (i think there have been some very nice "recent" improvements here, which are great, and for which, belated thanks!) ^^ i think we are all happy with those = = vv here, i think, well, "Houston, ..." :) after n* heading: column 1 vs column n+2 list entry (end of line): column where previous "-" was (to start a new list item) vs two columns *after* where previous "-" was (to continue with the current list item) immediately after (non-blank, non-list, non-heading) with text starting in column n: column 1 vs column n immediately after a blank line: column 1 vs column of first non-blank character of most recent non-blank line? = surveymonkey, anyone? :) not to vote, but i'm curious to what extent we divide cleanly into two groups (in which case, maybe an option for which "major mode indentation" style one prefers for org-mode makes sense), or if we are uniformly distributed across the power set. :) btw, it seems to me that M-q (fill-paragraph) also has *something* to say here. i.e., though *i* want from a list entry to line me up at the previous "-", i want M-q within a list entry to add new lines starting two columns past that point. i guess i see it as orthogonal (and, so far, non-controversial) to the current discussion, and hope it so stays! cheers, Greg
Re: Changed list indentation behavior: how to revert?
Kyle Meyer writes: > Kévin Le Gouguec writes: > >> Detlef Steuer writes: >> Note that indenting section bodies by default predates Org 9.4: in Org >> 9.3, hitting TAB on the first line of text after a heading indents it to >> column LEVEL+1. > > Yes, org-adapt-indentation has been around (with a default of t) since > 4be4c5623 (version 4.12a, 2008-01-31). > >> IMHO, the default value of org-adapt-indentation might be the issue here >> (made more visible by the change in 9.4): I agree that hard-indenting >> prose should not be the default behaviour. FWIW the .dir-locals.el file >> at the root of Org's own repository sets this variable to nil; maybe >> that suggests that it would be a better default? > > Perhaps. I certainly prefer org-adapt-indentation at nil and would vote > for that if we were introducing the option today, but this would be > changing a longstanding default. > > So, it seems that changing Org to honor electric-indent-mode is now > making some users aware of org-adapt-indentation and that its default > value is not what they want. Thanks for clarifying this Kyle. So essentially, this change has been made to make org-mode consistent with the rest of emacs which enabled electric-indent by default in Emacs 24. this is a good thing. Org should be consistent with other modes. Any differences are likely to be the source of confusion and bug reports. I am a little confused about the purpose of org-adapt-indentation though. According to the org news file, to get back the old behaviour, it says to explicity disable electric-indent mode using org-mode-hook. There is no mention of org-adapt-indentation. Is this just an artefact from before and in effect, we have two methods to disable the indentation behaviour? Is there anything functionally different between disabling electric-indent by calling electric-indent-local-mode -1 or setting org-adapt-indent to nil or is the result functionally equivalent? Tim -- Tim Cross
Re: Changed list indentation behavior: how to revert?
i wanted first to thank everyone for their participation in this discussion. i want to not be annoying. and, yes, this is a long thread, and for me, at least, it's hard to keep track of what was said. (like many, i assumed this was some bug, triggered by my configuration TIMES emacs release TIMES org release, and that it would eventually clear up or i'd eventually track down whatever in my .emacs that was causing it.) Kévin Le Gouguec said > My understanding of electric-indent-mode is that it tries to make > "RET" equivalent to "insert newline; indent according to major mode > rules". and i wonder if this might be a big part of the "problem": exactly what *are* the major mode rules when org-mode is the major mode? my sense is that for some of us, column 1 (modulo lists) rules; for others, column (n*asterisks+1) is the rule. both seem reasonable choices. afaict, either, if adopted as "the" major mode rule for org-mode, could be said to be playing to the tune of emacs' electric indent. then, more mundanely, i'll note that setting 'org-adapt-indentation' to nil doesn't seem to take at least me back to (my column-1 version of) nirvana. if i type (ignore square brackets): [- thisisatest] i end up with: - this is a test rather than - this is a test which i think was the previous behavior. (in the previous, iirc, M-q and/or word-wrapping would wrap w.r.t. the indentation of the current (sub-)list item.) cheers, Greg ps -- Gustavo, again, thanks. > You (plural) could probably also get some juice from looking into, and > incorporating to muscle memory, `M-RET', `C-RET' and `C-j'. i tried that with the BSD users. there, it didn't sell. (almost) forty years, and a couple of thousand users, later, maybe it will take! (but, obviously, i sort of hope not, now that i'm vaguely on the other side of the table. :) best.
[PATCH] lisp/org.el: Allow hiding #+SUBTITLE: keyword via `org-hidden-keywords'
Titus von der Malsburg writes: > Subject: [PATCH] lisp/org.el: Allow hiding #+SUBTITLE: keyword via > `org-hidden-keywords' > > * lisp/org.el: Allow users to include 'subtitle in > `org-hidden-keywords' to hide #+SUBTITLE: keyword. > > This way #+SUBTITLE is treated like similar keywords for title, date, > e-mail, and author. Thanks, sounds good. > --- > lisp/org.el | 1 + > 1 file changed, 1 insertion(+) Could you add an entry to ORG-NEWS? > diff --git a/lisp/org.el b/lisp/org.el > index 73b270712..0d2fbddda 100644 > --- a/lisp/org.el > +++ b/lisp/org.el > @@ -3573,6 +3573,7 @@ appear in the buffer without the initial \"#+TITLE:\" > part." >:type '(set (const :tag "#+AUTHOR" author) > (const :tag "#+DATE" date) > (const :tag "#+EMAIL" email) > + (const :tag "#+SUBTITLE" subtitle) > (const :tag "#+TITLE" title))) Please add :package-version '(Org . "9.5") dropping the current ':version "24.1"'.
Re: Changed list indentation behavior: how to revert?
Kévin Le Gouguec writes: > Detlef Steuer writes: > Note that indenting section bodies by default predates Org 9.4: in Org > 9.3, hitting TAB on the first line of text after a heading indents it to > column LEVEL+1. Yes, org-adapt-indentation has been around (with a default of t) since 4be4c5623 (version 4.12a, 2008-01-31). > IMHO, the default value of org-adapt-indentation might be the issue here > (made more visible by the change in 9.4): I agree that hard-indenting > prose should not be the default behaviour. FWIW the .dir-locals.el file > at the root of Org's own repository sets this variable to nil; maybe > that suggests that it would be a better default? Perhaps. I certainly prefer org-adapt-indentation at nil and would vote for that if we were introducing the option today, but this would be changing a longstanding default. So, it seems that changing Org to honor electric-indent-mode is now making some users aware of org-adapt-indentation and that its default value is not what they want.
Re: Changed list indentation behavior: how to revert?
* Kévin Le Gouguec [2020-11-16 01:00]: :PROPERTIES: :CREATED: [2020-11-16 Mon 01:15] :ID: bd11f325-c034-4f9b-baa6-b7d606af3cbb :END: > - Plenty of Org users do not expect it to behave like programming modes > wrt indentation (they might not even use programming modes). > > - These users were using RET as a "dumb newline" command, unaware > that by default, Org considers that text should be indented. You have all nice good points, thank you. My confusion comes from the below advertised liberties: - Org Mode - Your life in plain text - A GNU Emacs major mode for convenient plain text markup — and much more. And so all the time I have expected Org to be very liberal. I could write it in any mode, any editor, and I could still use it back in Emacs. Special stuff as I understood it since beginning is just header, properties or tags and tables and special blocks. Everything else should be liberal. Using RET as newline, yes. This is only how I was hooked onto Org. Side notes: Personally I would like Org to be either rigid or not rigid and liberal. It is either one of those. Indentation by default is nowhere. Neither rigid or not rigid as it is not mature feature. It is hard to express me. I have given examples when indentation is not following with itself. But if all other functions are following nicely with indentation AND bunch of users seek that, why not. When copying subtrees into different headings, identation is not always following nicely. When demoting upmoting headings, is not following nicely.
Re: Changed list indentation behavior: how to revert?
Jean Louis writes: > There is just slight difference, and that is what I learned from > introduction to Org mode that it is "plain text" kind of mode. I can > do and write how I wish. My habit comes from being used to indent when > I want and then to follow indentation in that specific paragraph. That > is really great. > > But I was not used to have it indented by programmer like the > introduction of this new default feature, which I consider is not > useful to be default. Note that even before this change, Org's indentation already behaved like a "programming mode". TAB does not allow you to move to "any column": - either org-adapt-indentation is t (the default) and TAB moves your paragraph to column LEVEL+1, - or it is nil, and TAB is a no-op. > Observe this official presentation and you will see how current > indentation is not consistent to what is shown: > https://orgmode.org/resources/img/features/folding.gif > > Look at this official presentation and you will see that even headings > are indented for which we say it should not be so: > https://orgmode.org/resources/img/features/clocking.svg Yep, AFAICT this has been produced with org-indent-mode, which soft-indents using overlays. > The official presentation here: > https://orgmode.org/ > > does not show any indentation at all. > > And in Info file I find nothing of it. Yep; what this (along with the way org-adapt-indentation is unset in Org's own repo) suggests to me is that Org, by default, should not indent section bodies. This means *not only* that RET should not indent, but that /TAB/ should not rigidly indent to column LEVEL+1 (I don't have a strong opinion about whether it should rigidly indent to column 0, or if it should behave as in text-mode). So AFAIU the issue lies not with RET becoming consistent with the rest of Emacs and doing "insert newline then indent smartly"; rather it lies with how Org defines "smartly". From what I gather from this thread, lots of folks would like Org to keep section bodies at column 0. > All I say, when default is introduced, should be well documented how > and why. Before it is introduced it is better to discuss wider with > people. > > Few of people reading these exchanges may find how to turn it off, > majority will not find it. Before being applied, this change has been discussed on emacs-devel and emacs-orgmode; it has then been documented in ORG-NEWS. Which other places do you think we should have reached out to? >> IIUC this can be toggled off by setting org-adapt-indentation to nil; >> FWIW this is what the .dir-locals.el file at the root of Org's >> repository doe > > With 2000+ directories containing Org file of persons, held on this > system that would mean turning it on 2000+ times. Because in general I > do not use that type of indentation I have just set it in main > ~/.emacs.d/init.el file. > > We concluded that configuring is easy and that is great. > > What is not concluded is that the default impacts too many people who > may not find out how to configure it back and that designing user > interface shall be made with more care. I admit to not having put as much thought in a "migration plan" as I could have. My reasoning was that since Org indents text by default (/when/ hitting TAB or using the "smart newline" command), users were probably fine with it. IIUC I failed to understand that: - Plenty of Org users do not expect it to behave like programming modes wrt indentation (they might not even use programming modes). - These users were using RET as a "dumb newline" command, unaware that by default, Org considers that text should be indented. - org-adapt-indentation… - exists (really, I just found out about it today, after wondering why on Earth Org does not indent text in doc/org-guide.org, and tracing it to the repository's directory-local variables). - has a default value that does not reflect how Org text is indented in official examples, nor in Org's own repository.
Re: Changed list indentation behavior: how to revert?
* Gustavo Barros [2020-11-15 17:51]: > > I do, thank you for reminder. Us in plural are sometimes teachers or > > mentors who educate other people who are supposed to edit Org files in > > most simple manner, and those people will never be able to write to > > this list to find out which option where, not even to know about > > indentation things. When default is introduced then all people > > following an educator has to turn off default. They will not even know > > why. One default introduced can cause butterfly effect. > > > > Also a fellow teacher here. As you, I'm trying to transmit this information > to you and others, because I find it useful. Nobody needs to use `M-RET', > `C-RET' and `C-j'. You are right, I am totally in agreement that it is useful as a feature. In general I am using electric-indent mode. Though that it is introduced by default is arguable what can be seen in responses here. > > General design of user interface should not conquer their habits > > unless substantial amount of users have demanded it so. > > And how exactly would maintainers know that? Do you claim to be speaking on > their (substantial amount of users) behalf? In this specific case it is easy to know what was the condition before and what is condition after introduction of that new feature. Somebody offered reasoning and I have seen 3-4 people declaring that function works OK. Super fine. But that is not reasoning enough to change some default behavior of a program for maybe hundreds of thousands of users. Better reasoning could be to ask on the mailing list what people think about it and how they are using indentation as that way more information may be obtained if such or any new feature would be more useful or contraproductive for users. You ask them. > Please, don't confuse. I said you should *not* use (the command) > `org-indent-region' if you were systematically manually overriding > indentation defaults. I recommended to set the user option > `org-adapt-indentation' to nil, which seems to be the desired value > for most of the manifestations on this thread. Maybe I made a mistake, as that is exactly what I did set. I am using Org for some years, so of course it came to me very surprising. Person who just start using it recently with such defaults should rarely find it awkward as person learns about it and assumes it is how it is.
Re: Changed list indentation behavior: how to revert?
* Kévin Le Gouguec [2020-11-15 15:45]:
:PROPERTIES:
:CREATED: [2020-11-15 Sun 16:26]
:ID: e454756a-3123-42dc-8c44-8682f12927ad
:END:
> Jean Louis writes:
>
> > Indentation in fundamental mode:
> >
> > ** HereRET
> > I come here.
> > But only if I start indenting
> >Like hereRET
> >Then I continue here
>
> Hi Jean,
>
> My understanding of electric-indent-mode is that it tries to make "RET"
> equivalent to "insert newline; indent according to major mode rules".
> E.g. in c-mode, when point is after the brace:
>
> if (condition) {
>
> RET will move point to column 2, while C-j will just insert a newline
> and stay at column 0.
> Likewise in python-mode, when point is after the colon:
>
> def foobar():
>
> RET will insert a newline and move point to column 4; C-j will stay at
> column 0.
>
> Your counter-example in fundamental-mode only shows that there are no
> "smart indentation" rules in this mode; hitting TAB more than once keeps
> on inserting horizontal space unconditionally instead of snapping to the
> "correct" indentation level.
I know it behaves different in different modes.
And there is also to consider (which I did not test in many modes)
that in majority of modes not being programming language user may move
either with TAB or SPC to any column and RET will be aligned to begin
of that previous line.
anywhere
this lines alignes with the first one
Which is generally good think.
There is just slight difference, and that is what I learned from
introduction to Org mode that it is "plain text" kind of mode. I can
do and write how I wish. My habit comes from being used to indent when
I want and then to follow indentation in that specific paragraph. That
is really great.
But I was not used to have it indented by programmer like the
introduction of this new default feature, which I consider is not
useful to be default.
> I've used Emacs's programming language modes for years before finally
> trying out Org, where I noticed that the keys were swapped: RET was the
> "plain dumb newline" key, and C-j was the "smart newline-then-indent"
> key. IIUC this was how the rest of Emacs behaved before
> electric-indent-mode became enabled by default.
>
> I personally found the difference infuriating. Everywhere else in
> Emacs,
> - C-m and do smart indentation,
> - C-j ≡ ^J ≡ (insert "\N{LINE FEED (LF)}")
I understand it for you, you got also surprised as you were used to it.
> The changes in Org 9.4 aimed to make Org consistent with this "new"
> convention, so that hitting RET immediately indents paragraphs below a
> heading (as if the user hit TAB right after inserting a newline), and a
> user wishing to "just insert some vertical space" can just whale on
> C-j.
Somehow I protest against it as it is not what I learned from roots of
Org writing, so introducing it as default is breaking habits and
consistency.
Observe this official presentation and you will see how current
indentation is not consistent to what is shown:
https://orgmode.org/resources/img/features/folding.gif
Look at this official presentation and you will see that even headings
are indented for which we say it should not be so:
https://orgmode.org/resources/img/features/clocking.svg
The official presentation here:
https://orgmode.org/
does not show any indentation at all.
And in Info file I find nothing of it.
All I say, when default is introduced, should be well documented how
and why. Before it is introduced it is better to discuss wider with
people.
Few of people reading these exchanges may find how to turn it off,
majority will not find it.
> FWIW, what I wonder about is /why/ Org hard-indents section bodies by
> default (org-indent-mode, which I use, soft-indents instead using
> overlays).
>
> IIUC this can be toggled off by setting org-adapt-indentation to nil;
> FWIW this is what the .dir-locals.el file at the root of Org's
> repository doe
With 2000+ directories containing Org file of persons, held on this
system that would mean turning it on 2000+ times. Because in general I
do not use that type of indentation I have just set it in main
~/.emacs.d/init.el file.
We concluded that configuring is easy and that is great.
What is not concluded is that the default impacts too many people who
may not find out how to configure it back and that designing user
interface shall be made with more care.
Re: Changed list indentation behavior: how to revert?
Hi Jean, On Sun, 15 Nov 2020 at 09:09, Jean Louis wrote: That is useful. I'm glad to hear that. You (plural) could probably also get some juice from looking into, and incorporating to muscle memory, `M-RET', `C-RET' and `C-j'. I do, thank you for reminder. Us in plural are sometimes teachers or mentors who educate other people who are supposed to edit Org files in most simple manner, and those people will never be able to write to this list to find out which option where, not even to know about indentation things. When default is introduced then all people following an educator has to turn off default. They will not even know why. One default introduced can cause butterfly effect. Also a fellow teacher here. As you, I'm trying to transmit this information to you and others, because I find it useful. Nobody needs to use `M-RET', `C-RET' and `C-j'. General design of user interface should not conquer their habits unless substantial amount of users have demanded it so. And how exactly would maintainers know that? Do you claim to be speaking on their (substantial amount of users) behalf? For me is now better to simple adjust: org-indent-region variable just as you said. Please, don't confuse. I said you should *not* use (the command) `org-indent-region' if you were systematically manually overriding indentation defaults. I recommended to set the user option `org-adapt-indentation' to nil, which seems to be the desired value for most of the manifestations on this thread. Best regards, Gustavo.
Re: Changed list indentation behavior: how to revert?
Detlef Steuer writes: > I'm constantly bitten by that change, but was too lazy to dig for the > cause. But now that I know, I want to add 2c. > > If one writes prose it looks much more natural to have > > * Healine > > start editing in column 1 of next row. > (Personally I would prefer to start at row 3, but independent > of the depth of the heading. Probably there is a setting already?) > > C-j is fine and nice, but I *feel* the default should be the other > way round. > > I'm in no way emotional about these changes, but as Arne demonstrates > in his example text, org files become less readable when using the new > default. Heavy indenting is not what we are used to see if we have > subheadings in prose. Readability of org on the screen should be very high > in list of usability target. (Most probably it indeed is for the developers! > I'm not assuming you would neglect it!) > Maybe all boils down to a matter of taste, but at least imho Arne's > example shows the problem quite clearly. > > For lists or sequences of mostly empty headings this does not matter > as much. > > Furthermore: If I understand correctly electric-ident mode is thought to > be a helper for programming major modes. In my opinion org is no (not > only, much more than a) programming mode, so maybe electric ident is not > the optimal default. Note that indenting section bodies by default predates Org 9.4: in Org 9.3, hitting TAB on the first line of text after a heading indents it to column LEVEL+1. IMHO, the default value of org-adapt-indentation might be the issue here (made more visible by the change in 9.4): I agree that hard-indenting prose should not be the default behaviour. FWIW the .dir-locals.el file at the root of Org's own repository sets this variable to nil; maybe that suggests that it would be a better default? (As I said in my reply to Jean Louis: I've only skimmed over this thread; apologies if I've missed anything.)
Re: Changed list indentation behavior: how to revert?
* Gustavo Barros [2020-11-15 14:49]: :PROPERTIES: :CREATED: [2020-11-15 Sun 15:09] :ID: fef3cdfd-8870-4471-bcc7-4d690bfaceb2 :END: > I'm quite surprised by the reaction to this issue, because > `electric-indent-mode' *does not change Org's indentation settings*, it > just applies them alongside RET. Which makes me think that those who've > been so bitten by it where actually manually overriding (their own) > settings in this area by never applying indentation. If that's your > case, you'd probably be very surprised of running `org-indent-region' in > your documents (don't do it, I don't want to break them). > > In particular, one "surprising" result of the "new behavior" is that of > indentation after a heading. That was already and continues to be > controlled by the user option `org-adapt-indentation'. If you don't > want your content to be indented after a heading, set it to nil. And > `electric-indent-mode' should do what you expect in this regard. That is useful. What is not useful is introducing default to thousands of users without asking at least 1% of them. I have 2456 Org files on my system and inconsistency introduced only on my system also affects people like me and those who receive Org files produced on my system. What about other users among 1% of them... I propose that NEWS and Info files shall include pointers from indentation descriptions to that option, as authors considered including function to turn off electric indent mode, while it is now obvious that this function here already does the work. So documentation and NEWS shall be updated. > An example from Greg: > > > - > > * i wanted a headline > > * i wanted a subhead, but it's ignored by org mode > > - > > That's because the first one is indeed a heading, and the second is not, > it is a plain list item. By definition a heading must start at the > left margin. That I did not know. Maybe I remember wrong but back in time even indented headings worked. Now I have tested it they do not work, so they need to be on the first column on left side. Side thought: what about hebrew and arabic, how does Org mode work for those languages? > You (plural) could probably also get some juice from looking into, and > incorporating to muscle memory, `M-RET', `C-RET' and `C-j'. I do, thank you for reminder. Us in plural are sometimes teachers or mentors who educate other people who are supposed to edit Org files in most simple manner, and those people will never be able to write to this list to find out which option where, not even to know about indentation things. When default is introduced then all people following an educator has to turn off default. They will not even know why. One default introduced can cause butterfly effect. General design of user interface should not conquer their habits unless substantial amount of users have demanded it so. > Of course, with that said, if you really don't like > `electric-indent-mode' for Org, you can disable it as described in > the Org News, previously linked to in this thread. There is ground > to prefer this, particularly for the list case, mentioned by Karl in > the original message of this thread. But `electric-indent-mode' > does not induce a new pattern of indentation for Org, it just > applies your settings in this area, whose defaults have not changed > of recent, as far as I recall. Finally, the "change" was not > brought about by Org, but by Emacs. Org just (belatedly) tagged > along. Best regards, Gustavo. For me is now better to simple adjust: org-indent-region variable just as you said. Thank you for references.
Re: Changed list indentation behavior: how to revert?
Jean Louis writes:
> Indentation in fundamental mode:
>
> ** HereRET
> I come here.
> But only if I start indenting
>Like hereRET
>Then I continue here
Hi Jean,
My understanding of electric-indent-mode is that it tries to make "RET"
equivalent to "insert newline; indent according to major mode rules".
E.g. in c-mode, when point is after the brace:
if (condition) {
RET will move point to column 2, while C-j will just insert a newline
and stay at column 0.
Likewise in python-mode, when point is after the colon:
def foobar():
RET will insert a newline and move point to column 4; C-j will stay at
column 0.
Your counter-example in fundamental-mode only shows that there are no
"smart indentation" rules in this mode; hitting TAB more than once keeps
on inserting horizontal space unconditionally instead of snapping to the
"correct" indentation level.
I've used Emacs's programming language modes for years before finally
trying out Org, where I noticed that the keys were swapped: RET was the
"plain dumb newline" key, and C-j was the "smart newline-then-indent"
key. IIUC this was how the rest of Emacs behaved before
electric-indent-mode became enabled by default.
I personally found the difference infuriating. Everywhere else in
Emacs,
- C-m and do smart indentation,
- C-j ≡ ^J ≡ (insert "\N{LINE FEED (LF)}")
The changes in Org 9.4 aimed to make Org consistent with this "new"
convention, so that hitting RET immediately indents paragraphs below a
heading (as if the user hit TAB right after inserting a newline), and a
user wishing to "just insert some vertical space" can just whale on C-j.
FWIW, what I wonder about is /why/ Org hard-indents section bodies by
default (org-indent-mode, which I use, soft-indents instead using
overlays).
IIUC this can be toggled off by setting org-adapt-indentation to nil;
FWIW this is what the .dir-locals.el file at the root of Org's
repository does…
I haven't read this whole thread thoroughly; I've had trouble staying on
top of Emacs's mailing lists this week.
Apologies if I've missed something, and thanks for your patience.
buggy plantuml function
(defun org-babel-plantuml-make-body (body params) "Return PlantUML input string. BODY is the content of the source block and PARAMS is a property list of source block parameters. This function relies on the `org-babel-expand-body:generic' function to extract `:var' entries from PARAMS and on the `org-babel-variable-assignments:plantuml' function to convert variables to PlantUML assignments. If BODY does not contain @startXXX ... @endXXX clauses, @startuml ... @enduml will be added." (let ((assignments (org-babel-variable-assignments:plantuml params))) (if (string-prefix-p "@start" body t) assignments (format "@startuml\n%s\n@enduml" (org-babel-expand-body:generic body params assignments) expands to assignments if the body starts with @startmindmap? Immanuel -- -- Researching the dual problem of finding the function that has a given point as fixpoint.
Re: Changed list indentation behavior: how to revert?
Am Sun, 15 Nov 2020 08:48:56 -0300 schrieb Gustavo Barros : > Hi All, > > On Sun, 15 Nov 2020 at 13:37, Greg Minshall > wrote: > > > hi, all. > > > > David Rogers wrote: > > > >> Am I crazy to say that your last example of unwanted behavior is > >> easier for me to read and understand? (and to me the common > >> indenting is a hopeless mess?) > > > > yes, in fact, the "new" way sort of has the buffer indentation match > > that of the outline structure of the file (specified by asterisks). > > there's a lot to be said for that. (though, obviously, it's not > > what everyone would want.) > > > > if the new mode stays as the standard, maybe we'd want to capture an > > asterisk typed immediately after a newline that would (by default), > > put that line-beginning asterisk back in column one? > > > > otherwise, this is what one gets (without remembering to do a C-j > > instead of ): > > - > > * i wanted a headline > > * i wanted a subhead, but it's ignored by org mode > > - > > which is maybe not optimal? > > > > in most non-org modes (including in Org Src... buffers, and in org > > files when writing org-mode lists), i'm a big fan of electric > > indent mode. > > > > maybe an org-specific setting, "org-file-indent-follows-structure"? > > if true, it means the user wants to have a "raw" org document laid > > out according to the outline structure of the document. if false, > > it means one, in general, wants the org file laid out with > > left-alignment (or, right, in right-to-left) languages (not > > including embedded lists, and whatever else i might be ignoring). > > > > cheers, Greg > > I'm quite surprised by the reaction to this issue, because > `electric-indent-mode' *does not change Org's indentation settings*, > it just applies them alongside RET. Which makes me think that those > who've been so bitten by it where actually manually overriding (their > own) settings in this area by never applying indentation. If that's > your case, you'd probably be very surprised of running > `org-indent-region' in your documents (don't do it, I don't want to > break them). > > In particular, one "surprising" result of the "new behavior" is that > of indentation after a heading. That was already and continues to be > controlled by the user option `org-adapt-indentation'. If you don't > want your content to be indented after a heading, set it to nil. And > `electric-indent-mode' should do what you expect in this regard. > > I'm not sure if thus overriding your own (or Org's, if you prefer) > indentation settings by selectively applying indentation is a sane > approach, so perhaps `electric-indent-mode' may help you discipline > your editing to your benefit. And make you more conscious of Org > indentation. Especially because indentation is not a "free variable" > in Org, it is a syntactical aspect of an Org document and, > conspicuously, is critical to the definition of a heading and of > plain lists. > > An example from Greg: > > > - > > * i wanted a headline > > * i wanted a subhead, but it's ignored by org mode > > - > > That's because the first one is indeed a heading, and the second is > not, it is a plain list item. By definition a heading must start at > the left margin. > > You (plural) could probably also get some juice from looking into, and > incorporating to muscle memory, `M-RET', `C-RET' and `C-j'. > > Of course, with that said, if you really don't like > `electric-indent-mode' for Org, you can disable it as described in the > Org News, previously linked to in this thread. There is ground to > prefer this, particularly for the list case, mentioned by Karl in the > original message of this thread. But `electric-indent-mode' does not > induce a new pattern of indentation for Org, it just applies your > settings in this area, whose defaults have not changed of recent, as > far as I recall. > > Finally, the "change" was not brought about by Org, but by Emacs. Org > just (belatedly) tagged along. > > Best regards, > Gustavo. > Thank you for clearing that up! Detlef
Re: Changed list indentation behavior: how to revert?
Hi All, On Sun, 15 Nov 2020 at 13:37, Greg Minshall wrote: > hi, all. > > David Rogers wrote: > >> Am I crazy to say that your last example of unwanted behavior is >> easier for me to read and understand? (and to me the common >> indenting is a hopeless mess?) > > yes, in fact, the "new" way sort of has the buffer indentation match > that of the outline structure of the file (specified by asterisks). > there's a lot to be said for that. (though, obviously, it's not what > everyone would want.) > > if the new mode stays as the standard, maybe we'd want to capture an > asterisk typed immediately after a newline that would (by default), put > that line-beginning asterisk back in column one? > > otherwise, this is what one gets (without remembering to do a C-j > instead of ): > - > * i wanted a headline > * i wanted a subhead, but it's ignored by org mode > - > which is maybe not optimal? > > in most non-org modes (including in Org Src... buffers, and in org files > when writing org-mode lists), i'm a big fan of electric indent mode. > > maybe an org-specific setting, "org-file-indent-follows-structure"? if > true, it means the user wants to have a "raw" org document laid out > according to the outline structure of the document. if false, it means > one, in general, wants the org file laid out with left-alignment (or, > right, in right-to-left) languages (not including embedded lists, and > whatever else i might be ignoring). > > cheers, Greg I'm quite surprised by the reaction to this issue, because `electric-indent-mode' *does not change Org's indentation settings*, it just applies them alongside RET. Which makes me think that those who've been so bitten by it where actually manually overriding (their own) settings in this area by never applying indentation. If that's your case, you'd probably be very surprised of running `org-indent-region' in your documents (don't do it, I don't want to break them). In particular, one "surprising" result of the "new behavior" is that of indentation after a heading. That was already and continues to be controlled by the user option `org-adapt-indentation'. If you don't want your content to be indented after a heading, set it to nil. And `electric-indent-mode' should do what you expect in this regard. I'm not sure if thus overriding your own (or Org's, if you prefer) indentation settings by selectively applying indentation is a sane approach, so perhaps `electric-indent-mode' may help you discipline your editing to your benefit. And make you more conscious of Org indentation. Especially because indentation is not a "free variable" in Org, it is a syntactical aspect of an Org document and, conspicuously, is critical to the definition of a heading and of plain lists. An example from Greg: > - > * i wanted a headline > * i wanted a subhead, but it's ignored by org mode > - That's because the first one is indeed a heading, and the second is not, it is a plain list item. By definition a heading must start at the left margin. You (plural) could probably also get some juice from looking into, and incorporating to muscle memory, `M-RET', `C-RET' and `C-j'. Of course, with that said, if you really don't like `electric-indent-mode' for Org, you can disable it as described in the Org News, previously linked to in this thread. There is ground to prefer this, particularly for the list case, mentioned by Karl in the original message of this thread. But `electric-indent-mode' does not induce a new pattern of indentation for Org, it just applies your settings in this area, whose defaults have not changed of recent, as far as I recall. Finally, the "change" was not brought about by Org, but by Emacs. Org just (belatedly) tagged along. Best regards, Gustavo.
Re: Changed list indentation behavior: how to revert?
Greg Minshall writes: > hi, all. > > David Rogers wrote: > >> Am I crazy to say that your last example of unwanted behavior is >> easier for me to read and understand? (and to me the common >> indenting is a hopeless mess?) > > yes, in fact, the "new" way sort of has the buffer indentation match > that of the outline structure of the file (specified by asterisks). > there's a lot to be said for that. (though, obviously, it's not what > everyone would want.) > > if the new mode stays as the standard, maybe we'd want to capture an > asterisk typed immediately after a newline that would (by default), put > that line-beginning asterisk back in column one? > I think this would be a great improvement. It is probably more comon that that when you type an asterisk as the first character in the line you want it to be a header and therefore, in the first column. On rare occasions when you do want an asterisk at the beginning of the line, you can indent it manually. > otherwise, this is what one gets (without remembering to do a C-j > instead of ): > - > * i wanted a headline > * i wanted a subhead, but it's ignored by org mode > - > which is maybe not optimal? > > in most non-org modes (including in Org Src... buffers, and in org files > when writing org-mode lists), i'm a big fan of electric indent mode. > > maybe an org-specific setting, "org-file-indent-follows-structure"? if > true, it means the user wants to have a "raw" org document laid out > according to the outline structure of the document. if false, it means > one, in general, wants the org file laid out with left-alignment (or, > right, in right-to-left) languages (not including embedded lists, and > whatever else i might be ignoring). > Seems like a reasonable approach to me. -- Tim Cross
Re: Changed list indentation behavior: how to revert?
> > > Am I crazy to say that your last example of unwanted behavior is > > easier for me to read and understand? (and to me the common > > indenting is a hopeless mess?) > > I think the second becomes horribly hard to read if you have more than > one line in the body. I use org-mode for writing long prose and having > all my text indented is pretty annoyming. I’ve tried to ignore and > work around it for some time now because I assumed it was a bug but > didn’t have a clear view when it appears. > Just like Arne I thought it to be some kind or quirk in the code that would self-heal at some point in time. I'm constantly bitten by that change, but was too lazy to dig for the cause. But now that I know, I want to add 2c. If one writes prose it looks much more natural to have * Healine start editing in column 1 of next row. (Personally I would prefer to start at row 3, but independent of the depth of the heading. Probably there is a setting already?) C-j is fine and nice, but I *feel* the default should be the other way round. I'm in no way emotional about these changes, but as Arne demonstrates in his example text, org files become less readable when using the new default. Heavy indenting is not what we are used to see if we have subheadings in prose. Readability of org on the screen should be very high in list of usability target. (Most probably it indeed is for the developers! I'm not assuming you would neglect it!) Maybe all boils down to a matter of taste, but at least imho Arne's example shows the problem quite clearly. For lists or sequences of mostly empty headings this does not matter as much. Furthermore: If I understand correctly electric-ident mode is thought to be a helper for programming major modes. In my opinion org is no (not only, much more than a) programming mode, so maybe electric ident is not the optimal default. Just one more opinion. Detlef
Re: Changed list indentation behavior: how to revert?
David Rogers writes: >> Common indenting in Org mode is: >> >> * Heading >> Text >> ** Heading >> Text >> *** Heading text >> Text >> Heading >> Text here >> * Heading >> Text >> ** Heading >> Text >> >> AND if somebody likes to indent differently electric indent mode >> would help. >> >> Common indenting is not (other may tell me that I am wrong if this >> statement is wrong) >> >> * Heading >> Text >> ** Heading >>Text >> *** Heading text >> Text >> Heading >> Text here >> * Heading >> Text >> ** Heading >>Text >> >> The above change was introduced as default to many users and is not >> conveniente. > Am I crazy to say that your last example of unwanted behavior is > easier for me to read and understand? (and to me the common > indenting is a hopeless mess?) I think the second becomes horribly hard to read if you have more than one line in the body. I use org-mode for writing long prose and having all my text indented is pretty annoyming. I’ve tried to ignore and work around it for some time now because I assumed it was a bug but didn’t have a clear view when it appears. I have text like this: Exilanten: Clanjäger-Fuchsmenschen *Fuchsmenschen mit Berserkererbe, das die Realität wanken lässt. Jäger mit starken Sinnen, denen Gruppe und Clan stabilen Halt geben.* Außensicht: /Einst unaufhaltsame Berserker, heute an ihre Clansregeln gebundene Jäger, Piloten und Leibwächter. Sie erkennen mehr, als sie zeigen./ Innensicht: /Der Clan ist deine Familie, die Tradition der Jagd dein Halt in der Welt. Wenn deine Sinne die gesamte Welt zu durchdringen scheinen, ist dein Biest nicht weit./ … * Kernantriebe #+caption: Kernantriebe der Ranmex #+attr_latex: :placement [H] #+tblname: kernantriebe-ranmex | Wollen | Handeln | Sein | |+---+| | Ansehen| Tradition | Leistungsstark | | Sicherheit | Anpassung | Zuverlässig| | Genugtuung | Unterstützung | Loyal | … ** Beispiel: Chessos Reluna - Beschreibung: Geschäftstüchtiger und kampferprobter Ranmex. - Zitat: „Was kriegen wir dafür?“ - Motivation: Will genug Geld verdienen, um ein großes, kampftaugliches Schiff für einen eigenen Clan zu kaufen. Eigenschaften: - Sehr Geschäftstüchtig: + (15) Berufe: - Söldner: + (9) - Pilot: + (9) … From here: https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/ews.org?rev=b8e3899c6d8b#L2644 > Does the new behavior “break” something for you (causing errors etc), > or does it just look wrong? It becomes much harder to work in prose. What you’ll note in my files is that they all have #+STARTUP: hidestars So the above does not look to me like ** Beispiel: Chessos Reluna - Beschreibung: Geschäftstüchtiger und kampferprobter Ranmex. - Zitat: „Was kriegen wir dafür?“ - Motivation: Will genug Geld verdienen, um ein großes, kampftaugliches Schiff für einen eigenen Clan zu kaufen. But like * Beispiel: Chessos Reluna - Beschreibung: Geschäftstüchtiger und kampferprobter Ranmex. - Zitat: „Was kriegen wir dafür?“ - Motivation: Will genug Geld verdienen, um ein großes, kampftaugliches Schiff für einen eigenen Clan zu kaufen. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: Changed list indentation behavior: how to revert?
hi, all. David Rogers wrote: > Am I crazy to say that your last example of unwanted behavior is > easier for me to read and understand? (and to me the common > indenting is a hopeless mess?) yes, in fact, the "new" way sort of has the buffer indentation match that of the outline structure of the file (specified by asterisks). there's a lot to be said for that. (though, obviously, it's not what everyone would want.) if the new mode stays as the standard, maybe we'd want to capture an asterisk typed immediately after a newline that would (by default), put that line-beginning asterisk back in column one? otherwise, this is what one gets (without remembering to do a C-j instead of ): - * i wanted a headline * i wanted a subhead, but it's ignored by org mode - which is maybe not optimal? in most non-org modes (including in Org Src... buffers, and in org files when writing org-mode lists), i'm a big fan of electric indent mode. maybe an org-specific setting, "org-file-indent-follows-structure"? if true, it means the user wants to have a "raw" org document laid out according to the outline structure of the document. if false, it means one, in general, wants the org file laid out with left-alignment (or, right, in right-to-left) languages (not including embedded lists, and whatever else i might be ignoring). cheers, Greg
Re: S-RET
> you can find a lot of functions like the ones in jupyter at > https://github.com/jkitchin/scimax/blob/master/scimax-ob.el. I setup my > ipython like this: > https://github.com/jkitchin/scimax/blob/master/scimax-org-babel-ipython-upstream.el#L89 > > although I will note there are several setups in that file, e.g. this > hydra: > https://github.com/jkitchin/scimax/blob/master/scimax-org-babel-ipython-upstream.el#L271 > … > I don't use them all, but leave them to remind me sometimes. Thanks, the number of supported features is impressive! I see that the file name contains the word 'upstream'. This implies a set of patches to upstream modules. Are there any plans to submit upstream at least some of the most often used commands that correspond to basic Jupyter shortcuts? For example, it would make sense to bring scimax-execute-and-next-block under the org-babel namespace as e.g. org-babel-execute-src-block-and-next-block in the upstream ob-core.el. Then S-RET will be available to other ob backends (such as ob-ruby.el that I use often too.)
Re: Changed list indentation behavior: how to revert?
* David Rogers [2020-11-15 10:48]: :PROPERTIES: :CREATED: [2020-11-15 Sun 11:53] :ID: e9973880-3447-42c6-99e4-2a0b430d136b :END: > Jean Louis writes: > > > * David Rogers [2020-11-15 01:44]: > > > Hello > > > > > > After reading several of the responses to this, I’ve started to > > > wonder: Is > > > electric-indent-mode broken for everybody because it contains a bug > > > or > > > design flaw, or is electric-indent-mode working fine but simply not > > > suitable > > > for every situation? > > > > > > In other words, where is the “right” place to fix this problem? > > > > It was working in Org file automatically well and fine. > > > > As if user decides to indent, electric-indent would help the user: > > > > ** HeadingRET > > > > At this point below user may decide to indent: > > > >- First itemRET after RET > >^ > >- the new line appears here > > > > User has to move the cursor to the point shown above for indentation > > to begin. That is good as user decides it and it is text, it is not > > programming language with special convention for indentation. > > > > Electric indent mode always worked like that, including in Org mode > > without any problems. > > > > The change that is introduced in my opinion, and I did not look into > > code, is changing how electric indent mode behaves specifically for > > Org mode as somebody assumes that immediately after headingRET the new > > lines should be indented, like if there is some special indentation > > convention for Org mode. > > > > So without user deciding to indent, it does following: > > > > ** HeadingRET > >- First line here > > But there is no indentation convetion for Org mode of that kind that > > I > > know. > > > > The Org file shown on https://orgmode.org/ does not follow that type > > of indenting. > > > > Common indenting in Org mode is: > > > > * Heading > > Text > > ** Heading > > Text > > *** Heading text > > Text > > Heading > > Text here > > * Heading > > Text > > ** Heading > > Text > > > > AND if somebody likes to indent differently electric indent mode would > > help. > > > > Common indenting is not (other may tell me that I am wrong if this > > statement is wrong) > > > > * Heading > > Text > > ** Heading > >Text > > *** Heading text > > Text > > Heading > > Text here > > * Heading > > Text > > ** Heading > >Text > > > > The above change was introduced as default to many users and is not > > conveniente. > > > > Especially not conveniente I find that I need to delete by using > > backspace all the spaces inserted that I did not want after pressing > > RET after inserting heading. > > > > Some people will insert ONLY heading as a test without any text. > > Thank you! You’ve really explained this clearly, and I understand your > point. > Am I crazy to say that your last example of unwanted behavior is easier for > me to read and understand? (and to me the common indenting is a hopeless > mess?) I am not against indenting how users wish and want. That is why electric-indent is there, it is by default there. When you with your wanted behavior write this line: ** Heading :PROPERTIES: :CREATED: [2020-11-15 Sun 11:53] :ID: 4e00e232-bf01-4ba5-a87b-6b0a9747ecee :END: and press TAB, your cursor should automatically come to here below: ** Heading :PROPERTIES: :CREATED: [2020-11-15 Sun 11:53] :ID: be2a9fb6-bb27-416d-aa84-17e83a97f024 :END: ^ Then when you start writing a line: ** Heading :PROPERTIES: :CREATED: [2020-11-15 Sun 11:53] :ID: bb1feeb1-0e3c-429f-90a7-86b577f3b0c9 :END: Line here Next line automatically here Your next line is automatically there. Does programmer impose to you HOW to indent? No. You explicitly decide by using TAB and writing indented lines that you wish electric-indent mode to work for you. > If the new behavior really does what you showed under “Common > indenting is not…”, then I think I prefer the new way for my own > use. I prefer that every user can explicityl decide how to indent. User group that wish to indent exactly under the letter where heading begins, they can press TAB and continue doing it. It is one key press. If that is introduced as default then users with many Org files on file system are by default faced with inconvenience for the sake of those who find it convenient. > And it makes sense to me that it should automatically work like > that. I think the cursor jumping all the way back to the left margin > after I’ve created a multi-starred heading makes no sense. As you are indenting it that way I can understand that. I have tried that in past. Try M-S-left M-S-right on heading to see what is happening with such indentation if your heading was with more stars. If I write: * HeadingRET :PROPERTIES: :CREATED: [2020-11-15 Sun 11:53] :ID: b2aaa359-12d6-4e64-a5d8-ec02b0f79532 :END: - one line
