From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 8DhaGPT0sF8fdwAA0tVLHw (envelope-from ) for ; Sun, 15 Nov 2020 09:29:24 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id YBgoFPT0sF/vaQAA1q6Kng (envelope-from ) for ; Sun, 15 Nov 2020 09:29:24 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id A09A99401D0 for ; Sun, 15 Nov 2020 09:29:23 +0000 (UTC) Received: from localhost ([::1]:43302 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1keELZ-0004Cl-4Q for larch@yhetil.org; Sun, 15 Nov 2020 04:29:21 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:36746) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1keELB-0004CE-HK for emacs-orgmode@gnu.org; Sun, 15 Nov 2020 04:28:57 -0500 Received: from static.rcdrun.com ([95.85.24.50]:55393) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1keEL8-0005Vp-Ra for emacs-orgmode@gnu.org; Sun, 15 Nov 2020 04:28:57 -0500 Received: from localhost ([::ffff:41.202.241.56]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C000A.000000005FB0F4D4.0000185B; Sun, 15 Nov 2020 09:28:51 +0000 Date: Sun, 15 Nov 2020 11:54:36 +0300 From: Jean Louis To: Karl Voit , emacs-orgmode@gnu.org, Karl Voit Subject: Re: Changed list indentation behavior: how to revert? Message-ID: References: <2020-11-13T18-23-43@devnull.Karl-Voit.at> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/15 02:58:10 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -0.01 X-TUID: E9KG++H6mZA7 * David Rogers [2020-11-15 10:48]: :PROPERTIES: :CREATED: [2020-11-15 Sun 11:53] :ID: e9973880-3447-42c6-99e4-2a0b430d136b :END: > Jean Louis writes: > > > * David Rogers [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.