Various discussions convinced me that `org-adapt-indentation' should be nil by default. With `electric-indent-mode' being activated by default in Emacs, the current behavior is that RET after a headline moves the point below the beginning of this headline, not the beginning of the line, which might surprise users. Indentation is quite sensitive: what do you think of setting a new default value of nil for `org-adapt-indentation' in Org 9.5? -- Bastien
Bastien <bzg@gnu.org> writes:
> Various discussions convinced me that `org-adapt-indentation' should
> be nil by default.
>
> With `electric-indent-mode' being activated by default in Emacs, the
> current behavior is that RET after a headline moves the point below
> the beginning of this headline, not the beginning of the line, which
> might surprise users.
>
> Indentation is quite sensitive: what do you think of setting a new
> default value of nil for `org-adapt-indentation' in Org 9.5?
+1. I think it will be less surprising for users and those who want that
type of indentation can easily enable it.
--
Tim Cross
* Bastien <bzg@gnu.org> [2021-05-02 09:10]: > Various discussions convinced me that `org-adapt-indentation' should > be nil by default. > > With `electric-indent-mode' being activated by default in Emacs, the > current behavior is that RET after a headline moves the point below > the beginning of this headline, not the beginning of the line, which > might surprise users. > > Indentation is quite sensitive: what do you think of setting a new > default value of nil for `org-adapt-indentation' in Org 9.5? Yes, it should be nil just as it was in beginning. But there is one problem that I encountered since that was introduced, namely I do like properties being indented under the first letter of heading or on 3rd place. Like this below, however, C-c C-x p will create properties indented only if org-adapt-indentation is t * Heading :PROPERTIES: :ARCHIVE: new :END: But if org-adapt-indentation is nil, it will be like: * Heading :PROPERTIES: :ARCHIVE: new :END: and I remember that behavior before the introduced change was that properties were intended, which does look nicer for properties. But I definitely do not prefer cursor to come indentend after writing a header like: * Heading C ursor on C Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns Sign an open letter in support of Richard M. Stallman https://stallmansupport.org/ https://rms-support-letter.github.io/
Jean Louis <bugs@gnu.support> writes:
> * Bastien <bzg@gnu.org> [2021-05-02 09:10]:
>> Various discussions convinced me that `org-adapt-indentation' should
>> be nil by default.
>>
>> With `electric-indent-mode' being activated by default in Emacs, the
>> current behavior is that RET after a headline moves the point below
>> the beginning of this headline, not the beginning of the line, which
>> might surprise users.
>>
>> Indentation is quite sensitive: what do you think of setting a new
>> default value of nil for `org-adapt-indentation' in Org 9.5?
>
> Yes, it should be nil just as it was in beginning.
>
> But there is one problem that I encountered since that was introduced,
> namely I do like properties being indented under the first letter of
> heading or on 3rd place.
>
> Like this below, however, C-c C-x p will create properties indented
> only if org-adapt-indentation is t
>
> * Heading
> :PROPERTIES:
> :ARCHIVE: new
> :END:
>
> But if org-adapt-indentation is nil, it will be like:
>
> * Heading
> :PROPERTIES:
> :ARCHIVE: new
> :END:
>
> and I remember that behavior before the introduced change was that
> properties were intended, which does look nicer for properties.
>
> But I definitely do not prefer cursor to come indentend after writing a header like:
>
> * Heading
> C
> ursor on C
>
>
Sounds like you want the 'headline-data value for this variable. Please
check the documentation.
Note that there was a bug with this setting which has recently be fixed.
So if you tried it previously and found it didn't quite work correctly,
try it again in current maint version.
Jean Louis <bugs@gnu.support> writes: >> Indentation is quite sensitive: what do you think of setting a new >> default value of nil for `org-adapt-indentation' in Org 9.5? > > Yes, it should be nil just as it was in beginning. I think `org-adapt-indentation' has always been `t' by default. > But there is one problem that I encountered since that was introduced, > namely I do like properties being indented under the first letter of > heading or on 3rd place. > > Like this below, however, C-c C-x p will create properties indented > only if org-adapt-indentation is t > > * Heading > :PROPERTIES: > :ARCHIVE: new > :END: > > But if org-adapt-indentation is nil, it will be like: > > * Heading > :PROPERTIES: > :ARCHIVE: new > :END: I suggest (setq org-adapt-indentation 'headline-data). -- Bastien
Bastien <bzg@gnu.org> writes:
> I suggest (setq org-adapt-indentation 'headline-data).
With electric-indent-mode turned off, that is.
--
Bastien
On Sunday, 2 May 2021 at 08:09, Bastien wrote:
> Various discussions convinced me that `org-adapt-indentation' should
> be nil by default.
I have this set to nil in any case, in combination with org-indent-mode
and visual-line-mode, so would not have any problem with the change. I
do think a nil value would be more consistent with the rest of emacs.
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-405-g0a689b
Am Sun, 02 May 2021 08:09:02 +0200
schrieb Bastien <bzg@gnu.org>:
> Various discussions convinced me that `org-adapt-indentation' should
> be nil by default.
>
> With `electric-indent-mode' being activated by default in Emacs, the
> current behavior is that RET after a headline moves the point below
> the beginning of this headline, not the beginning of the line, which
> might surprise users.
>
> Indentation is quite sensitive: what do you think of setting a new
> default value of nil for `org-adapt-indentation' in Org 9.5?
>
I would like it.
Detlef
>>>>> Detlef Steuer <steuer@hsu-hh.de> writes:
> Am Sun, 02 May 2021 08:09:02 +0200 schrieb Bastien <bzg@gnu.org>:
>> Various discussions convinced me that `org-adapt-indentation'
>> should be nil by default.
>>
>> With `electric-indent-mode' being activated by default in Emacs,
>> the current behavior is that RET after a headline moves the point
>> below the beginning of this headline, not the beginning of the
>> line, which might surprise users.
>>
>> Indentation is quite sensitive: what do you think of setting a
>> new default value of nil for `org-adapt-indentation' in Org 9.5?
>>
> I would like it.
Not me. I most certainly would not appreciate a change in the default.
Bastien writes:
> Various discussions convinced me that `org-adapt-indentation' should
> be nil by default.
>
> With `electric-indent-mode' being activated by default in Emacs, the
> current behavior is that RET after a headline moves the point below
> the beginning of this headline, not the beginning of the line, which
> might surprise users.
>
> Indentation is quite sensitive: what do you think of setting a new
> default value of nil for `org-adapt-indentation' in Org 9.5?
+1 from me as well. I personally quite dislike indenting after headings
with spaces, and instead use (add-hook 'org-mode-hook #'org-indent-mode)
for the visual indentation effect, which I can easily toggle off when
needed.
Hi Bastien, Strong +1 here. Users can get the same visual effect without materializing the whitespace into the file. Materializing the whitespace causes many potential issues with source blocks for languages that have significant whitespace, issues with #+begin_src and #+end_src having different levels of indentation (still an issue if you want a block in a plain list), weirdness with noweb, obligatory two pass parsing to get the spacing correct in paragraphs, etc. There are many cases where adapting indentation requires the specification of extremely detailed heuristics that must be followed exactly in order to get at least a consistent parse of a source block. The only sane way forward for a language specification would be to avoid that leading whitespace or avoid trying to specify the interpretation of source blocks in contexts with leading whitespace (src blocks in plain lists may come back to haunt us here). Setting org-adapt-indentation to nil by default would be a major step toward resolving these issues and frankly I couldn't ask for more. Best! Tom PS I have included some notes on the worg/dev/org-syntax.org file that I wrote while working on the formal grammar. I would qualify what I wrote slightly to state that users could in principle have leading whitespace before source blocks but that the behavior of org in such cases would be left unspecified in the not quite nasal demons sense, but that it might be better to have the behavior described below with a note that no attempt to deal with correctly preserving leading whitespace is required, user beware. A final aside: maybe plain lists could have the #+begin_ and #+end_ lines indented to the level of the plain list but maybe not the body? ----------------------------- Eliminate leading whitespace in the canonical representation. There are other ways that make it possible to have the indentation visibility without adding massive complexity to the implementation. The existing implementation can continue to support it, but any other implementation SHALL convert indented sections to the canonical form where there is NO leading whitespace. This eliminates the problem of significant whitespace for everything except plain lists. Users will need a migration path and this will require extensive testing to make sure that the tooling catches as many of the issues as possible. However, the benefits in the long run are vastly reduced complexity without all the risks of accidentally botching an indent somewhere.
Hello, Tom Gillespie <tgbugs@gmail.com> writes: > Materializing the whitespace causes many potential issues with source > blocks for languages that have significant whitespace, issues with > #+begin_src and #+end_src having different levels of indentation > (still an issue if you want a block in a plain list), This is inaccurate. The following is a perfectly valid list. --8<---------------cut here---------------start------------->8--- 1. foo #+begin_src emacs-lisp (+ 1 1) #+end_src 2. bar --8<---------------cut here---------------end--------------->8--- Source blocks for languages that have significant whitespace should use the -i flag. > PS I have included some notes on the worg/dev/org-syntax.org > file that I wrote while working on the formal grammar. I would > qualify what I wrote slightly to state that users could in principle > have leading whitespace before source blocks but that the behavior of > org in such cases would be left unspecified in the not quite nasal > demons sense, but that it might be better to have the behavior > described below with a note that no attempt to deal with correctly > preserving leading whitespace is required, user beware. A final > aside: maybe plain lists could have the #+begin_ and #+end_ > lines indented to the level of the plain list but maybe not the body? What makes you think this is not the case? Regards, -- Nicolas Goaziou
On 5/1/2021 11:09 PM, Bastien wrote:
> With `electric-indent-mode' being activated by default in Emacs, the
> current behavior is that RET after a headline moves the point below
> the beginning of this headline, not the beginning of the line, which
> might surprise users.
>
> Indentation is quite sensitive: what do you think of setting a new
> default value of nil for `org-adapt-indentation' in Org 9.5?
I much prefer the current behavior as of 9.4.5. I'll try to explain my
reasoning. Of course like anyone, I'm biased, and got used to indenting
the text under a heading (pre-9.4) simply because that's where it ends
up if I hit TAB; in most other modes, TAB indents a line to where it
"should" be, so I reasoned that text under a heading should be indented.
Visually, I find indented text easier to scan. When my org document is
fully-expanded, I can still quickly glance at the left margin to see
when the outline level changes. It's much harder for me to do so when
there's a bunch of text that's flush with the left margin.
`org-indent-mode' can also do this, but I took to heart the Org Mode
motto ("Your life in plain text"): I try to ensure my org files look as
similar as possible regardless of whether they're opened in Emacs or a
plain text editor. Hence, I put the indentation in the actual org file
(and use `auto-fill-mode' to wrap the text)[1]. This makes it easier for
me to send a non-Emacs-using colleague one of my org files while
ensuring it's (somewhat) readable for them.
Finally, as someone who primarily uses Emacs to write software, I find
the current behavior to be more consistent with the other modes I use
most often. In all programming modes I'm familiar with, hitting RET will
create a new line, indented to the appropriate depth. For a
whitespace-dependent language like Python, this is really the *maximum*
depth that would make sense.
However, compared to Org Mode, python-mode has an advantage: if I hit
RET and the indentation isn't what I want (e.g. I was writing an `if'
block and now I'm done with it), I can hit TAB repeatedly to cycle
indentation levels. Org Mode does this when you've typed the "* " for a
heading (or plain list), but not for a blank line. If I'm typing some
text below a heading and hit RET to write some more, I might realize
that I *actually* want a new heading. I could try to type "* ", but as
I'm already indented, Org Mode rightly treats that as a plain list.
Currently, I just hit undo and then try again with C-RET to make a new
heading, but it might be nice to allow cycling indent levels on an
otherwise-empty line.
This reasoning might not apply for users who primarily use Emacs to edit
text documents, as I'm sure the indentation logic there is different
from editing source code. In that case, you could perhaps say that
`org-adapt-indentation' == t is for programmers, and == nil for writers. :)
Ultimately, I'm not sure this will convince anyone who disagrees, and
I'm not even sure my *goal* is to convince people (so long as I'm still
able to configure things the way I like). I just wanted to provide a
perspective from someone on the other side of the fence.
- Jim
[1] This doesn't quite work for links specified like [[url][title]], but
I see that as just a minor hiccup.
Hi Nicolas, Sorry, I did not mean to imply that such things were not possible currently. I was writing in the context of how to specify the current behavior formally. As you point out they absolutely are possible. More replies in line. Best, Tom > This is inaccurate. > > The following is a perfectly valid list. > > --8<---------------cut here---------------start------------->8--- > 1. foo > > #+begin_src emacs-lisp > (+ 1 1) > #+end_src > > 2. bar > --8<---------------cut here---------------end--------------->8--- Yes. My question is about how to deal with cases like --8<---------------cut here---------------start------------->8--- 1. foo #+begin_src emacs-lisp (+ 1 1) #+end_src 2. bar --8<---------------cut here---------------end--------------->8--- > Source blocks for languages that have significant whitespace should use > the -i flag. My known issues with switches aside, the misaligned cases are the ones that I worry about, and I don't think being able to flag a block as being indentation sensitive helps resolve the potential ambiguity there. > What makes you think this is not the case? Sorry, my wording is unclear here. I was not talking about the current implementation which can and does do this, but instead about how to formally specify what should be done in such cases.
Tom Gillespie <tgbugs@gmail.com> writes: > Yes. My question is about how to deal with cases like > > --8<---------------cut here---------------start------------->8--- > 1. foo > > #+begin_src emacs-lisp > (+ 1 1) > #+end_src > > 2. bar > --8<---------------cut here---------------end--------------->8--- > > >> Source blocks for languages that have significant whitespace should use >> the -i flag. > > My known issues with switches aside, the misaligned cases are the ones > that I worry about, and I don't think being able to flag a block as > being indentation sensitive helps resolve the potential ambiguity > there. There are various options: 1. Syntax error. Everything does not have to be valid in an Org document. 2. Opening line always wins (which is the case in Org) Regards,
* Tim Cross <theophilusx@gmail.com> [2021-05-02 11:52]: > > Jean Louis <bugs@gnu.support> writes: > > > * Bastien <bzg@gnu.org> [2021-05-02 09:10]: > >> Various discussions convinced me that `org-adapt-indentation' should > >> be nil by default. > >> > >> With `electric-indent-mode' being activated by default in Emacs, the > >> current behavior is that RET after a headline moves the point below > >> the beginning of this headline, not the beginning of the line, which > >> might surprise users. > >> > >> Indentation is quite sensitive: what do you think of setting a new > >> default value of nil for `org-adapt-indentation' in Org 9.5? > > > > Yes, it should be nil just as it was in beginning. > > > > But there is one problem that I encountered since that was introduced, > > namely I do like properties being indented under the first letter of > > heading or on 3rd place. > > > > Like this below, however, C-c C-x p will create properties indented > > only if org-adapt-indentation is t > > > > * Heading > > :PROPERTIES: > > :ARCHIVE: new > > :END: > > > > But if org-adapt-indentation is nil, it will be like: > > > > * Heading > > :PROPERTIES: > > :ARCHIVE: new > > :END: > > > > and I remember that behavior before the introduced change was that > > properties were intended, which does look nicer for properties. > > > > But I definitely do not prefer cursor to come indentend after writing a header like: > > > > * Heading > > C > > ursor on C > > > > > > Sounds like you want the 'headline-data value for this variable. Please > check the documentation. If I set `org-adapt-indent' to 'headline-data, I get that same behavior that after pressing ENTER on headline line, position becomes indentend. So it does not make it right. My favour was the behaviour how it was before introduction of indentation change: - after headline, cursors went to beginning of line; I find it usable, as that is where I write text. - if I ever wanted to enter properties with C-c C-x p, those were automatically indented, But OK I can personally get used, especially that I these months avoid using any properties in Org mode. "GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.17.4, Xaw3d scroll bars) of 2021-05-02" -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns Sign an open letter in support of Richard M. Stallman https://stallmansupport.org/ https://rms-support-letter.github.io/
* Bastien <bzg@gnu.org> [2021-05-02 11:57]: > Jean Louis <bugs@gnu.support> writes: > > >> Indentation is quite sensitive: what do you think of setting a new > >> default value of nil for `org-adapt-indentation' in Org 9.5? > > > > Yes, it should be nil just as it was in beginning. > > I think `org-adapt-indentation' has always been `t' by default. > > > But there is one problem that I encountered since that was introduced, > > namely I do like properties being indented under the first letter of > > heading or on 3rd place. > > > > Like this below, however, C-c C-x p will create properties indented > > only if org-adapt-indentation is t > > > > * Heading > > :PROPERTIES: > > :ARCHIVE: new > > :END: > > > > But if org-adapt-indentation is nil, it will be like: > > > > * Heading > > :PROPERTIES: > > :ARCHIVE: new > > :END: > > I suggest (setq org-adapt-indentation 'headline-data). That achieves opposite effect, but if nobody else complains, I will not mind it. IMHO, when there shall be option like: (setq org-adapt-indentation 'properties-only) where only properties would be indented. It is not same as what headline-data does. As if text begins on beginning of the line, there is visual distinction together with the colon that properties are there. Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns Sign an open letter in support of Richard M. Stallman https://stallmansupport.org/ https://rms-support-letter.github.io/
* Bastien <bzg@gnu.org> [2021-05-02 11:57]: > Jean Louis <bugs@gnu.support> writes: > > >> Indentation is quite sensitive: what do you think of setting a new > >> default value of nil for `org-adapt-indentation' in Org 9.5? > > > > Yes, it should be nil just as it was in beginning. > > I think `org-adapt-indentation' has always been `t' by default. Maybe, but it did not indent, I was never setting it neither nil or t, I just know that at some Org version it started indenting, which was considered correct. Personally I always follow decisions of developers. We may discuss features, but I am fine with final decisions and will rather adapt myself to it. Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns Sign an open letter in support of Richard M. Stallman https://stallmansupport.org/ https://rms-support-letter.github.io/
* Bastien <bzg@gnu.org> [2021-05-02 11:59]: > Bastien <bzg@gnu.org> writes: > > > I suggest (setq org-adapt-indentation 'headline-data). > > With electric-indent-mode turned off, that is. That is it, thank you. That combination comforts my personal habbits. But that need not stop changes in Org mode of course, unless too many people wish something like this. Personal customization satisfies those habits. Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns Sign an open letter in support of Richard M. Stallman https://stallmansupport.org/ https://rms-support-letter.github.io/
Bastien <bzg@gnu.org> writes: > Indentation is quite sensitive: what do you think of setting a new > default value of nil for `org-adapt-indentation' in Org 9.5? I think that makes sense. If the controversy over the electric-indent-mode change taught me anything, it's that a lot of people don't expect their Org files to be hard-indented, which I fully sympathize with (I personally soft-indent with org-indent-mode). I don't know whether the folks that protested over the change represent the majority of Org users, but FWIW: - That position sounds consistent with the Org files we see in the org-mode repo (where .dir-locals.el sets the variable to nil). - I expect that the resulting behaviour matches what users were used to: before Org 9.4, I imagine most folks would hit RET, get unindented text, and not think twice about it. People who preferred indentation would have had to go out of their way to get it, by always hitting TAB or C-j (which is the "dumb, unindented newline" in other modes which honor electric-indent-mode); I'd be surprised if many people worked this way[1]. 'headline-data sounds like a reasonable default too, although I think it still has some wrinkles[2]. Thanks for following up on this, and thanks again for your stewardship. [1] Although I'm glad to learn that the current state of affairs made at least one user happy 🙂 <s6mr6r$17cg$1@ciao.gmane.io> https://orgmode.org/list/s6mr6r$17cg$1@ciao.gmane.io/t/#u [2] Typing "* headline RET" starts an indented line; further RETs keep point indented until I type in something, after which RET finally snaps back to column 0. I'd expect point to always land on column 0 when hitting RET after a headline, since "headline data" (e.g. :PROPERTIES:, :LOGBOOK:) will probably always be entered automatically via a command.
+1 from me. It is nil in my config, which feels better to me.
Jean Louis <bugs@gnu.support> writes:
> * Tim Cross <theophilusx@gmail.com> [2021-05-02 11:52]:
>>
>> Jean Louis <bugs@gnu.support> writes:
>>
>> > * Bastien <bzg@gnu.org> [2021-05-02 09:10]:
>> >> Various discussions convinced me that `org-adapt-indentation' should
>> >> be nil by default.
>> >>
>> >> With `electric-indent-mode' being activated by default in Emacs, the
>> >> current behavior is that RET after a headline moves the point below
>> >> the beginning of this headline, not the beginning of the line, which
>> >> might surprise users.
>> >>
>> >> Indentation is quite sensitive: what do you think of setting a new
>> >> default value of nil for `org-adapt-indentation' in Org 9.5?
>> >
>> > Yes, it should be nil just as it was in beginning.
>> >
>> > But there is one problem that I encountered since that was introduced,
>> > namely I do like properties being indented under the first letter of
>> > heading or on 3rd place.
>> >
>> > Like this below, however, C-c C-x p will create properties indented
>> > only if org-adapt-indentation is t
>> >
>> > * Heading
>> > :PROPERTIES:
>> > :ARCHIVE: new
>> > :END:
>> >
>> > But if org-adapt-indentation is nil, it will be like:
>> >
>> > * Heading
>> > :PROPERTIES:
>> > :ARCHIVE: new
>> > :END:
>> >
>> > and I remember that behavior before the introduced change was that
>> > properties were intended, which does look nicer for properties.
>> >
>> > But I definitely do not prefer cursor to come indentend after writing a header like:
>> >
>> > * Heading
>> > C
>> > ursor on C
>> >
>> >
>>
>> Sounds like you want the 'headline-data value for this variable. Please
>> check the documentation.
>
> If I set `org-adapt-indent' to 'headline-data, I get that same
> behavior that after pressing ENTER on headline line, position becomes
> indentend. So it does not make it right.
>
> My favour was the behaviour how it was before introduction of
> indentation change:
>
> - after headline, cursors went to beginning of line; I find it
> usable, as that is where I write text.
>
> - if I ever wanted to enter properties with C-c C-x p, those were automatically
> indented,
>
> But OK I can personally get used, especially that I these months avoid
> using any properties in Org mode.
>
>
> "GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.17.4, Xaw3d scroll bars)
> of 2021-05-02"
This is exactly what headline-data does. I suspect what your running
into is electric-indent-mode and you need to turn it off to get the
behaviour you want. So set org-adapt-indentation to hedline-data and
turn off electric-indent-mode and you will get the indentation style you
are after.
The issue here isn't that org-adapt-indentation changed. The issue is
that the effect of this setting changed when org mode was updated to be
consistent with the rest of emacs and honour electric-indent-mode, which
is enabled by default in emacs. Previously, org ignored this wider Emacs
default setting.
The poll is to decide if we should change this long standing default due
to the side effects from enabling electric-indent-mode. Enabling
electric-indent-mode was done to make org mode consistent with other
Emacs modes, so disabling it by default would be inconsistent with Emacs
defaults.
I'm not sure the full impact of enabling electric-indent-mode was
realised at the time. With org, I think the general principal is to try
and have defaults set to the 'least surprising' value, particularly for
new users.
--
Tim Cross
Kévin Le Gouguec <kevin.legouguec@gmail.com> writes: > 'headline-data sounds like a reasonable default too, although I think it > still has some wrinkles[2]. > > [2] Typing "* headline RET" starts an indented line; further RETs keep > point indented until I type in something, after which RET finally > snaps back to column 0. I'd expect point to always land on column 0 > when hitting RET after a headline, since "headline data" > (e.g. :PROPERTIES:, :LOGBOOK:) will probably always be entered > automatically via a command. And as of 3 hours ago, this complaint is now obsolete[1][2] 🎉 A fews more moles to whack, maybe: - RET after an ":END:" starts an indented line, - "* headline RET text TAB" indents "text" (and subsequent RETs are then indented). Sorry for just dumping all these nits at your front door Bastien 😕 I should at least write test cases for them. Will try to find the time Sometime Later™. [1] https://code.orgmode.org/bzg/org-mode/commit/c7331f859d1cc53d5c5f2c6ec58691af15f60b80 [2] https://code.orgmode.org/bzg/org-mode/commit/945c019176b2d23c5006377c95ce8d69b4b4de66
Tim Cross <theophilusx@gmail.com> writes:
> Jean Louis <bugs@gnu.support> writes:
>
>> If I set `org-adapt-indent' to 'headline-data, I get that same
>> behavior that after pressing ENTER on headline line, position becomes
>> indentend. So it does not make it right.
>>
>> My favour was the behaviour how it was before introduction of
>> indentation change:
>>
>> - after headline, cursors went to beginning of line; I find it
>> usable, as that is where I write text.
>>
>> - if I ever wanted to enter properties with C-c C-x p, those were automatically
>> indented,
>
> This is exactly what headline-data does. I suspect what your running
> into is electric-indent-mode and you need to turn it off to get the
> behaviour you want. So set org-adapt-indentation to hedline-data and
> turn off electric-indent-mode and you will get the indentation style you
> are after.
Note that electric-indent-mode means "RET indents according to the major
mode's canonical indentation rules", not "RET always indents".
Org's rules depend on org-adapt-indentation: ideally with
org-adapt-indentation set to 'headline-data, the canonical rules become
"only :DRAWERS: are indented", so RET should *not* indent text; things
should behave as Jean Louis prefers even with electric-indent-mode on.
Bastien has just committed a fix for this earlier today;
cf. <87fsz4gtjs.fsf@gmail.com>.
Hi Kevin, thanks for checking. Kévin Le Gouguec <kevin.legouguec@gmail.com> writes: > A fews more moles to whack, maybe: > > - RET after an ":END:" starts an indented line, > - "* headline RET text TAB" indents "text" (and subsequent RETs are then > indented). Fixed, thanks. > Sorry for just dumping all these nits at your front door Bastien 😕 I > should at least write test cases for them. Will try to find the time > Sometime Later™. This might help: https://orgmode.org/worg/org-faq.html#indentation Thanks! -- Bastien
[-- Attachment #1: Type: text/plain, Size: 1792 bytes --] Amin Bandali <bandali@gnu.org> writes: > Bastien writes: > >> Various discussions convinced me that `org-adapt-indentation' should >> be nil by default. >> >> With `electric-indent-mode' being activated by default in Emacs, the >> current behavior is that RET after a headline moves the point below >> the beginning of this headline, not the beginning of the line, which >> might surprise users. >> >> Indentation is quite sensitive: what do you think of setting a new >> default value of nil for `org-adapt-indentation' in Org 9.5? > > +1 from me as well. I personally quite dislike indenting after headings > with spaces, and instead use (add-hook 'org-mode-hook #'org-indent-mode) > for the visual indentation effect, which I can easily toggle off when > needed. What’s important for me is that hitting enter on a headline does not create indentation for the text. I’ve been removing indentation manually ever since that change, and I cannot just configure it out, because I often open org-files with emacs -Q or on different systems. Therefore this default matters a lot for me. With the current default I would have to change the default in every emacs session on every docker or VM, and I would have to tell every new org-user to start by changing the default just to be able to write conveniently. I made a point of slimming down my Emacs config, because I often sit at a pristine emacs, and it is important for me that org-mode just works. Before electric-indent-mode got enabled, it was one of the huge strengths of org-mode that it just worked for most use-cases while enabling everyone to customize it incrementally. And I vote to get that back. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 1125 bytes --]
* Tim Cross <theophilusx@gmail.com> [2021-05-03 01:39]: > This is exactly what headline-data does. I suspect what your running > into is electric-indent-mode and you need to turn it off to get the > behaviour you want. So set org-adapt-indentation to hedline-data and > turn off electric-indent-mode and you will get the indentation style you > are after. > > The issue here isn't that org-adapt-indentation changed. The issue is > that the effect of this setting changed when org mode was updated to be > consistent with the rest of emacs and honour electric-indent-mode, which > is enabled by default in emacs. Previously, org ignored this wider Emacs > default setting. I got it after Bastien explained it. I am just not sure if right settings should be like this: (add-hook 'org-mode-hook (lambda () (electric-indent-mode 0))) (add-hook 'org-mode-hook (lambda () (setq org-adapt-indentation 'heading-data))) I understand from debate that changed was brought to make it consistent with Emacs and users have already got habits. IMHO change was made rather for the sake of computer program as quite number of people like it different. > I'm not sure the full impact of enabling electric-indent-mode was > realised at the time. With org, I think the general principal is to try > and have defaults set to the 'least surprising' value, particularly for > new users. > -- > Tim Cross That is it. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns Sign an open letter in support of Richard M. Stallman https://stallmansupport.org/ https://rms-support-letter.github.io/
Bastien <bzg@gnu.org> writes: > Kévin Le Gouguec <kevin.legouguec@gmail.com> writes: > >> A fews more moles to whack, maybe: >> >> - RET after an ":END:" starts an indented line, >> - "* headline RET text TAB" indents "text" (and subsequent RETs are then >> indented). > > Fixed, thanks. Great! One last snag that I can see: when inserting properties or clocking in, the :LOGBOOK:, :PROPERTIES: and :END: lines are indented, but the /first/ :property: or CLOCK: line remains at column 0. I've looked briefly at org-indent-line; IIUC, those lines get caught in this condition: (save-excursion (beginning-of-line 1) (skip-chars-backward "\n") (or (org-at-heading-p) (org-at-drawer-p) (org-at-planning-p))) I'm guessing we'd need to throw some (org-at-property-p) and (org-at-clock-log-p) guards *before* skipping backward over "\n", but I haven't thought this through completely yet. >> should at least write test cases for them. Will try to find the time >> Sometime Later™. > > This might help: https://orgmode.org/worg/org-faq.html#indentation Wonderful! That will definitely help, thanks.
[-- Attachment #1: Type: text/plain, Size: 414 bytes --] Hi Kevin, Kévin Le Gouguec <kevin.legouguec@gmail.com> writes: > Great! One last snag that I can see: when inserting properties or > clocking in, the :LOGBOOK:, :PROPERTIES: and :END: lines are indented, > but the /first/ :property: or CLOCK: line remains at column 0. Er. Can you try this (hopefully last) patch and report any problem? Thanks for your patience in testing this! -- Bastien [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: fix-indent.patch --] [-- Type: text/x-diff, Size: 1655 bytes --] diff --git a/lisp/org.el b/lisp/org.el index c0b5ee5ec..c20539a8a 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -18846,17 +18846,6 @@ ELEMENT." (t (goto-char start) (current-indentation)))) - ((and - (eq org-adapt-indentation 'headline-data) - (or (memq type '(planning clock node-property property-drawer drawer)) - ;; When storing a note in a LOGBOOK drawer, - ;; `org-store-log-note' needs to insert a new line before - ;; the newly inserted note, thus the `type' at point will - ;; return `paragraph' instead of the expected `drawer', so - ;; we need to manually detect the drawer. - (eq (org-element-type (car (org-element-lineage element))) 'drawer))) - (org--get-expected-indentation - (org-element-property :parent element) t)) ((memq type '(headline inlinetask nil)) (if (org-match-line "[ \t]*$") (org--get-expected-indentation element t) @@ -19000,11 +18989,12 @@ Also align node properties according to `org-property-format'." (interactive) (unless (or (org-at-heading-p) (and (eq org-adapt-indentation 'headline-data) + (not (org-at-clock-log-p)) (save-excursion (beginning-of-line 1) (skip-chars-backward "\n") (or (org-at-heading-p) - (org-at-drawer-p) + (looking-back ":END:.*") (org-at-planning-p))))) (let* ((element (save-excursion (beginning-of-line) (org-element-at-point))) (type (org-element-type element)))
Bastien <bzg@gnu.org> writes: > Kévin Le Gouguec <kevin.legouguec@gmail.com> writes: > >> Great! One last snag that I can see: when inserting properties or >> clocking in, the :LOGBOOK:, :PROPERTIES: and :END: lines are indented, >> but the /first/ :property: or CLOCK: line remains at column 0. > > Er. Can you try this (hopefully last) patch and report any problem? > > Thanks for your patience in testing this! Well, try as I might, I couldn't get this one to misindent 😃 And a good thing too, I was about to run out of synonyms for wrinkles/nits/snags and the like 😉 If anyone is wondering what these exchanges are all about: with Bastien's latest patch[1], setting org-adapt-indentation to 'headline-data results in the following behaviour, *whether electric-indent-mode is enabled or not*: - "* heading RET" starts an unindented line (point goes to column 0). - The drawers inserted by org-set-property and org-clock-in are indented. So, to bring the discussion back to the poll: - If nil or 'headline-data becomes the default value, RET will no longer indent regular text after a headline (even with electric-indent-mode). - The difference will be whether :DRAWERS: are indented or not. As far as I am concerned, my preference has become: (1) 'headline-data (indented drawers) (2) nil (nothing indented) (3) t (the status quo) although I suppose an argument could be made that 'headline-data might be a bit "young" and as such, should not be used as default value… Let's see what the poll yields 🙂 [1] Uncommited, to apply on branch maint: https://orgmode.org/list/87fsz4ue9e.fsf@bzg.fr/2-fix-indent.patch
Bastien <bzg@gnu.org> writes:
> Various discussions convinced me that `org-adapt-indentation' should
> be nil by default.
It is now, as of commit 0a651b746.
Thank you all very much for your feedback on this.
--
Bastien
Bastien <bzg@gnu.org> writes:
> Bastien <bzg@gnu.org> writes:
>
>> Various discussions convinced me that `org-adapt-indentation' should
>> be nil by default.
>
> It is now, as of commit 0a651b746.
... and I broke some tests. Sorry for that. I will fix this next
week, unless someone does it before me.
--
Bastien
Bastien, thank you for the fixes of electric-indent-mode, there is no feeling that it is necessary to choose between broken and inconvenient configuration options any more. On 03/05/2021 15:06, Bastien wrote: > > This might help: https://orgmode.org/worg/org-faq.html#indentation "What is the best setup for indenting?" I think, the something like the following should be added to the answer. It was not obvious for me at first. Gustavo explained it in https://orgmode.org/list/87blfxv966.fsf@gmail.com/ Do not try to avoid or ignore indentation of heading body or properties drawer determined by current org-adapt-indentation and electric-indent-mode by pressing C-j instead of RET (or vice versa). It is unsure way. When you refile heading or change its level (promote or demote it), you may find that despite your efforts, elements are indented accordingly to Org mode current settings instead of your visual preferences. It is better to customize org-adapt-indentation. I would suggest to mention =#+STARTUP: indent= as well as a visual alternative to (org-adapt-indentation t) that actually cancels its effect. Maybe it should be stressed in the ORG-NEWS file that previously there were suggestion to set electric-indent-local-mode to -1 for Org buffers. Now it is hopefully not necessary due to bug fixes and changed defaults. Finally, a case that might be fixed. - item 1 + item 2 +← cursor is here In this case TAB allows to cycle through indentation variants and it is great. Unfortunately just after RET (there are only some spaces on the new line) TAB fixes indentation as continuation of previous item and does not allow to shift left before marker is added. It is confusing at first since e.g. python mode is more liberal. Is there equivalent of TAB for indentation cycle when some item text is added since TAB is busy for switching of item visibility?
[-- Attachment #1: Type: text/plain, Size: 676 bytes --] Bastien <bzg@gnu.org> writes: >> It is now, as of commit 0a651b746. > > ... and I broke some tests. Sorry for that. I will fix this next > week, unless someone does it before me. Here are two patches that set org-adapt-indentation to t for the tests which were implicitly relying on that behavior; that lets 'make test' succeed again for me. I'm pretty sure the first one is TRT (since I'm the author of the tests), although Eventually™ we should make a more exhaustive suite based on the table you referenced earlier. The second one makes the remaining tests pass again, but I couldn't tell at a glance whether their expectations still make sense. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Set-org-adapt-indentation-explicitly-in-some-tests.patch --] [-- Type: text/x-patch, Size: 3006 bytes --] From e136f0d3123173d947bf4c1ce06aaf5f12117ef8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?K=C3=A9vin=20Le=20Gouguec?= <kevin.legouguec@gmail.com> Date: Sun, 9 May 2021 18:05:35 +0200 Subject: [PATCH 1/2] Set org-adapt-indentation explicitly in some tests * testing/lisp/test-org.el (test-org/with-electric-indent, test-org/without-electric-indent): Make sure org-adapt-indentation is consistent with expected results. --- testing/lisp/test-org.el | 42 +++++++++++++++++++++++----------------- 1 file changed, 24 insertions(+), 18 deletions(-) diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el index 9f0ede1b9..5ac9173ac 100644 --- a/testing/lisp/test-org.el +++ b/testing/lisp/test-org.el @@ -1404,12 +1404,14 @@ (electric-indent-local-mode 1) (call-interactively 'org-return) (buffer-string)))) - (should - (equal "* heading\n body" - (org-test-with-temp-text "* heading<point>body" - (electric-indent-local-mode 1) - (call-interactively 'org-return) - (buffer-string)))) + ;; TODO: test more values of `org-adapt-indentation'. + (let ((org-adapt-indentation t)) + (should + (equal "* heading\n body" + (org-test-with-temp-text "* heading<point>body" + (electric-indent-local-mode 1) + (call-interactively 'org-return) + (buffer-string))))) ;; C-j, like `electric-newline-and-maybe-indent', should not indent. (should (equal " Para\ngraph" @@ -1423,12 +1425,14 @@ (electric-indent-local-mode 1) (call-interactively 'org-return-and-maybe-indent) (buffer-string)))) - (should - (equal "* heading\nbody" - (org-test-with-temp-text "* heading<point>body" - (electric-indent-local-mode 1) - (call-interactively 'org-return-and-maybe-indent) - (buffer-string))))) + ;; TODO: test more values of `org-adapt-indentation'. + (let ((org-adapt-indentation t)) + (should + (equal "* heading\nbody" + (org-test-with-temp-text "* heading<point>body" + (electric-indent-local-mode 1) + (call-interactively 'org-return-and-maybe-indent) + (buffer-string)))))) (ert-deftest test-org/without-electric-indent () "Test RET and C-j specifications with `electric-indent-mode' off." @@ -1467,12 +1471,14 @@ (electric-indent-local-mode 0) (call-interactively 'org-return-and-maybe-indent) (buffer-string)))) - (should - (equal "* heading\n body" - (org-test-with-temp-text "* heading<point>body" - (electric-indent-local-mode 0) - (call-interactively 'org-return-and-maybe-indent) - (buffer-string))))) + ;; TODO: test more values of `org-adapt-indentation'. + (let ((org-adapt-indentation t)) + (should + (equal "* heading\n body" + (org-test-with-temp-text "* heading<point>body" + (electric-indent-local-mode 0) + (call-interactively 'org-return-and-maybe-indent) + (buffer-string)))))) (ert-deftest test-org/meta-return () "Test M-RET (`org-meta-return') specifications." -- 2.31.1 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #3: 0002-Set-org-adapt-indentation-explicitly-in-some-tests.patch --] [-- Type: text/x-patch, Size: 7038 bytes --] From 2a485754a7f04d00ef5e5ebed82924d44f768424 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?K=C3=A9vin=20Le=20Gouguec?= <kevin.legouguec@gmail.com> Date: Sun, 9 May 2021 18:20:11 +0200 Subject: [PATCH 2/2] Set org-adapt-indentation explicitly in some tests * testing/lisp/test-org.el (test-org/indent-line, test-org/indent-region): Make sure org-adapt-indentation is consistent with expected results. --- testing/lisp/test-org.el | 126 ++++++++++++++++++++------------------- 1 file changed, 66 insertions(+), 60 deletions(-) diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el index 5ac9173ac..95ffb0a80 100644 --- a/testing/lisp/test-org.el +++ b/testing/lisp/test-org.el @@ -1007,22 +1007,23 @@ ;; At the first line of an element, indent like previous element's ;; first line, ignoring footnotes definitions and inline tasks, or ;; according to parent. - (should - (= 2 - (org-test-with-temp-text "A\n\n B\n\nC<point>" - (org-indent-line) - (org-get-indentation)))) - (should - (= 1 - (org-test-with-temp-text " A\n\n[fn:1] B\n\n\nC<point>" - (org-indent-line) - (org-get-indentation)))) - (should - (= 1 - (org-test-with-temp-text - " #+BEGIN_CENTER\n<point> Contents\n#+END_CENTER" - (org-indent-line) - (org-get-indentation)))) + (let ((org-adapt-indentation t)) + (should + (= 2 + (org-test-with-temp-text "A\n\n B\n\nC<point>" + (org-indent-line) + (org-get-indentation)))) + (should + (= 1 + (org-test-with-temp-text " A\n\n[fn:1] B\n\n\nC<point>" + (org-indent-line) + (org-get-indentation)))) + (should + (= 1 + (org-test-with-temp-text + " #+BEGIN_CENTER\n<point> Contents\n#+END_CENTER" + (org-indent-line) + (org-get-indentation))))) ;; Within code part of a source block, use language major mode if ;; `org-src-tab-acts-natively' is non-nil. Otherwise, indent ;; according to line above. @@ -1066,11 +1067,12 @@ (ert-deftest test-org/indent-region () "Test `org-indent-region' specifications." ;; Indent paragraph. - (should - (equal "A\nB\nC" - (org-test-with-temp-text " A\nB\n C" - (org-indent-region (point-min) (point-max)) - (buffer-string)))) + (let ((org-adapt-indentation t)) + (should + (equal "A\nB\nC" + (org-test-with-temp-text " A\nB\n C" + (org-indent-region (point-min) (point-max)) + (buffer-string))))) ;; Indent greater elements along with their contents. (should (equal "#+BEGIN_CENTER\nA\nB\n#+END_CENTER" @@ -1083,11 +1085,12 @@ (org-test-with-temp-text "#+BEGIN_VERSE\n A\n B\n#+END_VERSE" (org-indent-region (point-min) (point-max)) (buffer-string)))) - (should - (equal "#+BEGIN_VERSE\n A\n B\n#+END_VERSE" - (org-test-with-temp-text " #+BEGIN_VERSE\n A\n B\n #+END_VERSE" - (org-indent-region (point-min) (point-max)) - (buffer-string)))) + (let ((org-adapt-indentation t)) + (should + (equal "#+BEGIN_VERSE\n A\n B\n#+END_VERSE" + (org-test-with-temp-text " #+BEGIN_VERSE\n A\n B\n #+END_VERSE" + (org-indent-region (point-min) (point-max)) + (buffer-string))))) ;; Indent example blocks as a single block, unless indentation ;; should be preserved. In this case only indent the block markers. (should @@ -1095,36 +1098,38 @@ (org-test-with-temp-text "#+BEGIN_EXAMPLE\n A\n B\n#+END_EXAMPLE" (org-indent-region (point-min) (point-max)) (buffer-string)))) - (should - (equal "#+BEGIN_EXAMPLE\n A\n B\n#+END_EXAMPLE" - (org-test-with-temp-text " #+BEGIN_EXAMPLE\n A\n B\n #+END_EXAMPLE" - (org-indent-region (point-min) (point-max)) - (buffer-string)))) - (should - (equal "#+BEGIN_EXAMPLE -i\n A\n B\n#+END_EXAMPLE" - (org-test-with-temp-text - " #+BEGIN_EXAMPLE -i\n A\n B\n #+END_EXAMPLE" - (org-indent-region (point-min) (point-max)) - (buffer-string)))) - (should - (equal "#+BEGIN_EXAMPLE\n A\n B\n#+END_EXAMPLE" - (org-test-with-temp-text - " #+BEGIN_EXAMPLE\n A\n B\n #+END_EXAMPLE" - (let ((org-src-preserve-indentation t)) - (org-indent-region (point-min) (point-max))) - (buffer-string)))) + (let ((org-adapt-indentation t)) + (should + (equal "#+BEGIN_EXAMPLE\n A\n B\n#+END_EXAMPLE" + (org-test-with-temp-text " #+BEGIN_EXAMPLE\n A\n B\n #+END_EXAMPLE" + (org-indent-region (point-min) (point-max)) + (buffer-string)))) + (should + (equal "#+BEGIN_EXAMPLE -i\n A\n B\n#+END_EXAMPLE" + (org-test-with-temp-text + " #+BEGIN_EXAMPLE -i\n A\n B\n #+END_EXAMPLE" + (org-indent-region (point-min) (point-max)) + (buffer-string)))) + (should + (equal "#+BEGIN_EXAMPLE\n A\n B\n#+END_EXAMPLE" + (org-test-with-temp-text + " #+BEGIN_EXAMPLE\n A\n B\n #+END_EXAMPLE" + (let ((org-src-preserve-indentation t)) + (org-indent-region (point-min) (point-max))) + (buffer-string))))) ;; Treat export blocks as a whole. (should (equal "#+BEGIN_EXPORT latex\n A\n B\n#+END_EXPORT" (org-test-with-temp-text "#+BEGIN_EXPORT latex\n A\n B\n#+END_EXPORT" (org-indent-region (point-min) (point-max)) (buffer-string)))) - (should - (equal "#+BEGIN_EXPORT latex\n A\n B\n#+END_EXPORT" - (org-test-with-temp-text - " #+BEGIN_EXPORT latex\n A\n B\n #+END_EXPORT" - (org-indent-region (point-min) (point-max)) - (buffer-string)))) + (let ((org-adapt-indentation t)) + (should + (equal "#+BEGIN_EXPORT latex\n A\n B\n#+END_EXPORT" + (org-test-with-temp-text + " #+BEGIN_EXPORT latex\n A\n B\n #+END_EXPORT" + (org-indent-region (point-min) (point-max)) + (buffer-string))))) ;; Indent according to mode if `org-src-tab-acts-natively' is ;; non-nil. Otherwise, do not indent code at all. (should @@ -1160,16 +1165,17 @@ (org-indent-region (point) (point-max))) (buffer-string)))) ;; Indent plain lists. - (should - (equal "- A\n B\n - C\n\n D" - (org-test-with-temp-text "- A\n B\n - C\n\n D" - (org-indent-region (point-min) (point-max)) - (buffer-string)))) - (should - (equal "- A\n\n- B" - (org-test-with-temp-text " - A\n\n - B" - (org-indent-region (point-min) (point-max)) - (buffer-string)))) + (let ((org-adapt-indentation t)) + (should + (equal "- A\n B\n - C\n\n D" + (org-test-with-temp-text "- A\n B\n - C\n\n D" + (org-indent-region (point-min) (point-max)) + (buffer-string)))) + (should + (equal "- A\n\n- B" + (org-test-with-temp-text " - A\n\n - B" + (org-indent-region (point-min) (point-max)) + (buffer-string))))) ;; Indent footnote definitions. (should (equal "[fn:1] Definition\n\nDefinition" -- 2.31.1
Hi Kévin,
Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
> Here are two patches that set org-adapt-indentation to t for the tests
> which were implicitly relying on that behavior; that lets 'make test'
> succeed again for me.
Thanks a lot for your help on this! Applied.
--
Bastien
Hi Maxim,
Maxim Nikulin <manikulin@gmail.com> writes:
> I think, the something like the following should be added to the
> answer.
Patch welcome! Either for Worg or etc/ORG-NEWS, if you think we
should add something to the existing explanations.
Thanks,
--
Bastien
--- etc/ORG-NEWS | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index f49d2c043..8707222e0 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -55,8 +55,11 @@ If you want to automatically indent headlines' metadata, set it to If you want to automatically indent every line to the headline's current indentation, set it to =t=. -Also beware that the behavior of =RET= and =C-j= also depends on the -value of ~electric-indent-mode~. See [[https://orgmode.org/worg/org-faq.html#indentation][this FAQ]] for more details. +Indent added by =RET= and =C-j= also depends on the value of +~electric-indent-mode~. Enabling this mode by default in 9.4 revealed +some bugs caused confusing behavior. If you disabled +~electric-indent-mode~ for this reason, it is time to try it again. +Hopefully problems have been fixed. See [[https://orgmode.org/worg/org-faq.html#indentation][this FAQ]] for more details. *** ~org-speed-commands-user~ is obsolete, use ~org-speed-commands~ -- 2.25.1
--- org-faq.org | 61 ++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 44 insertions(+), 17 deletions(-) diff --git a/org-faq.org b/org-faq.org index 9cc193c4..0f8934af 100644 --- a/org-faq.org +++ b/org-faq.org @@ -1029,21 +1029,33 @@ something like this: :CUSTOM_ID: indentation :END: -Indentation is a matter of personal preferences. General indentation -preferences are controlled in Emacs via ~electric-indent-mode~. Org -indentation behavior changes depending on ~org-adapt-indentation~, which -accepts three values: =nil= (no special indentation), =t= (always indent -relatively the the element above) and =headline-data= (only indent the -~PROPERTIES/LOGBOOK~ drawers relatively to the current level). On top -of these two configuration areas, there the difference between =RET= and -=C-j=. - -Here are two tables summarizing the behavior depending on whether -~electric-indent-mode~ is enable (the default) or not: - -With `electric-indent-mode' enabled: - -| org-adapt-indentation => | nil | t | headline-data | +Indentation, both appearance and behavior, is a matter of personal +preferences. You may try if the following adjustments suits better +for you than the defaults. Set ~org-adapt-indentation~ to have +content aligned to headline titles. Disable ~electric-indent-mode~ to +avoid automatic indentation in response to =RET= key. + +In more details, ~org-adapt-indentation~ controls indentation with +regards to previous element. Apparent effect is increased indentation +for content of deeper nested headings. The variable accepts three +values: =nil= (no special indentation), =t= (always indent relatively +the the element above) and =headline-data= (only indent the +~PROPERTIES/LOGBOOK~ drawers relatively to the current level). Value +=t= is suitable for short entries especially if you plan to share your +documents with someone who does not use Emacs. If you just want to +make heading level more prominent then consider adding visual left +margin using =#+STARTUP: indent= as described in the [[https://orgmode.org/manual/Clean-View.html#Clean-View][Clean View]] +section of the manual. The option works without adding extra spaces +to the document text. + +Configured indentation may be applied in response to =RET= or to +=C-j= depending on the state of ~electric-indent-mode~. The following +tables summarizes the difference. Version number is added to column +header if it describes default settings. + +With ~electric-indent-mode~ enabled: + +| org-adapt-indentation => | nil (Org >= 9.5) | t (Org 9.4) | headline-data | |---------------------------+------------------------+----------------------------+----------------------------| | RET after a headline | Do not indent | Indent | Do not indent | | C-j after a headline | Do not indent | Do not indent | Do not indent | @@ -1051,9 +1063,9 @@ With `electric-indent-mode' enabled: | C-j anywhere | Do not indent wrt prev | Do not indent wrt previous | Do not indent wrt previous | | Insert PROPERTIES/LOGBOOK | Do not indent | Indent wrt headline | Indent wrt headline | -With `electric-indent-mode' disabled: +With ~electric-indent-mode~ disabled: -| org-adapt-indentation => | nil | t | headline-data | +| org-adapt-indentation => | nil | t | headline-data (Org < 9.4) | |---------------------------+---------------------+----------------------------+----------------------------| | RET after a headline | Do not indent | Do not indent | Do not indent | | C-j after a headline | Do not indent | Indent | Do not indent | @@ -1061,6 +1073,21 @@ With `electric-indent-mode' disabled: | C-j | Indent wrt previous | Indent wrt previous | Indent wrt previous | | Insert PROPERTIES/LOGBOOK | Do not indent | Indent wrt headline | Indent wrt headline | +Do not try to avoid or to ignore indentation of heading body or +properties drawer determined by current state of +~org-adapt-indentation~ and ~electric-indent-mode~ by pressing =C-j= +instead of =RET= (or vice versa). The result is transient and you will +lost formatting when you refile heading or change its level (promote +or demote it). + +You may have noticed recommendation to disable ~electric-indent-mode~ +to restore behavior prior to Org 9.4. In Org 9.5 +~org-adapt-indentation~ default value changed to =nil= and, that is +more important, a number of bugs related to indentation were fixed. +Using =RET= with enabled ~electric-indent-mode~ should be convenient +now. Just customize ~org-adapt-indentation~ variable accordingly to +you preferences. + ** Can I migrate from Planner? Yes. This [[http://www.c0t0d0s0.de/plan2org/plan2org.pl][perl script]] or [[http://gitorious.org/bkuhn-small-hacks/org-mode/blobs/master/planner2org.plx -- 2.25.1
On 16/05/2021 03:51, Bastien wrote:
> Maxim Nikulin writes:
>
>> I think, the something like the following should be added to the
>> answer.
>
> Patch welcome! Either for Worg or etc/ORG-NEWS, if you think we
> should add something to the existing explanations.
I have tried to express my ideas as patches. Feel free to pick
only a part of changes or discard them at all.
Maxim, patches to patches... :) i think these are really just typos, rather than any useful substantial comment. - s/is enable (the default) or not:/is enabled (the default) or not:/ - i would suggest separate tables for >= 9.5 and < 9.5. just so the differences between with/without =electric-indent-mode= are easier to spot. - s/C-j anywhere/C-j elsewhere/ (and, iiuc, maybe also the "unadorned" [C-j] table entry should probably be [C-j elsewhere]?) - s/lost formatting/lose formatting/ - s/and, that is/and,/ - s/always indent relatively/always indent relative/ - s/the the element/to the element/ cheers, Greg
Hi Maxim, applied as 507cf71de in master, thanks! For your next patch to be perfect, please include a commit message: https://orgmode.org/worg/org-contribute.html#commit-messages -- Bastien
Hi Maxim, applied in Worg, thanks! -- Bastien
[-- Attachment #1: Type: text/plain, Size: 2146 bytes --] Thank you for your comments, Greg. On 20/05/2021 01:06, Greg Minshall wrote: > > patches to patches... :) i think these are really just typos, rather > than any useful substantial comment. > > - s/is enable (the default) or not:/is enabled (the default) or not:/ The patch removed this phrase. > - i would suggest separate tables for >= 9.5 and < 9.5. just so the > differences between with/without =electric-indent-mode= are easier to > spot. I have no idea how to express it in a better way. The tables are same for Org >= 9.5 and for Org < 9.5 (modulo bugs in indentation fixed in 9.4.6). Only default configuration evolves in time. 1. Before 9.4. (org-adapt-indentation t) electric-indent-mode disabled. Bugs remained unnoticed. Users were unaware that default configuration assumed indented text aligned to headline title. 2. 9.4. (org-adapt-indentation t) electric-indent-mode enabled. Hot discussions and recommendations to disable electric-indent-mode since even with (org-adapt-indentation headline-data) behavior was strange. 3. Recent changes. Bugs fixed, (org-adapt-indentation nil), so as earlier text is not indented by default. Now absence of indentation is consistent with settings. > - s/C-j anywhere/C-j elsewhere/ (and, iiuc, maybe also the "unadorned" > [C-j] table entry should probably be [C-j elsewhere]?) > > - s/lost formatting/lose formatting/ > > - s/and, that is/and,/ Agree. > - s/always indent relatively/always indent relative/ Not being a native speaker, I would either leave it as is or would change all 3 phrases attempting to make their style more uniform. a. "do not indent anything", "always indent relatively to the element above", "indent just ~PROPERTIES/LOGBOOK~ drawers relatively to the current heading level" b. "no special indentation", "indentation of all elements is relative to the element above", "only ~PROPERTIES/LOGBOOK~ drawers get indentation relative to the current heading level" If you think that your variant is better, I can add it to the patch. > - s/the the element/to the element/ Agree. Intermediate patch is attached. [-- Attachment #2: 0001-org-faq.org-Fix-typos-and-style-in-setup-for-indenti.patch --] [-- Type: text/x-patch, Size: 4096 bytes --] From 1881aacf22fda650408434394a96f3aaea2c6928 Mon Sep 17 00:00:00 2001 From: Max Nikulin <manikulin@gmail.com> Date: Thu, 20 May 2021 22:48:58 +0700 Subject: [PATCH] org-faq.org: Fix typos and style in "setup for indenting" * org-faq.org (What is the best setup for indenting?): Minor corrections suggested by Greg Minshall. --- org-faq.org | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/org-faq.org b/org-faq.org index 0f8934af..54d5e403 100644 --- a/org-faq.org +++ b/org-faq.org @@ -1039,7 +1039,7 @@ In more details, ~org-adapt-indentation~ controls indentation with regards to previous element. Apparent effect is increased indentation for content of deeper nested headings. The variable accepts three values: =nil= (no special indentation), =t= (always indent relatively -the the element above) and =headline-data= (only indent the +to the element above) and =headline-data= (only indent the ~PROPERTIES/LOGBOOK~ drawers relatively to the current level). Value =t= is suitable for short entries especially if you plan to share your documents with someone who does not use Emacs. If you just want to @@ -1059,8 +1059,8 @@ With ~electric-indent-mode~ enabled: |---------------------------+------------------------+----------------------------+----------------------------| | RET after a headline | Do not indent | Indent | Do not indent | | C-j after a headline | Do not indent | Do not indent | Do not indent | -| RET anywhere | Indent wrt previous | Indent wrt previous | Indent wrt previous | -| C-j anywhere | Do not indent wrt prev | Do not indent wrt previous | Do not indent wrt previous | +| RET elsewhere | Indent wrt previous | Indent wrt previous | Indent wrt previous | +| C-j elsewhere | Do not indent wrt prev | Do not indent wrt previous | Do not indent wrt previous | | Insert PROPERTIES/LOGBOOK | Do not indent | Indent wrt headline | Indent wrt headline | With ~electric-indent-mode~ disabled: @@ -1069,21 +1069,21 @@ With ~electric-indent-mode~ disabled: |---------------------------+---------------------+----------------------------+----------------------------| | RET after a headline | Do not indent | Do not indent | Do not indent | | C-j after a headline | Do not indent | Indent | Do not indent | -| RET | Do not indent | Do not indent wrt previous | Do not indent wrt previous | -| C-j | Indent wrt previous | Indent wrt previous | Indent wrt previous | +| RET elsewhere | Do not indent | Do not indent wrt previous | Do not indent wrt previous | +| C-j elsewhere | Indent wrt previous | Indent wrt previous | Indent wrt previous | | Insert PROPERTIES/LOGBOOK | Do not indent | Indent wrt headline | Indent wrt headline | Do not try to avoid or to ignore indentation of heading body or properties drawer determined by current state of ~org-adapt-indentation~ and ~electric-indent-mode~ by pressing =C-j= instead of =RET= (or vice versa). The result is transient and you will -lost formatting when you refile heading or change its level (promote +lose formatting when you refile heading or change its level (promote or demote it). You may have noticed recommendation to disable ~electric-indent-mode~ to restore behavior prior to Org 9.4. In Org 9.5 -~org-adapt-indentation~ default value changed to =nil= and, that is -more important, a number of bugs related to indentation were fixed. +~org-adapt-indentation~ default value changed to =nil= and, more +importantly, a number of bugs related to indentation were fixed. Using =RET= with enabled ~electric-indent-mode~ should be convenient now. Just customize ~org-adapt-indentation~ variable accordingly to you preferences. -- 2.25.1
Maxim, > The patch removed this phrase. sorry about that. > I have no idea how to express it in a better way. The tables are same > for Org >= 9.5 and for Org < 9.5 (modulo bugs in indentation fixed in > 9.4.6). Only default configuration evolves in time. again, i apologize. my confusion was in not having read the text to understand that the "(Org >= 9.5)" was the default. i assumed it meant, "this is the behavior for Org >= 9.5", even though that meant the tables really didn't make sense. if you wanted to compensate for such a "user feature" :), maybe remove "(Org >= 9.5)", and add that information as a short "NB:" line after each table? > Not being a native speaker, I would either leave it as is or would change > all 3 phrases attempting to make their style more uniform. > > a. "do not indent anything", > "always indent relatively to the element above", > "indent just ~PROPERTIES/LOGBOOK~ drawers relatively > to the current heading level" > > b. "no special indentation", > "indentation of all elements is relative to the element above", > "only ~PROPERTIES/LOGBOOK~ drawers get indentation relative > to the current heading level" > sorry, i should have caught *both* "relatively". i'd suggest > a. "do not indent anything", > "always indent relative to the element above", > "indent just ~PROPERTIES/LOGBOOK~ drawers relative > to the current heading level" which klings better to my ears. (sadly, i can't explain any grammatical reason why, though.) cheers, Greg
Hi Maxim,
Maxim Nikulin <manikulin@gmail.com> writes:
> Intermediate patch is attached.
Applied to worg, thanks!
--
Bastien
Hi Greg, Bastien merged that patch just before I was going to modify it in response to your suggestions. I think, 3 commits is too much noise in git history for the single item in FAQ. However I can to prepare one more correction. Maybe you have got a better idea how to avoid confusion with Org versions in the tables. On 21/05/2021 09:45, Greg Minshall wrote: > >> I have no idea how to express it in a better way. The tables are same >> for Org >= 9.5 and for Org < 9.5 (modulo bugs in indentation fixed in >> 9.4.6). Only default configuration evolves in time. > > again, i apologize. my confusion was in not having read the text to > understand that the "(Org >= 9.5)" was the default. i assumed it meant, > "this is the behavior for Org >= 9.5", even though that meant the tables > really didn't make sense. if you wanted to compensate for such a "user > feature" :), maybe remove "(Org >= 9.5)", and add that information as a > short "NB:" line after each table? ... > sorry, i should have caught *both* "relatively". i'd suggest > >> a. "do not indent anything", >> "always indent relative to the element above", >> "indent just ~PROPERTIES/LOGBOOK~ drawers relative >> to the current heading level" > > which klings better to my ears. (sadly, i can't explain any grammatical > reason why, though.)