From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id ALEbAXsB0mQZOQAASxT56A (envelope-from ) for ; Tue, 08 Aug 2023 10:48:59 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id iJ3jAHsB0mQyfQAAauVa8A (envelope-from ) for ; Tue, 08 Aug 2023 10:48:59 +0200 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 7664958AC1 for ; Tue, 8 Aug 2023 10:48:58 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=GpP7pXmK; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1691484538; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=GMQrW2j1Us5UTShfPksJZqAvpd/NCg1gegG/CzNkvI8=; b=np7vYT5gZTme9XQxPKrCk2X8wha447sEwEA06Vla83eVGMq2qAcLAGnItaGMc3AeJbmjiC 0OPba8FcWFoj0+m+ayWP2j8HQwQuaLsET99dZWsbHQC6/wWhZUjIFrzBjNv/mN4ZV4ohFl AbrcqcRU+mslRh0k6gjwUoqughlX0UTKg9plbP2SgGXtw8dQV6kM4KMcMbKmCjIY7gp/tV ofyZmdD+Zw5fXenFmEXqpVhwT6vCbmj7R8ciSsqk3QqmWZ/gkl1UdSslpKsJcX460YjjSc ujA8+yUWT+wuAnRmnV5dukRd/HUkjq+QFzJrOBJN47GMLSfyR3OKwVKCg3ZQIQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1691484538; a=rsa-sha256; cv=none; b=g03A1VqxMmaIK3N52QDWzWTR/MZ7vys2lFuzDeP16Lss3BNcAXXQZfFXYWE/I5uj6bY/GW VgooY1q29x/PIXw6XGSL9+nD+HDqZ+n+Sk9W0FuZxr9vLZ0TqJpwhQf3yX7XqQJ+MmFBIY FM4RY/eDOhLfXTvwvSvnKDDf9juj2w6LHM8y7itFNvj6cVvvX9Evfj3/BcFqaW2ljfhuWK 9hWOAJVJL6f494ulduMK9j0u2D9/ECfnIJJrHDCNVmbicTWTbkMyRbSLqjnupNcKiJS3Fk MD+GruenB5LPJtScDBAmDWRghPH9J3MhtdXBUwq1dBQu/rG5xRI4fZAPIX1SWQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=GpP7pXmK; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qTINo-0001HY-3g; Tue, 08 Aug 2023 04:48:04 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qTINl-0001HI-AZ for emacs-orgmode@gnu.org; Tue, 08 Aug 2023 04:48:01 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qTINj-0006zM-Ee for emacs-orgmode@gnu.org; Tue, 08 Aug 2023 04:48:01 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 68AEA240103 for ; Tue, 8 Aug 2023 10:47:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1691484477; bh=y8gBL4YbgGN3t9a4xoKSH0fxTHiL7o5WPWiDx3q6Syc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=GpP7pXmK0bb9ZTEqT7jVVy92ir/oqR9xMb8kuMOCvLBF5kFqkbnBahJxYeq2858Ig I4yzZsxOhW6pC6SBuRWuqoEp5xoHfB34TqFJxM/pNtvpTM/l8slreOAwfmEsA4FxZK /4Jzs/lqHN0IudBk0Ocx0/7kidTRLQ3ZBFUSSmqPNEXCahONvp1y+denmnTh9f8EfZ CBSlpI1FXE7o0Ph/S3WbjRKIBk5ExtwyN3RqEQEdKwmZHLd3wuA14LX37F+52JGrby AB7/VgBNcZbEhuFefozwG5w1/iX4i/zxKKK+E924iciqwNfN8JG3plY06X1D6T39JO noScKiQRMVgoA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RKmzc5qtTz6tn4; Tue, 8 Aug 2023 10:47:56 +0200 (CEST) From: Ihor Radchenko To: Bastien Guerry Cc: Max Nikulin , emacs-orgmode@gnu.org Subject: Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? In-Reply-To: <87bkfip3mo.fsf@gnu.org> References: <87o7omg4ie.fsf@alphaville.usersys.redhat.com> <87pm91ngb8.fsf@localhost> <87jzz8f3re.fsf@alphaville.usersys.redhat.com> <87mt43agk6.fsf@localhost> <874jq8ohbr.fsf@localhost> <87bkfip3mo.fsf@gnu.org> Date: Tue, 08 Aug 2023 08:48:26 +0000 Message-ID: <87r0odrkbp.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=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.29 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-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Queue-Id: 7664958AC1 X-Migadu-Scanner: mx0.migadu.com X-Migadu-Spam-Score: -5.34 X-Spam-Score: -5.34 X-TUID: ljgHdnouKfuL Bastien Guerry writes: >> This is convincing. >> I am then CCing Bastien, as, despite the Elisp convention, following it >> will break https://bzg.fr/en/the-software-maintainers-pledge/ > > FWIW, in this case, the mistake lies in breaking the Emacs Lisp coding > convention first. When the breaking change is a side-effect of fixing > a bug, it is unavoidable. The situation is a bit more complex. Strictly speaking, loading Elisp library _always_ has side effects of defining new functions. And, for example, Org babel's behavior is modified when ob-foo.el is loaded because `fboundp' on 'org-babel-execute:foo returns non-nil. A bit different approach is used for ol-foo.el, where more significant side effect is triggered by top-level calls to `org-link-set-parameters'. Similarly, ox-foo.el uses `org-export-define-derived-backend' or `org-export-define-backend'. Finally, we have org-mouse.el discussed here, which modifies key bindings and org-inlinetask.el, which modifies how Org treats headlines in Org files, modifying syntax. With the current state of affairs, it is often enough to (require 'org-library) to get things work. If we get rid of all the possible side effects, users will have to adapt their configurations and we will thus violate "I won't force you to update your configuration." Of course, we can change babel implementation to use explicit registry like for export backends and force users to call explicit activation commands in addition to (require 'library). But I am not sure if we are not crossing the line with such an approach: "I won't use software correctness as an excuse.". -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at