From: Marcel Ventosa <mve1@runbox.com>
To: Gustavo Barros <gusbrs.2016@gmail.com>
Cc: Tim Cross <theophilusx@gmail.com>, emacs-orgmode@gnu.org
Subject: Re: Changed list indentation behavior: how to revert?
Date: Thu, 19 Nov 2020 11:17:48 +0700 [thread overview]
Message-ID: <20201119111748.271f2709@argon> (raw)
In-Reply-To: <87blfxv966.fsf@gmail.com>
Hi all,
I've just caught up with this conversation after feeling similar
friction to others since the 'electric-indent' change.
When it happened, I spent time trying to figure out how to revert the
change (thinking I had introduced the bug myself in my configuration
somehow) and ended up setting 'org-adapt-indentation' to 'nil', which
solved some of my inconvenience while typing headlines, lists, etc.,
but not source blocks.
Source blocks
=============
After the change, it became extremely inconvenient to edit them inline,
as the level of indentation for the whole block changed constantly in
unexpected and unpredictable ways (when I pressed TAB, but maybe also in
other cases?).
In the end, the only solution has been to use {C-c'} any time I want to
modify one. While I understand that editing the source block in a
separate buffer is probably the "correct(TM)" way, I often make small
changes while looking at another buffer on a split screen, and {C-c'}
always pops up in a new buffer and forces me to reconfigure my buffers
to continue (I realize I can change 'org-src-window-setup', but
sometimes I still just want to edit the code in the actual Org document
itself).
---------------
I understand why the change was introduced, but it has really caused
some friction in my day-to-day work. I am very happy to find out today
how to undo this upgrade: I disliked and resented the rigitidy it
introduced into my interactions with Org. Looking back, I wish I'd spent
more time investigating the cause.
Best regards,
Marcel
On Mon, 16 Nov 2020 08:21:53 -0300
Gustavo Barros <gusbrs.2016@gmail.com> wrote:
> 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.
>
next prev parent reply other threads:[~2020-11-19 4:18 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
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 [this message]
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201119111748.271f2709@argon \
--to=mve1@runbox.com \
--cc=emacs-orgmode@gnu.org \
--cc=gusbrs.2016@gmail.com \
--cc=theophilusx@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.