From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.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 yKSAJnAF2GRRIgEASxT56A (envelope-from ) for ; Sun, 13 Aug 2023 00:19:28 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id yMCrJXAF2GQZOgEAG6o9tA (envelope-from ) for ; Sun, 13 Aug 2023 00:19:28 +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 00E9A5FCE5 for ; Sun, 13 Aug 2023 00:19:27 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=cYi1gitn; dmarc=pass (policy=none) header.from=gmail.com; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1691878768; 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=ED0+v7fyuoKI9ghecu+PWCUFAvFfx2KpD8phjN/PfcU=; b=OnrcDPw1qTysyqAEUAUrg0vcHaamNiuhh07AWUu4W+rD/X3aTNSMCpAc41rGhOykfzhotO z90gCrgB/FmpY6pFLMtMGEp711dlIR8y9sPOLXJA2u76hhCJVHTwfw3QyetD0irgBbSe33 ET8ttzLNh/t66VFVU5NTaCodEH/F8UWcs4nnj93FXeDSTZwvBOZdMFMQ8PxBonHD91MUUt lhxZ6AcrsKwVFONGnl+iGLce6Ct+q+LV6KqNzfiPxKq7TanoE1oShjhyyn47XkXN2+LFIv aGzrPrwuinF2f2dgjY3Je7tFTuHxJrUG9TVE32SuXtgdiFkCET90Cd8uwmKj1A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=cYi1gitn; dmarc=pass (policy=none) header.from=gmail.com; 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" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1691878768; a=rsa-sha256; cv=none; b=Y0MgFkjQ91fMJZ6WVeOZlWoxZPmnpbRr5w0XC24O7qlMitUB7SOcBctVt0qO1MjlF0ooLa mHihYUYu6j5BOWquoob1fMr5yySOqvYd4Cko7NNmTdE8UVHKL13gtazn/+R7hXFnzVitv7 nyRZM/bwU2tyQhIiElz1Hho+D3uTkfMnOQh2UTQNNpFNQcTjPlOEGRIWDhCkYPdzjm4Lx3 jRAdhv3gGyxkJoKCNJZshV+SNnT/HDIspZFt4iCrQr3hYOckXuUQF2Mf7TZUI0BSMiKbGN 3Im6zekG6t5jkPRxt1oDVH4LcJ8//MS/SpEtV3StKGzV83nUqGWHMi5/rwyk8g== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qUwwX-0001Li-Cz; Sat, 12 Aug 2023 18:18:45 -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 1qUwwW-0001LD-5l for emacs-orgmode@gnu.org; Sat, 12 Aug 2023 18:18:44 -0400 Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qUwwU-0004m5-34; Sat, 12 Aug 2023 18:18:43 -0400 Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-4fe0cfc7ef9so1173231e87.0; Sat, 12 Aug 2023 15:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691878718; x=1692483518; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ED0+v7fyuoKI9ghecu+PWCUFAvFfx2KpD8phjN/PfcU=; b=cYi1gitnscC7fo5SZEuek5tj0P83a1bMP1nsEuHCec7Ylqjc1+N7IM6CgYOCTKrCUL 7z06fX1KfOA9RzCs1fvDH0sexH9znyqqeI7pMrQthiUO+pXjbRbTogiHvPVxDQccA6xp lYXSUCK5qCDsd7ae0k9WUOh3vKtnH9GvACXOyzCB4HacZCYsnC8MKAkhovKsEBDYXPQG NarlflKobS4bx/TW/OVZKuqzgnHw99OlfU9BtWY1x1Mjge0N61eZdsHrwI41hgLS/xM2 u3MP1RSOr0+rAYa29Lu9l3r99YWSKWNhTODrl1be9xsTkn8TxVafKdm8sYfTVsYsdXH2 jhVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691878718; x=1692483518; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ED0+v7fyuoKI9ghecu+PWCUFAvFfx2KpD8phjN/PfcU=; b=gSPA+XCYAGkTBAHJXuzBMdsxeGqw+Vy5xsjxAwlDXqxpNFgjR/6NPAR+nST4dNG2gM XYh2kZhQsYYt/BzNGOibS4dp+t6X8QeFxarbmknLyHcYkZ3pPYuCDjYUJ2BZehBchkpL BNJ2PtlBp9NHLrkTFLzXQQVbX4gCPs2N8mbHYixT+S+oaAkIiCs9yBUxc4VXhugCVZ+N Hgpjovh+nVY0616Mqf1JVyNMwFM9vAlgahXZEs2r68Aghy6OYTkgUOdEyKFPtwHZWaTg FGCzEoN+OA2yD7olmZcusf+ZOuMa9x1tyvq+HnWDzclg4e2gX/k6G58+de7ysp+JTN7u i++A== X-Gm-Message-State: AOJu0Yx3hDz4MTPfo77fWFiQIA7njmPPD9AgOZCuPiARER+dv5/2ZBCH U3H9LPIxry+9m8cenZLU+3SYVsvKfYynRGCozeol+g3astQ7yAwREbY= X-Google-Smtp-Source: AGHT+IHsK+6uFwZsXu4cnWto8KgaU+Lqe0AzfhAeQq6XDrEsHnA63/L4G4dxMjxvKB9UsLR91dmMvnYd41qYw/K04DI= X-Received: by 2002:ac2:4883:0:b0:4f7:7980:fcdc with SMTP id x3-20020ac24883000000b004f77980fcdcmr3243076lfc.3.1691878717904; Sat, 12 Aug 2023 15:18:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9a:7ac4:0:b0:270:13b:14c4 with HTTP; Sat, 12 Aug 2023 15:18:36 -0700 (PDT) In-Reply-To: <87cyzswhqn.fsf@bzg.fr> 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> <87r0odrkbp.fsf@localhost> <875y5pvf04.fsf@bzg.fr> <87bkfdud55.fsf@localhost> <87cyzswhqn.fsf@bzg.fr> From: Samuel Wales Date: Sat, 12 Aug 2023 15:18:36 -0700 Message-ID: Subject: Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? To: Bastien Guerry Cc: Ihor Radchenko , Max Nikulin , emacs-orgmode@gnu.org Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::132; envelope-from=samologist@gmail.com; helo=mail-lf1-x132.google.com 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.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-Spam-Score: -8.56 X-Migadu-Queue-Id: 00E9A5FCE5 X-Migadu-Scanner: mx0.migadu.com X-Migadu-Spam-Score: -8.56 X-TUID: AgEHK9jcb6/g may i post a few notes? i've had tehse previously. 1. i rely on org-mouse for accessibility, as i often cannot use keyboard at all, so there is a personal stake in having it be part of org so that it is fully integrated. of course i have no problem with having to enable it instead of only load it. it has /minor/ limbo status in that, for example, you can't set a specific todo kw with the mouse, but that does not disturb me as much as code rot. see below. 2. i don't use org-inlinetask enough to have a personal stake [in my case i could make them siblings], but it seemed to me that it was never sufficiently integrated into org, or had bugs, at least before parsers became common. if anybody does have a strong personal stake in them, like i do in 1., it might be desirable to make inline tasks, even breakingly, part of org, merely to make sure that they fully integrate and test, as opposed to limbo or code rot. i would apply that principle to org-mouse, which being smallish and about bindings is probably not too disruptive to be part of org. i defer the measurement of the disruptiveness of inline tasks to the experts/stakeholders. 3. istr loading org-id is or was what enables org-ids? i'd rather have org-id work by default. OR maybe require activating. 4. idk if related, but some settings in org must be done before loading. i'd want a guideline in which, where possible, settings can be done after loading. this is because the user might need to go through contortions in .emacs. a user can do with-eval-after-load, but with-eval-before-load sounds radically grotesque. On 8/12/23, Bastien Guerry wrote: > Ihor Radchenko writes: > >> Yes, org-mouse modifies the behavior of certain key bindings. Not >> directly, but by advising `org-open-at-point'. > > IIRC Emacs core libraries should not advise functions. > This is something we should fix. > > Also, I'm not sure org-mouse.el has its place in Org's core nowadays. > >> 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. > > Same here, I'd be tempted to deny Org citizenship to inline tasks: it > always felt like a nice hack for a niche use-case, but a hack anyway. > > If it modifies Org syntax in surprising ways, this is another argument > for removing org-inlinetask.el from Org's core. Remember: this is not > to say that inline tasks are forbidden, it's just a message for users > that inline tasks are something not maintained by Org's core team. > >> 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. > > Yes, this is ugly. > >> 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). > > I feel like the stakes are not the same for features like org-mouse.el > and org-inlinetask.el and for core features like Babel libs and links. > For the former, a decision should be made relatively to the usefulness > of the feature; for the latter, loading libs (with side-effects on the > syntax) is required by the design of the core feature at hand (Babel > and links). > > I'd focus on solving the problem with org-mouse and org-inlinetasks > first. Let's make a poll for org-mouse.el then for org-inlinetasks.el ? > > -- > Bastien Guerry > > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com