From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>
Received: from mp12.migadu.com ([2001:41d0:306:2d92::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by ms9.migadu.com with LMTPS
	id YDLtKh0D1mT8WwEASxT56A
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Fri, 11 Aug 2023 11:45:01 +0200
Received: from aspmx1.migadu.com ([2001:41d0:306:2d92::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by mp12.migadu.com with LMTPS
	id cJmPKh0D1mRUewEAauVa8A
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Fri, 11 Aug 2023 11:45:01 +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 4B37B38417
	for <larch@yhetil.org>; Fri, 11 Aug 2023 11:45:01 +0200 (CEST)
Authentication-Results: aspmx1.migadu.com;
	dkim=pass header.d=posteo.net header.s=2017 header.b=msPRaYPR;
	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-Seal: i=1; s=key1; d=yhetil.org; t=1691747101; a=rsa-sha256; cv=none;
	b=f8DLs09pdM/Ccu5tYrHt9pvrTVal/aOFogunsSugCslwi8fTYVU1lL+ws+dH1QV5k5sNlw
	4XWmE/YNXz5WU9mNl1X5a0Q6fZYWHN+PgQUHhOUl2Xjt22JAPP+hAWl02XU0KhdxYKFj8e
	DwIMZwSpxl7v0cezWN/RF6M/6Nbzx5hmiPBJ5+PzuOWFfdJPMwiT0b5VOR3jbc2d9aTUwI
	J0+sg6NN5EE0mblMlt8MSiHcHBub+3AShq1cGybCyLzqJ5oCiJlpziG6w8FSxgwfZm87Jb
	bxHhh4Dmr2QUqG+uXr7aNFKPvUCfuwfH5OzD9GU5pbziTPfgAkqq2ZlDJPHmog==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org;
	s=key1; t=1691747101;
	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=jMvHgO54du1zwn78xKOr/VRPGBv0tTeJpPd/vidj4NQ=;
	b=ILaS5P1C62/ybXfXKNRp7sHV3nw1oLf3rN5F6I6bl+BmMY3+uANOaKnxp1IfNLW0+KDVH1
	x9HVuY9xzDO2cKuYTi4Pi15qbLUPqgwUlfcqfScxojyZEhB4f3iVC8LLAPTbIT+X+nNhTt
	5kdWWlVoyPaoRDb3h3jzBYTmQtWzTbMELuIMZIq0vmsxCySgjLiA4vfY7eRF2ZiS5dE1RA
	FbDOvM1UJ8f4UAATmo1q0ZtWhOg968sW0RBbbmZTTdqv7mS4qB/0b2Nxgzzl+ubaO8Zn55
	YEzKlSKBO/Imh4+IlXV41Q9VIk0Y0jYLrk+PkVbWGhoa+2u9vKmcMFBL6h5gBA==
ARC-Authentication-Results: i=1;
	aspmx1.migadu.com;
	dkim=pass header.d=posteo.net header.s=2017 header.b=msPRaYPR;
	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 <emacs-orgmode-bounces@gnu.org>)
	id 1qUOgi-0000Dc-Hj; Fri, 11 Aug 2023 05:44:08 -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 <yantar92@posteo.net>)
 id 1qUOgh-0000DD-DZ
 for emacs-orgmode@gnu.org; Fri, 11 Aug 2023 05:44:07 -0400
Received: from mout01.posteo.de ([185.67.36.65])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <yantar92@posteo.net>)
 id 1qUOgf-0006oh-7l
 for emacs-orgmode@gnu.org; Fri, 11 Aug 2023 05:44:07 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id 29D41240027
 for <emacs-orgmode@gnu.org>; Fri, 11 Aug 2023 11:43:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1691747036; bh=bn0Ik0xaO4YlpLXfoMSxDr+RrfVa8UZWjD/BLMns37E=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From;
 b=msPRaYPRr9xduGMWg7qDCscXgz8m6pTOlzo0QNP/FJye03R55CwlaLwdf/ABy5mTQ
 ad+2g5LVE3kRn0DgfIP/4ijbKk4z+EKOZFYuUrbU1gJrygyXs2CL7NT2GJiqcsuTvY
 L7BKrTBMk/+eS3Q6+k5wjAXKTQKj49MAvSy39Zr3tIiMve//+YmC6EIx1zgBP+1HK9
 KCS9j0EFuBKb1rkVOVl5iKR5QZpmjdUcdduyywg0xB67w7bJkEvUh2ipxqsMqZywVd
 UXReRBBOOudFmLBYkA4kA7vHav4WDWtszD01JNbHKfEkxRWEIUNuBTeW9ORsisMnsi
 HZ0Dh2lsp8P0A==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4RMf4q3Fb9z9rxL;
 Fri, 11 Aug 2023 11:43:55 +0200 (CEST)
From: Ihor Radchenko <yantar92@posteo.net>
To: Bastien Guerry <bzg@gnu.org>
Cc: Max Nikulin <manikulin@gmail.com>, 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: <875y5pvf04.fsf@bzg.fr>
References: <87o7omg4ie.fsf@alphaville.usersys.redhat.com>
 <87pm91ngb8.fsf@localhost> <87jzz8f3re.fsf@alphaville.usersys.redhat.com>
 <87mt43agk6.fsf@localhost> <tvhovc$mna$1@ciao.gmane.io>
 <874jq8ohbr.fsf@localhost> <87bkfip3mo.fsf@gnu.org>
 <87r0odrkbp.fsf@localhost> <875y5pvf04.fsf@bzg.fr>
Date: Fri, 11 Aug 2023 09:44:22 +0000
Message-ID: <87bkfdud55.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net;
 helo=mout01.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." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=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-Spam-Score: -7.85
X-Migadu-Scanner: mx2.migadu.com
X-Migadu-Queue-Id: 4B37B38417
X-Spam-Score: -7.85
X-TUID: zKT2qJm912dv

Bastien Guerry <bzg@gnu.org> writes:

>> 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.
>
> org-mouse.el should not modify default Org _editing_ key bindings.
> Is it really the case?  If so, can we fix this?

Yes, org-mouse modifies the behavior of certain key bindings. Not
directly, but by advising `org-open-at-point'.
Also, org-mouse adds new key bindings, potentially overriding custom
user bindings for mouse keys.

> Does org-inlinetask.el modifies the way non-inline headlines are
> edited?
> ... If so, can we fix this?  IIRC org-inlinetask.el only adds
> editing function for inline tasks, it is an extension, not a
> modification of the default Org editing behavior, but the limit
> can be thin here.

It changes the very notion of that is a headline - the syntax definition
is altered. Very deeply nested headlines may become inlinetasks upon
loading org-inlinetask, touching all aspects of Org, not just editing.

And it is not clear how to fix this. We did not make inlinetasks into
standard Org syntax in the past and now it is in the weird state when we
have (featurep 'org-inlinetask) sprinkled across the code just to
accommodate for this conditional syntax.

Inlinetasks are too similar in syntax with headlines, so it is
impossible to make the change backwards-compatible.

>> 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."
>
> Defining new functions is a desirable "side-effect" of all Elisp
> library, I don't think we should worry abou this.

Defining new functions by itself is not a big deal. But there are parts
of Org that alter their behavior depending on whether a feature is
loaded (like org-inlinetask) or depending whether certain function
symbol is defined (babel). Similarly, loading new link types re-defines
Org syntax in all the documents, affecting editing of everything that
looks like the loaded link type (org-ctags).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>