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 sO+mNg2lsV8jTgAA0tVLHw (envelope-from ) for ; Sun, 15 Nov 2020 22:00:45 +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 EAyOMg2lsV95XwAAB5/wlQ (envelope-from ) for ; Sun, 15 Nov 2020 22:00:45 +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 44C2C9407E3 for ; Sun, 15 Nov 2020 22:00:45 +0000 (UTC) Received: from localhost ([::1]:41258 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1keQ4i-0000qB-8O for larch@yhetil.org; Sun, 15 Nov 2020 17:00:44 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:48568) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1keQ3s-0000pa-6o for emacs-orgmode@gnu.org; Sun, 15 Nov 2020 16:59:52 -0500 Received: from mail-wr1-x431.google.com ([2a00:1450:4864:20::431]:38628) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1keQ3p-0006wS-RM for emacs-orgmode@gnu.org; Sun, 15 Nov 2020 16:59:51 -0500 Received: by mail-wr1-x431.google.com with SMTP id p8so16719614wrx.5 for ; Sun, 15 Nov 2020 13:59:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=Lh6lBqHOBbVIsY/lvbleJcCUNqFcpeV2bgRBLB0NEdI=; b=brtekmZyencTwsfG8daDUR0Zzd9fMpiJjMp+YsIqcp+KncO2+97q4sSk5GItdHJKpl wExPC3o8TjwDj9KatJc+7z08RnMye2COahMEQR58s8GUXc+oHfw5jYq+hT9t8HfvCo5z JNNxcyxzxuGDqNQh9jvJKSJbZmwR79RTMYIFn9v31xgsTGwaiX+iNyy/o6NQkuz0UbVO 1y7sJXMMBu/OO2rNvEohPJgCKLCqZ0UEC1vzP2HnOX2Fc//q4mlj9FO3DIQhhsq8EtU+ lKpA2/yZuaPz02NF+FtiImV1EZn0o8VfawSu70cT0I5vOOeLOG+VjjvvahdnjY1ixtjQ g7hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=Lh6lBqHOBbVIsY/lvbleJcCUNqFcpeV2bgRBLB0NEdI=; b=OOCNn0hQcF/8yCmwDgNxi4+OGh7BNqVTRcXlxJRnfJ8tXKtS+Qdt9/WBgdIjLKellJ 1FWMVVBrtSr9cDext2yji3vvRn8NBU/t09ZO1pkhIDqH2MdDds9ZGzMDaMaNtuSGIM9l RHPqINTJZk6LyRoOkHzhrORxk9gb4yyz2OZqWXeQoaQRHG/6ogK+BL8D6fJI7Er9EkMb tDoPrsSepNyWIQg7YUtMK7FA0NMISBEqVeQE71Rx9rGwrZ5UCOlwm7mf9QxfePKbYNKt yo7ROIfjYZ/jqTBM2nG6foPbOtT78JsQzz4GagtGhLGP5vwZUBTGBClo+z4EV4hd+MoB LTKA== X-Gm-Message-State: AOAM533HrVO4O1lKe6ve5mhf+uAiKm7hdtsJ/NwSZ5QKUOmexeOkvRBc e3Nn5zRphwZlY23mIEtJEgY/oQV99KdP5g== X-Google-Smtp-Source: ABdhPJzNfKCvje2+YHOCW5EKrTmTHKRSyJpsXJyJvWCm0Y5rDyMaBDA/9az+afHEBAP4n+kM/YZEAQ== X-Received: by 2002:adf:f3c4:: with SMTP id g4mr16285173wrp.399.1605477585486; Sun, 15 Nov 2020 13:59:45 -0800 (PST) Received: from my-little-tumbleweed ([2a01:e0a:20e:d340:922b:34ff:fe95:9aed]) by smtp.gmail.com with ESMTPSA id y20sm17144182wma.15.2020.11.15.13.59.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Nov 2020 13:59:44 -0800 (PST) From: =?utf-8?Q?K=C3=A9vin_Le_Gouguec?= To: Jean Louis Subject: Re: Changed list indentation behavior: how to revert? References: <2020-11-13T18-23-43@devnull.Karl-Voit.at> <871rgxotcv.fsf@gmail.com> <87zh3koqgk.fsf@gmail.com> <871rgu7pt9.fsf@gmail.com> Date: Sun, 15 Nov 2020 22:59:43 +0100 In-Reply-To: (Jean Louis's message of "Sun, 15 Nov 2020 16:26:25 +0300") Message-ID: <87k0umjn74.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::431; envelope-from=kevin.legouguec@gmail.com; helo=mail-wr1-x431.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: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_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=pass header.d=gmail.com header.s=20161025 header.b=brtekmZy; dmarc=pass (policy=none) header.from=gmail.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.71 X-TUID: SJSEXKEiQvvt Jean Louis writes: > There is just slight difference, and that is what I learned from > introduction to Org mode that it is "plain text" kind of mode. I can > do and write how I wish. My habit comes from being used to indent when > I want and then to follow indentation in that specific paragraph. That > is really great. > > But I was not used to have it indented by programmer like the > introduction of this new default feature, which I consider is not > useful to be default. Note that even before this change, Org's indentation already behaved like a "programming mode". TAB does not allow you to move to "any column": - either org-adapt-indentation is t (the default) and TAB moves your paragraph to column LEVEL+1, - or it is nil, and TAB is a no-op. > Observe this official presentation and you will see how current > indentation is not consistent to what is shown: > https://orgmode.org/resources/img/features/folding.gif > > Look at this official presentation and you will see that even headings > are indented for which we say it should not be so: > https://orgmode.org/resources/img/features/clocking.svg Yep, AFAICT this has been produced with org-indent-mode, which soft-indents using overlays. > The official presentation here: > https://orgmode.org/ > > does not show any indentation at all. > > And in Info file I find nothing of it. Yep; what this (along with the way org-adapt-indentation is unset in Org's own repo) suggests to me is that Org, by default, should not indent section bodies. This means *not only* that RET should not indent, but that /TAB/ should not rigidly indent to column LEVEL+1 (I don't have a strong opinion about whether it should rigidly indent to column 0, or if it should behave as in text-mode). So AFAIU the issue lies not with RET becoming consistent with the rest of Emacs and doing "insert newline then indent smartly"; rather it lies with how Org defines "smartly". From what I gather from this thread, lots of folks would like Org to keep section bodies at column 0. > All I say, when default is introduced, should be well documented how > and why. Before it is introduced it is better to discuss wider with > people. > > Few of people reading these exchanges may find how to turn it off, > majority will not find it. Before being applied, this change has been discussed on emacs-devel and emacs-orgmode; it has then been documented in ORG-NEWS. Which other places do you think we should have reached out to? >> IIUC this can be toggled off by setting org-adapt-indentation to nil; >> FWIW this is what the .dir-locals.el file at the root of Org's >> repository doe > > With 2000+ directories containing Org file of persons, held on this > system that would mean turning it on 2000+ times. Because in general I > do not use that type of indentation I have just set it in main > ~/.emacs.d/init.el file. > > We concluded that configuring is easy and that is great. > > What is not concluded is that the default impacts too many people who > may not find out how to configure it back and that designing user > interface shall be made with more care. I admit to not having put as much thought in a "migration plan" as I could have. My reasoning was that since Org indents text by default (/when/ hitting TAB or using the "smart newline" command), users were probably fine with it. IIUC I failed to understand that: - Plenty of Org users do not expect it to behave like programming modes wrt indentation (they might not even use programming modes). - These users were using RET as a "dumb newline" command, unaware that by default, Org considers that text should be indented. - org-adapt-indentation=E2=80=A6 - exists (really, I just found out about it today, after wondering why on Earth Org does not indent text in doc/org-guide.org, and tracing it to the repository's directory-local variables). - has a default value that does not reflect how Org text is indented in official examples, nor in Org's own repository.