emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Gustavo Barros <gusbrs.2016@gmail.com>
To: Tim Cross <theophilusx@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Changed list indentation behavior: how to revert?
Date: Mon, 16 Nov 2020 08:21:53 -0300	[thread overview]
Message-ID: <87blfxv966.fsf@gmail.com> (raw)
In-Reply-To: <871rgtbwml.fsf@gmail.com> (Tim Cross's message of "Mon, 16 Nov 2020 18:15:30 +1100")

Hi Tim,
Hi All,

On Mon, 16 Nov 2020 at 18:15, Tim Cross <theophilusx@gmail.com> wrote:

> Tim Cross <theophilusx@gmail.com> writes:
>> Thanks for clarifying this Kyle.
>> So essentially, this change has been made to make org-mode consistent
>> with the rest of emacs which enabled electric-indent by default in Emacs
>> 24. this is a good thing. Org should be consistent with other modes. Any
>> differences are likely to be the source of confusion and bug reports.
>> I am a little confused about the purpose of org-adapt-indentation
>> though. According to the org news file, to get back the old behaviour,
>> it says to explicity disable electric-indent mode using org-mode-hook.
>> There is no mention of org-adapt-indentation.
>> Is this just an artefact from before and in effect, we have two methods
>> to disable the indentation behaviour? Is there anything functionally
>> different between disabling electric-indent by calling
>> electric-indent-local-mode -1 or setting org-adapt-indent to nil or is
>> the result functionally equivalent?
> Following up to my own question. The two are NOT functionally equivalent
> in that org-adapt-indentation supports other values than t or nil. You
> can use this variable to tweak how the adaptive indentation works. While
> setting it to nil may be equivalent to turning of electric-indent mode,
> it can be used to adjust how adaptive indentation works as well.
> Tim
> --
> Tim Cross

I think I might chime in again, as perhaps I have a point to add, and
Tim's formulation here is a good hook for that.  Setting
`org-adapt-indentation' to nil is not equivalent to disabling
`electric-indent-mode' not because there are more values than t or nil
for the first, but because they are conceptually different.
`org-adapt-indentation' controls how the indentation should be done by
Org, `electric-indent-mode' just applies this setting when you hit RET.
If you have `electric-indent-mode' off, but `org-adapt-indentation' set
to t, type a heading hit RET, than TAB, you will get the same
indentation up to the heading stars level.

But the point of interest here, is not this difference by itself, but in
some of its implications, and why so many people were unaware of
`org-adapt-indentation'.  I think this is the case because, with
`electric-indent-mode' off, it is easy to slip through the right
indentation, and get to believe things are working as expected, when
they are actually just doing so by coincidence.

Suppose you are in the status quo before 9.4, that is
`org-adapt-indentation' set to its default value of true, and
`electric-indent-mode' off, and you start to type a little document.

If you type it always hitting TAB after RET, you will get:

#+begin_src org
,** Foo
   First line
   Second line

(Indentation appears off, but that's just the escape comma).

If, instead, you just type RET, you get what many people surprised by
the change in this thread expect:

#+begin_src org
,** Foo
First line
Second line

Now, the point is that, if you just miss the TAB on the first line, even
if you hit TAB to indent on the subsequent ones, they will still not
indent and be kept on the left margin.  So things *appear* to be working
as expected, but they are not.  What is happening here is that *because
indentation is broken in the first line* it goes amiss in the following

One might argue that, if it appears to work on all accounts, it is
actually working.  But if you have this situation, you will then be
subject to all sorts of strange things.

Suppose we are in the situation of the last block, and demote the

#+begin_src org
,*** Foo
 First line
 Second line

Surprise! the content of the heading was moved to the right by one space
which is neither indented as it should, nor at the left margin as

Now you try to "fix" this "incorrect" dragging of the content, by
selecting the subtree and calling `org-indent-region'.

#+begin_src org
,*** Foo
    First line
    Second line

Surprise! it's even "worse".  So you then undo twice, and type the star
directly to "correct" it (how else?).

Try to expand an org-tempo template and get surprised that you can't get
a non-indented expansion right after the heading, but you can do it
after some content (from a real case at

I haven't tried further, but I wouldn't be surprised if similar
"strange" behaviors would also affect killing-yanking subtrees,
refiling, etc.

So, keeping `org-adapt-indentation' to t, but "solving" the
inconvenience by disabling `electric-indent-mode' is not a solution,
because this will just hide (keep hiding?) from you the fact that you
are editing a document which is different from what Org is actually
expecting according to the indentation settings, and this will result in
inconsistencies of behavior at a number of points.

We should probably thank `electric-indent-mode' for making people more
aware of this user option, and correct this setting to their actual use,
regardless of whether they choose to use `electric-indent-mode' at Org.
Bitter medicine?  Perhaps.  But it's good.

Best regards,

  reply	other threads:[~2020-11-16 11:22 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-13 17:30 Changed list indentation behavior: how to revert? Karl Voit
2020-11-13 21:10 ` Gustavo Barros
2020-11-13 21:38   ` Jean Louis
2020-11-14  3:02     ` Greg Minshall
2020-11-13 21:47   ` Jean Louis
2020-11-13 22:13     ` Gustavo Barros
2020-11-13 22:21       ` Jean Louis
2020-11-14 17:28         ` Diego Zamboni
2020-11-14 19:10           ` Jean Louis
2020-11-15 12:44             ` Kévin Le Gouguec
2020-11-15 13:26               ` Jean Louis
2020-11-15 21:59                 ` Kévin Le Gouguec
2020-11-15 22:15                   ` Jean Louis
2020-11-16  7:15                   ` Dr. Arne Babenhauserheide
2020-11-16  6:26               ` Greg Minshall
2020-11-14 10:45   ` Diego Zamboni
2020-11-13 21:31 ` Jean Louis
2020-11-14 22:43 ` David Rogers
2020-11-15  5:38   ` Jean Louis
2020-11-15  7:47     ` David Rogers
2020-11-15  8:54       ` Jean Louis
2020-11-15 10:37       ` Greg Minshall
2020-11-15 11:42         ` Tim Cross
2020-11-15 11:48         ` Gustavo Barros
2020-11-15 11:58           ` Detlef Steuer
2020-11-15 12:09           ` Jean Louis
2020-11-15 14:50             ` Gustavo Barros
2020-11-15 15:11               ` Jean Louis
2020-11-15 10:44       ` Dr. Arne Babenhauserheide
2020-11-15 11:22         ` Detlef Steuer
2020-11-15 14:03           ` Kévin Le Gouguec
2020-11-16  5:24             ` Kyle Meyer
2020-11-16  6:41               ` Tim Cross
2020-11-16  7:15                 ` Tim Cross
2020-11-16 11:21                   ` Gustavo Barros [this message]
2020-11-16 23:24                     ` T.F. Torrey
2020-11-17  1:21                       ` Tom Gillespie
2020-11-17  7:01                         ` Dr. Arne Babenhauserheide
2020-11-17  7:48                       ` Michal Politowski
2020-11-19  4:17                     ` Marcel Ventosa
2020-11-16  8:06                 ` Kévin Le Gouguec
2020-11-16 12:10                 ` Bill Burdick
2020-11-16  6:54               ` Greg Minshall
2020-11-16  7:12                 ` Tim Cross
2020-11-17  4:03                   ` Greg Minshall
2020-11-17  5:25                     ` Tim Cross
2020-11-17 13:15                       ` Greg Minshall
2020-11-16  7:01               ` Dr. Arne Babenhauserheide
2020-11-16  7:22                 ` Tim Cross
2020-11-16 16:04                   ` Dr. Arne Babenhauserheide
2020-11-16 16:26                     ` Tom Gillespie
2020-11-16 18:12                       ` gyro funch
2020-11-16 18:48                         ` Tom Gillespie
2020-11-16 19:41                           ` Bill Burdick
2020-11-16 19:56                             ` Tom Gillespie
2020-11-16 21:50                             ` Tim Cross
2020-11-16 23:01                               ` Tom Gillespie
2020-11-16 21:44                           ` Tim Cross
2020-11-16 18:20                       ` gyro funch
2020-11-16 20:56                       ` Tim Cross
2020-11-16 21:35                         ` Bill Burdick
2020-11-16 22:44                         ` Tom Gillespie
2020-11-16 23:55                         ` Dr. Arne Babenhauserheide
2020-11-17  9:05                           ` Stefan Nobis
2020-11-17  9:15                             ` Loris Bennett
2020-11-17  9:32                             ` Diego Zamboni
2020-11-17 14:29                             ` Dr. Arne Babenhauserheide
2020-11-17 16:25                               ` Robert Pluim
2020-11-16 23:39                       ` Dr. Arne Babenhauserheide
2020-11-16 21:35                     ` Tim Cross
2020-11-17  0:11                       ` Dr. Arne Babenhauserheide
2020-11-17  8:45                         ` Detlef Steuer
2020-11-17  9:41                           ` Jean Louis
2020-11-17 15:33                     ` Maxim Nikulin
2020-11-16 13:00                 ` Uwe Brauer
2020-11-16 16:10                   ` Dr. Arne Babenhauserheide

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87blfxv966.fsf@gmail.com \
    --to=gusbrs.2016@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=theophilusx@gmail.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).