all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.
> 



  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.