From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id gBNXC/Rgsl/eKAAA0tVLHw (envelope-from ) for ; Mon, 16 Nov 2020 11:22:28 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id gDQrB/Rgsl9dAwAAbx9fmQ (envelope-from ) for ; Mon, 16 Nov 2020 11:22:28 +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 B56F29401BF for ; Mon, 16 Nov 2020 11:22:27 +0000 (UTC) Received: from localhost ([::1]:50414 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kecaY-0004WE-Hr for larch@yhetil.org; Mon, 16 Nov 2020 06:22:26 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:44426) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kecaA-0004Vt-Vn for emacs-orgmode@gnu.org; Mon, 16 Nov 2020 06:22:03 -0500 Received: from mail-pl1-x62f.google.com ([2607:f8b0:4864:20::62f]:36105) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1keca8-00064Y-W5 for emacs-orgmode@gnu.org; Mon, 16 Nov 2020 06:22:02 -0500 Received: by mail-pl1-x62f.google.com with SMTP id k7so8238452plk.3 for ; Mon, 16 Nov 2020 03:22:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=/ajHrapPSbqLepuM6o1BniJfM9mbrz1kEzqJhh9E4sQ=; b=Or+wZKDupX4HAq9hn+VP/5+FLO3GcYWLf3LnImnmHt9uo253ayjwSYaAVd51S3Shhh mtaVrVhpijVfQloQ6BwzXTiX6Wmpf4t/i38r7AIZ3JmuEtNKhhqfOw7kNci7nIaLXiaS 9UQYKGLXwEHoC9F/LYMYXVY5AqwJhJadfLXL9o7B9TK4sERgGDXjzb/4cwlxfJqNiMwH sKDile8KZURVfeVLC5qKuEatkyW3csnT0oOtl24ljHw4dZRyqVzzY3m/g+cRQJXahm2H PT6QwFobv+t+x6UeCDVpeMA6K8LpTPsT7cjgnatkf2omWYIGahPFGNfFDfIRLWWy08px 9fsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=/ajHrapPSbqLepuM6o1BniJfM9mbrz1kEzqJhh9E4sQ=; b=qFQWEfMn0NYlsGjrg+vOwAYss78UEmygA/Fhu2Pqzo6RoC9iVeK1n9t8jw4ayK0AKJ m0G6RO19oZhk7Vu+HieDyREGmuYLahwylmrn15kFHhJTVZyN0ynpPAPt7wUrqOjp1b8b ADxQ9sqdRyKyOzYoaIC+8WXtuMDHgv2ktsj21+9D+MRcSiRHAwTxZUaThlTVwFs0hT+W QQawrNAPzogNi/BHI1/C8xY+btpl+VBD/0qvKjuqxmntynw60rQHGW8ZB1p6/onNkkyk HAjSLIb+foB7aOpraGgZuss1CF1FlTgMvRTW81i/fUh900PI7iU3h4JczWmfxzmvxxeo EZLA== X-Gm-Message-State: AOAM531vu4u6M1F9AjgiCq2QFcRIDdmISfiuKW6LrkmSwMLVh8l8Gx4A KhK7r/e0i8ylMCO4otGaQ5s4PQL4Y16gfw== X-Google-Smtp-Source: ABdhPJylV/O62GdckUaMqpXcKSZ99X7F7DEEnlhjl81NTpl7yMuI81Ekmy2ngaD31ZtccRsK+tXw5w== X-Received: by 2002:a17:902:82c3:b029:d6:c377:c87d with SMTP id u3-20020a17090282c3b02900d6c377c87dmr12350449plz.37.1605525719247; Mon, 16 Nov 2020 03:21:59 -0800 (PST) Received: from gusbrs-laptop ([199.116.118.169]) by smtp.gmail.com with ESMTPSA id y25sm17475400pfn.44.2020.11.16.03.21.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Nov 2020 03:21:58 -0800 (PST) From: Gustavo Barros To: Tim Cross Subject: Re: Changed list indentation behavior: how to revert? 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> Date: Mon, 16 Nov 2020 08:21:53 -0300 In-Reply-To: <871rgtbwml.fsf@gmail.com> (Tim Cross's message of "Mon, 16 Nov 2020 18:15:30 +1100") Message-ID: <87blfxv966.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::62f; envelope-from=gusbrs.2016@gmail.com; helo=mail-pl1-x62f.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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_NONE=-0.0001, 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: 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=fail (headers rsa verify failed) header.d=gmail.com header.s=20161025 header.b=Or+wZKDu; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=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: 1.09 X-TUID: CqbgmiwobA1P 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.