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.2...@gmail.com> wrote:
> Hi Tim,
> Hi All,
>
> On Mon, 16 Nov 2020 at 18:15, Tim Cross <theophil...@gmail.com> wrote:
>
> > Tim Cross <theophil...@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.
>
