emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Changed list indentation behavior: how to revert?


From: Gustavo Barros
Subject: Re: Changed list indentation behavior: how to revert?
Date: Mon, 16 Nov 2020 08:21:53 -0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

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
#+end_src

(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
#+end_src

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

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

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

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

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
#+end_src

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
https://emacs.stackexchange.com/q/55413/18951).

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]