From: Jean Louis <email@example.com> To: Karl Voit <devnull@Karl-Voit.at>, firstname.lastname@example.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 Message-ID: <X7DszP+GZHrR6LvS@protected.rcdrun.com> (raw) In-Reply-To: <email@example.com> * David Rogers <firstname.lastname@example.org> [2020-11-15 10:48]: :PROPERTIES: :CREATED: [2020-11-15 Sun 11:53] :ID: e9973880-3447-42c6-99e4-2a0b430d136b :END: > Jean Louis <email@example.com> writes: > > > * David Rogers <firstname.lastname@example.org> [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.
next prev parent 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 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://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 \ --email@example.com \ --cc=devnull@Karl-Voit.at \ --firstname.lastname@example.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
Org-mode mailing list This inbox may be cloned and mirrored by anyone: git clone --mirror https://orgmode.org/list/0 list/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 list list/ https://orgmode.org/list \ email@example.com public-inbox-index list Example config snippet for mirrors. Newsgroups are available over NNTP: nntp://news.yhetil.org/yhetil.emacs.orgmode nntp://news.gmane.io/gmane.emacs.orgmode AGPL code for this site: git clone https://public-inbox.org/public-inbox.git