emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Jean Louis <bugs@gnu.support>
To: Karl Voit <devnull@Karl-Voit.at>,
	emacs-orgmode@gnu.org, Karl Voit <news2042@Karl-Voit.at>
Subject: Re: Changed list indentation behavior: how to revert?
Date: Sun, 15 Nov 2020 11:54:36 +0300	[thread overview]
Message-ID: <X7DszP+GZHrR6LvS@protected.rcdrun.com> (raw)
In-Reply-To: <s0e4klr3vu4.fsf@gmail.com>

* David Rogers <davidandrewrogers@gmail.com> [2020-11-15 10:48]:
  :PROPERTIES:
  :CREATED:  [2020-11-15 Sun 11:53]
  :ID:       e9973880-3447-42c6-99e4-2a0b430d136b
  :END:
> Jean Louis <bugs@gnu.support> writes:
> 
> > * David Rogers <davidandrewrogers@gmail.com> [2020-11-15 01:44]:
> > > Hello
> > > 
> > > After reading several of the responses to this, I’ve started to
> > > wonder: Is
> > > electric-indent-mode broken for everybody because it contains a bug
> > > or
> > > design flaw, or is electric-indent-mode working fine but simply not
> > > suitable
> > > for every situation?
> > > 
> > > In other words, where is the “right” place to fix this problem?
> > 
> > It was working in Org file automatically well and fine.
> > 
> > As if user decides to indent, electric-indent would help the user:
> > 
> > ** HeadingRET
> > 
> > At this point below user may decide to indent:
> > 
> >    - First itemRET after RET
> >    ^
> >    - the new line appears here
> > 
> > User has to move the cursor to the point shown above for indentation
> > to begin. That is good as user decides it and it is text, it is not
> > programming language with special convention for indentation.
> > 
> > Electric indent mode always worked like that, including in Org mode
> > without any problems.
> > 
> > The change that is introduced in my opinion, and I did not look into
> > code, is changing how electric indent mode behaves specifically for
> > Org mode as somebody assumes that immediately after headingRET the new
> > lines should be indented, like if there is some special indentation
> > convention for Org mode.
> > 
> > So without user deciding to indent, it does following:
> > 
> > ** HeadingRET
> >    - First line here
> >     But there is no indentation convetion for Org mode of that kind that
> > I
> > know.
> > 
> > The Org file shown on https://orgmode.org/ does not follow that type
> > of indenting.
> > 
> > Common indenting in Org mode is:
> > 
> > * Heading
> > Text
> > ** Heading
> > Text
> > *** Heading text
> > Text
> > **** Heading
> > Text here
> > ***** Heading
> > Text
> > ****** Heading
> > Text
> > 
> > AND if somebody likes to indent differently electric indent mode would
> > help.
> > 
> > Common indenting is not (other may tell me that I am wrong if this
> > statement is wrong)
> > 
> > * Heading
> >   Text
> > ** Heading
> >    Text
> > *** Heading text
> >     Text
> > **** Heading
> >      Text here
> > ***** Heading
> >       Text
> > ****** Heading
> >        Text
> > 
> > The above change was introduced as default to many users and is not
> > conveniente.
> > 
> > Especially not conveniente I find that I need to delete by using
> > backspace all the spaces inserted that I did not want after pressing
> > RET after inserting heading.
> > 
> > Some people will insert ONLY heading as a test without any text.
> 
> Thank you! You’ve really explained this clearly, and I understand your
> point.
> Am I crazy to say that your last example of unwanted behavior is easier for
> me to read and understand? (and to me the common indenting is a hopeless
> mess?)

I am not against indenting how users wish and want.

That is why electric-indent is there, it is by default there.

When you with your wanted behavior write this line:

** Heading
   :PROPERTIES:
   :CREATED:  [2020-11-15 Sun 11:53]
   :ID:       4e00e232-bf01-4ba5-a87b-6b0a9747ecee
   :END:

and press TAB, your cursor should automatically come to here below:

** Heading
   :PROPERTIES:
   :CREATED:  [2020-11-15 Sun 11:53]
   :ID:       be2a9fb6-bb27-416d-aa84-17e83a97f024
   :END:

   ^

Then when you start writing a line:

** Heading
   :PROPERTIES:
   :CREATED:  [2020-11-15 Sun 11:53]
   :ID:       bb1feeb1-0e3c-429f-90a7-86b577f3b0c9
   :END:

   Line here
   Next line automatically here

Your next line is automatically there.

Does programmer impose to you HOW to indent? No. You explicitly decide
by using TAB and writing indented lines that you wish electric-indent
mode to work for you.

> If the new behavior really does what you showed under “Common
> indenting is not…”, then I think I prefer the new way for my own
> use.

I prefer that every user can explicityl decide how to indent. User
group that wish to indent exactly under the letter where heading
begins, they can press TAB and continue doing it.

It is one key press.

If that is introduced as default then users with many Org files on
file system are by default faced with inconvenience for the sake of
those who find it convenient.

> And it makes sense to me that it should automatically work like
> that. I think the cursor jumping all the way back to the left margin
> after I’ve created a multi-starred heading makes no sense.

As you are indenting it that way I can understand that. I have tried
that in past. Try M-S-left M-S-right on heading to see what is
happening with such indentation if your heading was with more stars.

If I write:

* HeadingRET
  :PROPERTIES:
  :CREATED:  [2020-11-15 Sun 11:53]
  :ID:       b2aaa359-12d6-4e64-a5d8-ec02b0f79532
  :END:
     - one line
     - second line

Then if I go back to H in Heading and do M-S-left to make parent
heading, indentation is not moving along. Then I am left to correct
all the indentations manually.

If I wish to use M-q on region to indent how I mean it, it does not
work. That is my expectation but this specific need not be right.

Because I do lessen the number of stars in heading I do not wish to be
bothered with indentation that is disturbing otherwise nice considered
structure.

If I remember well when copying trees it was also about same or
related problem either introducing new indentation or not keeping the
wanted indentation.

I am not talking against your indentation neither against mine. Just
pointing out that default features that are not mature and are not
compatible with habbits of users neither of Org in general, should not
be introduced as such. That is not enough tested.

If you do copy subtree with heading 2 below with some text under the
list of items with C-c C-x M-w and later insert under Heading 1 with
C-c C-x C-y you will get heading 3 as you see below which is not
indented. That is to me bug. It is not bug if users do not mind WHERE
to indent, if they do not mind that indentation is moved for one char
to the right side. It definitely does not support consistency.

* Heading 1
  :PROPERTIES:
  :CREATED:  [2020-11-15 Sun 11:53]
  :ID:       f490a670-487c-4bc7-b57d-e0b3052f1291
  :END:

** Heading 3
   :PROPERTIES:
   :CREATED:  [2020-11-15 Sun 11:53]
   :ID:       722e5db0-9da1-43c8-9e1e-030957dfe742
   :END:
    - line
    - line

If there is text HERE.

** Heading
   :PROPERTIES:
   :CREATED:  [2020-11-15 Sun 11:53]
   :ID:       b46215dd-c4a9-47f1-a293-282c59021401
   :END:
   - line
   - line
*** Heading
    :PROPERTIES:
    :CREATED:  [2020-11-15 Sun 11:53]
    :ID:       f5775fe6-6771-4b59-9b15-d9720c9e5e12
    :END:
*** Heading 2
    :PROPERTIES:
    :CREATED:  [2020-11-15 Sun 11:53]
    :ID:       b4e9f819-8517-45d7-9237-0d654c99b657
    :END:
    - line
    - line

If there is text HERE.

** Here is end of headings
   :PROPERTIES:
   :CREATED:  [2020-11-15 Sun 11:53]
   :ID:       28bd67c3-906c-4ce7-ae63-79611938b018
   :END:

Feature of indentation after heading is not mature to be introduced by
default to all user of Org file.

Instead new option should be included that users who need that can
turn it on, and I do not mean to change anything with electric-indent
as default. Leave defaults how they are.

It is not logical to say to users of electric-indent, please remove it
only for Org files because we made defaults this way. I do need
electric indent including in Org files and it does work well itself.

But I’m also likely to forget to consider things that might go wrong
with implementing a new plan, so I’m not a great judge.  Does the
new behavior “break” something for you (causing errors etc), or does
it just look wrong?

** Heading
   :PROPERTIES:
   :CREATED:  [2020-11-15 Sun 11:53]
   :ID:       005cd684-f363-4008-a36e-d109d50a3f4f
   :END:
   - line
   - line
*** Heading
    :PROPERTIES:
    :CREATED:  [2020-11-15 Sun 11:53]
    :ID:       f018afcd-ed2c-4092-8e3e-f50ad915c2df
    :END:
*** Heading
    :PROPERTIES:
    :CREATED:  [2020-11-15 Sun 11:53]
    :ID:       a98ea345-3a42-4063-a795-0aad9790095f
    :END:
    - line
    - line
      
*** New
    :PROPERTIES:
    :CREATED:  [2020-11-15 Sun 11:53]
    :ID:       06bec39a-8f48-44cf-860f-614f3d85d5e7
    :END:
    
> But I’m also likely to forget to consider things that might go wrong
> with implementing a new plan, so I’m not a great judge.  Does the
> new behavior “break” something for you (causing errors etc), or does
> it just look wrong?  -- David Rogers

I have explained it above. It was introduced slightly and for I don't
know how many months I get all wrong indentations. It breaks
M-S-left/right and it breaks C-c C-x M-w based copy of trees and
subtrees and placing them in other parts of Org files.

Unspoken of table and other formatting that need to be compared
vertically, that goes out of any alignments. Using occur becomes hell,
but that is my personal preference just as it is yours to indent.

Table under one heading I wish to have aligned under different heading
in same columns.

You may like to have one table little right or left, those are
personal preferences.




  reply	other threads:[~2020-11-15  9:29 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 [this message]
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
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

  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=X7DszP+GZHrR6LvS@protected.rcdrun.com \
    --to=bugs@gnu.support \
    --cc=devnull@Karl-Voit.at \
    --cc=emacs-orgmode@gnu.org \
    --cc=news2042@Karl-Voit.at \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

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