emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "T.F. Torrey" <tftorrey@tftorrey.com>
To: emacs-orgmode@gnu.org
Subject: Re: Changed list indentation behavior: how to revert?
Date: Mon, 16 Nov 2020 16:24:45 -0700	[thread overview]
Message-ID: <87a6vgq402.fsf@victor.tftorrey.com> (raw)
In-Reply-To: <87blfxv966.fsf@gmail.com>

Hello all,

I apologize in advance that this is so long.

I've been following this thread closely, because I've been using Org
mode daily for well over a decade, and this behavior affects me in
several important ways.  I think this summary might be helpful.

Forever, it has been possible to start a heading in Org by typing a
return one or more times, then typing an asterisk and a space and the
heading text.  To add a series of headings, just keep hitting return at
the end of the current one, type an asterisk and a space and the next
one, then repeat.  If you want subheadings, it is as simple as typing
more asterisks.  Easy.

This worked because electric-indent-mode defaulted to off, and although
org-adapt-indentation defaulted to t, it didn't affect this situation.

The default behavior here matters because Org is a killer feature of
Emacs, enticing many people to give it a try, including my nine-year-old
daughter.  For them, it should behave by default the way it looks like
it should.  That means, typing asterisks and text for headings, followed
by returns, and text, and more asterisks, should just work by default.

#+NAME: Old Defaults: electric-indent-mode OFF and org-adapt-indent t
#+begin_example org
,* Testing out Org, type <RET> here once or twice

I get it!  I'll type <RET> once or twice again and start a subheading.

,** Headings are easy!  Now another <RET> or two for subhead content

This is awesome!  It works just as I expect, and I don't have to
memorize a bunch of key chords just to get started.  And folding is
awesome!  I love Org!  I will stick with it and learn it all!

I have probably typed close to a million headings like this all by
myself, and collectively we have probably typed billions or more.

The last release, as everyone knows, turned on electric-indent-mode by
default.  So, right now, typing an Org document with default settings
does not work like it looks like it should.  This is the new experience
for people used to the old defaults, and beginners like my daughter:

#+NAME: New Defaults: electric-indent-mode ON and org-adapt-indent t
#+begin_example org
,* I typed an asterisk for this heading, how about <RET> here once or twice

  Okay.  This is indented.  Since I'm new, I don't realize it isn't
  useful yet, or that it makes a difference at all.  How about a
  subheading?  I'll hit <RET> a couple times, they type two asterisks.

  ,** Is this a subheading? It looks like one.  <RET> again here ...

  Okay, the indentation isn't the same, but maybe it's okay?  I
  probably didn't even notice.

  ,*** I think I'm organizing my document with *'s and <RET>'s

  I'm going to try folding my stuff, becaue I saw that and it looks

  Wait!  The instructions say <TAB> will cycle the folding, but it
  only works on the top level.  What?

  Okay, some searching said I have to modify init, or something, or
  type some weird key combinations.  What?  This looked like it was
  going to be easy.  Nerds are liars.

  I can't figure this out, and I don't have time to mess with this.
  I'm going back to Word.  Maybe I'll try Markdown tomorrow.

For new users, step one is either to start changing default settings,
start learning key chords and/or arcane (to beginners) commands---or go
back to Word or Markdown.

Turning on electric-indent-mode, all by itself, shouldn't break the
useful or customary indentation that the users of Org expect, but it
has.  Instead of starting a new heading by typing <RET> one or more
times, then typing an asterisk and a space and a new heading, a user
has to either hit some control characters with returns, or backspace to
column zero, or something else.

The manual shows heading and body formatting as this:

#+NAME: Org Manual Sample: electric-indent-mode on, org-adapt-indent t
#+begin_example org
,* Top level headline
,** Second level
,*** Third level
    some text
,*** Third level
    more text
,* Another top level headline

I don't recall ever seeing an Org document in real life with the body
indented at the level of each heading, and I haven't seen anyone argue
for that behavior on this thread.  I've tried it, and the text body
width rapidly becomes too narrow to be useful.  As several people have
noted, even the Org repositories turn this off, which suggests even
the developers don't find it useful.  Why this is set as the default,
I have no idea, but it didn't really matter until now.

An Org document looks like you can create it by typing asterisks,
text, and returns, but you can't, not by default, anyway.

That's the root of the problem: the longstanding default *behavior*
has been changed.  The only people unaffected are people who already
had compensatory settings in their init files.

As far as I can tell, turning on electric-indent-mode by default was
done for no reason other than other Emacs modes have it as a default.

The proper fix for this is one of two choices:

1. If keeping electric-indent-mode on is really important, the easiest
   way to restore intuitive behavior is to change the default of
   org-adapt-indentation to nil.  Yes, this changes a longstanding
   default, but it is necessitated because of the change of another
   longstanding default: electric-indent-mode.  Before, anyone who
   wanted text indented by default needed to specify that in their init
   file, so this should not inconvenience anyone who wasn't
   inconvenienced before.


2. More involved would be to change the default behavior of Org's
   electric indentation so that typing <RET> at the end of a heading
   takes you back to column 0 by default.  In many contexts, the
   indentation provided by org-auto-indent is useful, but not this

The Emacs manual says that "Electric Indent mode is a global minor mode
that automatically indents the line after every <RET> you type", but
that's not exactly true.  What it does do is indent a line to what is
useful or customary based on the context, which is often not at all.  In
the context of hitting <RET> at the end of a heading in Org, what is
useful may be debatable, but it seems customary for all serious Org
users to return to column 0, and that seems what new and casual users

Finally, I can point out that, for myself, adding another line to my
init file (actually a literate Org doc) is not a big deal.  I've been
using Org and Emacs long enough that changing defaults doesn't bother me

For new and casual users, including my nine-year-old daughter, however,
I hope we can change the defaults so that it works the way it looks like
it should.  It's not easy to get her to try Emacs and Org, and this
makes it harder.

Side note: the manual frequently refers to headings as "headlines", but
that is not the right use of that word.  To whit: there is no such thing
as a "subheadline", but there is a "subheading", because that construct
is a "heading", and a "headline" is something else.

All the best,

  reply	other threads:[~2020-11-16 23:25 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 [this message]
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=87a6vgq402.fsf@victor.tftorrey.com \
    --to=tftorrey@tftorrey.com \
    --cc=emacs-orgmode@gnu.org \


* 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).