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 0L+IAJ+Ss1+jIAAA0tVLHw (envelope-from ) for ; Tue, 17 Nov 2020 09:06:39 +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 ILUBOJ6Ss19JZQAAB5/wlQ (envelope-from ) for ; Tue, 17 Nov 2020 09:06:38 +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 2EBDD9402B0 for ; Tue, 17 Nov 2020 09:06:38 +0000 (UTC) Received: from localhost ([::1]:55736 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kewwe-0005xJ-Pa for larch@yhetil.org; Tue, 17 Nov 2020 04:06:36 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41354) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kewvp-0005vX-Jp for emacs-orgmode@gnu.org; Tue, 17 Nov 2020 04:05:45 -0500 Received: from basilikum.nobis-admin.de ([89.238.71.130]:50942) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kewvm-0001Ur-Qe for emacs-orgmode@gnu.org; Tue, 17 Nov 2020 04:05:45 -0500 Received: from bohne (p200300cd67370f00e9bd7dd5f4927282.dip0.t-ipconnect.de [IPv6:2003:cd:6737:f00:e9bd:7dd5:f492:7282]) by basilikum.nobis-admin.de (Postfix) with ESMTPSA id D8CFA6D81C24 for ; Tue, 17 Nov 2020 10:05:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=snobis.de; s=default; t=1605603936; bh=MOyFU2qdRz+JgHV7g38jCSfI1Ab9IzvPe+0xzOPxG8Q=; h=From:To:Subject:References:Date:In-Reply-To:From; b=VsRZrxOUGnX9fNajGD0tlOtUz9ITWvgkr2zOt2un9emRsEnnvX1N2CFi0rjbNyHnH pmJYzFcgpUB/HccWKZImvWtgkC/U7Ud6YDD5aSmPxtUwfYmjSavZIfUis3+EOr7jix AqvtABrBBV4SIcsqkeyJm2RojVVKZoUUTkl4HdBQ= From: Stefan Nobis To: emacs-orgmode@gnu.org 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> <871rgtwzrs.fsf@web.de> <87y2j1ahqf.fsf@gmail.com> <87v9e5uw2u.fsf@web.de> <87sg999g13.fsf@gmail.com> <87k0ukvotx.fsf@web.de> Mail-Followup-To: emacs-orgmode@gnu.org Date: Tue, 17 Nov 2020 10:05:36 +0100 In-Reply-To: <87k0ukvotx.fsf@web.de> (Arne Babenhauserheide's message of "Tue, 17 Nov 2020 00:55:54 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (darwin) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=89.238.71.130; envelope-from=stefan-ml@snobis.de; helo=basilikum.nobis-admin.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/17 04:05:37 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] 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, 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=pass header.d=snobis.de header.s=default header.b=VsRZrxOU; dmarc=pass (policy=reject) header.from=snobis.de; 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: mqXeV0yxKAM6 "Dr. Arne Babenhauserheide" writes: > Sad story short:... I'm with you - last weekend I upgrade my OS and had quite some trouble to get everything working again and still have some nasty hoops to jump through. But on the other side: What are we talking about? Org had a given default configuration for quite some time. To be clear: THIS DID NOT CHANGE! But some people are upset now. Why? Because the emergent behaviour changed. Not the underlying default configuration, but in the context and details of how each individual uses Org for some users the default configuration was emergent and evident, but some other users did not perceive this default configuration. Now a simple setting, syncing Org with the defaults of Emacs and other modes with respect to RET and electric-indent-mode, make the OLD, UNCHANGED default configuration emergent for almost all users. These are very subtle effects inside a very complex environment. How should maintainers be able to foresee all possible environments and use cases and the resulting emergent behaviour? I'm really surprised that such a simple and insignificant breaking change results in such a uproar. If a new Org version make all old files completely unusable or a bunch of important features is totally broken, say nothing of babel works anymore - yes, is such a case I would understand the uproar. But ranting so loudly and insistent and continuously over such a minor details is really beyond me. And nobody has to read all NEWS and Changelogs for every single peace of software they are using. If nothing breaks maybe there is nothing to worry about. If some minor detail like the new emergent indentation behaviour annoys you - just have a quick look in the NEWS file of the new version. Is this really that hard? On the other hand: What's the alternative? Never change anything again? Maybe some users rely on the emergent behaviour of some bad bug (that has bad consequences for some other users). Should it never be changed, because it may annoy some users and they could be forced to read the NEWS file? You cannot have the cookie and eat it! So, everyone, please calm down and try not to overreact over really simple, negligible details. -- Until the next mail..., Stefan.