From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id vE82IS3ytV+ZQAAA0tVLHw (envelope-from ) for ; Thu, 19 Nov 2020 04:18:53 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id EDuiHC3ytV/OTAAAB5/wlQ (envelope-from ) for ; Thu, 19 Nov 2020 04:18:53 +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 BCF79940148 for ; Thu, 19 Nov 2020 04:18:52 +0000 (UTC) Received: from localhost ([::1]:53330 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kfbPH-0008Nm-Oz for larch@yhetil.org; Wed, 18 Nov 2020 23:18:51 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46406) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kfbOf-0008NP-EO for emacs-orgmode@gnu.org; Wed, 18 Nov 2020 23:18:14 -0500 Received: from aibo.runbox.com ([91.220.196.211]:35232) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kfbOa-0006WX-NZ for emacs-orgmode@gnu.org; Wed, 18 Nov 2020 23:18:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=selector1; h=Content-Transfer-Encoding:Content-Type:MIME-Version: References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=d9Rb/0f5Hro69WsotKGlS3n//1FDAt3gS2UEjZELirI=; b=bPCg5TVDoqBZMfw+hCCjMCgqrH 1slMnChZolD3REDCOLHfrLH6Ctg2Sj2evj3wujYALANhs2kVICzeWKzzS2iYrfWYk4zNhwTH3QHWR qimbCzeYa5Aq6NV8jn+25HaHX/ZAmj0jjkivoUQ0PNYt1M5gk+R4uG/EEU10QVlB9J9zQ/8OSpWH7 YszAbJ8CgzBVaApk2zd42pnSDNodv47ctSd1HTSjF72+eehuUHH5SBQufoHTyhscSdGSBUDUY7hCL 1ZPhwe5Hi94mJwO4DY0avKdfbtlNbfV+MHac8TEUvNhdQo0YMMPdHL48d893pqPD0W+MmcELNPZ88 yrJinbvw==; Received: from [10.9.9.74] (helo=submission03.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1kfbOW-0000SP-HT; Thu, 19 Nov 2020 05:18:04 +0100 Received: by submission03.runbox with esmtpsa [Authenticated alias (585453)] (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) id 1kfbOS-0005Li-5e; Thu, 19 Nov 2020 05:18:00 +0100 Date: Thu, 19 Nov 2020 11:17:48 +0700 From: Marcel Ventosa To: Gustavo Barros Subject: Re: Changed list indentation behavior: how to revert? Message-ID: <20201119111748.271f2709@argon> In-Reply-To: <87blfxv966.fsf@gmail.com> References: <2020-11-13T18-23-43@devnull.Karl-Voit.at> <874klqew77.fsf@web.de> <20201115122154.50ad1503@linux-h0yu.fritz.box> <87tutq67ka.fsf@gmail.com> <87tutpvppm.fsf@kyleam.com> <877dqlby74.fsf@gmail.com> <871rgtbwml.fsf@gmail.com> <87blfxv966.fsf@gmail.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=91.220.196.211; envelope-from=mve1@runbox.com; helo=aibo.runbox.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/18 23:18:05 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -24 X-Spam_score: -2.5 X-Spam_bar: -- X-Spam_report: (-2.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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: , Cc: Tim Cross , emacs-orgmode@gnu.org 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=pass header.d=runbox.com header.s=selector1 header.b=bPCg5TVD; dmarc=pass (policy=none) header.from=runbox.com; 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.21 X-TUID: s5NiO1ZfUHO0 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 wrote: > Hi Tim, > Hi All, > > On Mon, 16 Nov 2020 at 18:15, Tim Cross wrote: > > > Tim Cross 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. >