[POLL] Setting `org-adapt-indentation' to nil by default?

[POLL] Setting `org-adapt-indentation' to nil by default?

[Bastien]

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

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Tim Cross]

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

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Jean Louis]

* 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/

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Tim Cross]

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.

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Bastien]

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

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Bastien]

Bastien <bzg@gnu.org> writes:

> I suggest (setq org-adapt-indentation 'headline-data).

With electric-indent-mode turned off, that is.

-- 
 Bastien

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Eric S Fraga]

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

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Detlef Steuer]

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

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Colin Baxter]

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

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Amin Bandali]

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.

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Tom Gillespie]

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.

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Nicolas Goaziou]

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

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Jim Porter]

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.

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Tom Gillespie]

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.

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Nicolas Goaziou]

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,

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Jean Louis]

* 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/

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Jean Louis]

* 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/

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Jean Louis]

* 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/

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Jean Louis]

* 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/

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Kévin Le Gouguec]

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.

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Jack Kamm]

+1 from me. It is nil in my config, which feels better to me.

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Tim Cross]

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

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Kévin Le Gouguec]

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

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Kévin Le Gouguec]

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

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Bastien]

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

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Dr. Arne Babenhauserheide]

[-- 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 --]

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Jean Louis]

* 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/

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Kévin Le Gouguec]

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.

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Bastien]

[-- 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)))

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Kévin Le Gouguec]

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

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Bastien]

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

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[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

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Maxim Nikulin]

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?

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Kévin Le Gouguec]

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

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Bastien]

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

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[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

[PATCH] etc/ORG-NEWS: Suggest against disabling `electric-indent-mode'

[Maxim Nikulin]

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

[PATCH] org-faq.org: Expand "What is the best setup for indenting?"

[Maxim Nikulin]

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

Re: [POLL] Setting `org-adapt-indentation' to nil by default?

[Maxim Nikulin]

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.

Re: [PATCH] org-faq.org: Expand "What is the best setup for indenting?"

[Greg Minshall]

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

Re: [PATCH] etc/ORG-NEWS: Suggest against disabling `electric-indent-mode'

[Bastien]

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

Re: [PATCH] org-faq.org: Expand "What is the best setup for indenting?"

[Bastien]

Hi Maxim,

applied in Worg, thanks!

-- 
 Bastien

Re: [PATCH] org-faq.org: Expand "What is the best setup for indenting?"

[Maxim Nikulin]

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

Re: [PATCH] org-faq.org: Expand "What is the best setup for indenting?"

[Greg Minshall]

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

Re: [PATCH] org-faq.org: Expand "What is the best setup for indenting?"

[Bastien]

Hi Maxim,

Maxim Nikulin <manikulin@gmail.com> writes:

> Intermediate patch is attached.

Applied to worg, thanks!

-- 
 Bastien

Re: [PATCH] org-faq.org: Expand "What is the best setup for indenting?"

[Maxim Nikulin]

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