From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id kNiaM8uUL2K+ygAAgWs5BA (envelope-from ) for ; Mon, 14 Mar 2022 20:17:31 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 0B7lMMuUL2KwcQEA9RJhRA (envelope-from ) for ; Mon, 14 Mar 2022 20:17:31 +0100 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 5BF964431A for ; Mon, 14 Mar 2022 20:17:31 +0100 (CET) Received: from localhost ([::1]:40984 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nTqCA-00077t-3S for larch@yhetil.org; Mon, 14 Mar 2022 15:17:30 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33518) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nTqBN-00076z-7l for emacs-orgmode@gnu.org; Mon, 14 Mar 2022 15:16:41 -0400 Received: from [2607:f8b0:4864:20::102a] (port=54997 helo=mail-pj1-x102a.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nTqBL-0006rN-9u for emacs-orgmode@gnu.org; Mon, 14 Mar 2022 15:16:40 -0400 Received: by mail-pj1-x102a.google.com with SMTP id b8so15650186pjb.4 for ; Mon, 14 Mar 2022 12:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version; bh=JUtpaBJaAydT1y5Wpwr3/4tZleF00oqfDmwyllpkvYY=; b=GNNXJ2+2ORcQHPCeksCKJWVhJF0LCSub2SwTkDvcq5OBt+tgrgSKe8QNMom7C526W4 C0uZlj55BEqWfqkT+JyIKA75peGZS/CllLGywtRoJ2hpzGYcikintT4AJ0YwbXiSTEWl ZkmuITGrxaG9P/JowpzMKV6LxzVD497w1ie+ABO8Hu0aa/pwUyFPOhNLsGn2eSU2OmIG 95w+d4U7kmdK643r2MDzamHOwvfpZh0Vtem7p5ulzGZ/sLg7kDb2sh38xhBbNfjKQkef 1WmWKYkdci5Y4Wagd9c9fhiuQTdwZGJXmbjGijmvDR1XWdZicu0LgY6uN4gWzpLj2UHF Qwyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version; bh=JUtpaBJaAydT1y5Wpwr3/4tZleF00oqfDmwyllpkvYY=; b=0b36cse+6/VDATA8TbnTkUGtWIzyotIaBgU5cFs56gENBEGPm+ISOrMeawcA6NVP3T u/N9sHzJzYNACQg09RR5pOg0OqAL4qDvKti94LSDDEc8bvD6ATsPKsFfsEmHzto1obQq FO7EnccuU9bbFKQ4fqybVPGwHkzj2LSPGqn3Naxqdlfb0UVJxBf9oido/3i3tC/Mo0ea y14VBweUGF0j72+MH9ZGNcWUDb+MgS/ZuxQVsNlXb07QI/dCtIstzkVzzp3yJT6OSM4L qKnHYebHeGl6Za7gFf9lqYwM3jRjUce3m7FSmbqwaAHrBXPMrG+NKQuP/oDeX/fsEIGD Q9Og== X-Gm-Message-State: AOAM5318IraKN9inlWF16sznSgFGpokeqCiBYCutHIvmztHSQ/T/krw4 7O2Z1ATx2W8i+FUFiOd+ifoOjTiRDBysNg== X-Google-Smtp-Source: ABdhPJySP1UqoUqpkmzVOwIth7qOnoHt8EpPQyAfMb82GYfiLU3a45s5zN2xpyg/gQKmQgQPofuziw== X-Received: by 2002:a17:902:7c89:b0:153:758e:cb with SMTP id y9-20020a1709027c8900b00153758e00cbmr6430999pll.27.1647285397380; Mon, 14 Mar 2022 12:16:37 -0700 (PDT) Received: from dingbat (2001-44b8-31f2-bb00-2514-928a-0791-fa45.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:2514:928a:791:fa45]) by smtp.gmail.com with ESMTPSA id o3-20020a056a0015c300b004f72b29159csm22364021pfu.159.2022.03.14.12.16.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Mar 2022 12:16:36 -0700 (PDT) References: <87mthw8b74.fsf@gmail.com> User-agent: mu4e 1.7.10; emacs 28.0.91 From: Tim Cross To: Max Nikulin Subject: Re: [BUG] org-capture autoload bug? [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)] Date: Tue, 15 Mar 2022 05:42:21 +1100 In-reply-to: Message-ID: <87tuc0mjjj.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::102a (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::102a; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x102a.google.com X-Spam_score_int: -6 X-Spam_score: -0.7 X-Spam_bar: / X-Spam_report: (-0.7 / 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, PDS_HP_HELO_NORDNS=0.659, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1647285451; 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=JUtpaBJaAydT1y5Wpwr3/4tZleF00oqfDmwyllpkvYY=; b=PuK+p8oOPSkdauNYV7Q39NIYUGqJ4GkyzlOOYGg8/H6H71Z3+h4jMCTwtHkDoaJG18chTc kiUrN2QQFIKKYe6i90to8ykumcMMoluAqNER/f98DqCvd614MvEgFxzI/1L9L9gsKJPkTI NZ2Fw6YCMW9QiIrFLk+r5Ye2K4dXfFoPx5FnAEyqkUlJmVLOnJNtjJeueZ/yxTscMnsi/M rrvugeRhsRdTlWviFiNUQRGQe/Q9Yxhxxj/s32FdNNZV7LXxiUkNCrVAe8drE0LxMcVKif 5ZhVz1bP/UM+rQBDVu3xB4qcqX4aDl+osP62XqO9Bh/dQ77dvNw1FFiZ+QWCpA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1647285451; a=rsa-sha256; cv=none; b=ZweKq4C6UKYVpwNjTaWibF/VSay7KNjqZL1YtMjuYmbUqWqdDCt81A6OyFd/6YxYNtw9y6 2qr1mUjB8wxA1XIrtw9QXjIekntGuR/B+uZAkdkWrLf5yTJyYdZa9ur8dDQ+QXaBVZYbJx S88O9k0XFC6WwWiVtv0RqBTnuIgVoygWMwVpuuY/LSj9hN8/ZnamioVwMtTPZpkZcVMljm aESyKGjGieltLzOEh2qVdRszwbKro+M5t5IT66GSZsn09EBLFhtX8EquE7iDGlTyM2/ICA BKbIZIXx9OYatbycLld5sXtLrPWLFmzZ5zpywaZldVmsrd1MKYkO16hAeizjxg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=GNNXJ2+2; 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" X-Migadu-Spam-Score: -5.97 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=GNNXJ2+2; 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" X-Migadu-Queue-Id: 5BF964431A X-Spam-Score: -5.97 X-Migadu-Scanner: scn0.migadu.com X-TUID: HqL7XOlkAh+W Max Nikulin writes: > On 12/03/2022 02:59, Tim Cross wrote: >> Ignacio Casso writes: > >>> (let ((org-capture-templates >>> '(("d" "default" entry >>> (file+headline org-default-notes-file "Tasks") >>> "* %?")))) >>> (org-capture nil "d"))) >>> >>> I put an autoload cookie myself and it doesn't fix it, so it's probably >>> not that. It's the first time I manage autoload cookies though, so I may >>> have done something wrong. I only tested that the autoload cookie worked >>> by checking that before loading org-capture, org-capture-templates >>> appears in the completion list for C-h v, and I can evaluate it. >> While I don't know if this is a bug, it certainly doesn't seem to be >> doing the right thing from an 'intuitive' point of view. I would expect >> when a variable is bound to a value inside a let and a function is then >> called which uses that variable, the initial let bound value should be >> used and the result be the same regardless of whether org-capture has or >> has not been loaded. It means there is a hidden side-effect here, which >> isn't good and probably needs more analysis. If you had set the value >> using setq rather than as a let form, it wouldn't be overridden when >> org-capture is loaded, so why does it when it is a let binding? > > For `defcustom' autoload generates no more than > > (defvar org-capture-templates nil "...") > > It seems, behavior depends on whether `org-capture-templates' has the :set > attribute. The setter receives nil instead of the let-bound value. I can not say > I understand the tricks with bypassing lexical binding in `defcustom' and some > checks in `custom-declare-variable'. Since emacs-26 something has changed: > > https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=6309131349 >> - ;; Use defvar to set the docstring as well as the special-variable-p flag. >> - ;; FIXME: We should reproduce more of `defvar's behavior, such as the warning >> - ;; when the var is currently let-bound. >> - (if (not (default-boundp symbol)) > > I am unsure that the setter of `defcustom' should get let-bound value in the > case of autoloading since it might lead to fragile behavior. > > I still think that explicit templates argument for `org-capture' is better than > relying on autoloading. > Yes, it would seem that something has changed and I suspect it may be related to the introduction of lexical bindings. Explicit template arguments for org-capture may or may not be better, I don't know. However, this behaviour seems like it may be the tip of a much bigger issue outside of org-mode and potential source of bugs for Emacs. Bottom line is I don't think any function should behave differently depending on when autoload runs. It could be because the setter used in the defcustom is incorrect since the change a while back to use lexical-binding by default or something else. It looks like the setter on org-capture-template is used to do some form of conversion on the template specification to force a new format. Not sure how long that has been there or whether it is actually still required. Could be that this setter was added to aid in transition to a new template format which could/should be removed at some point. Personally, I've never liked custom setters. I typically avoid the custom interface. However, exotic custom variable setters can mean that using setq won't work correctly and you need to use custom-set-variable etc. In fact, I'm seeing a lot more use of custom-set-variable* in init code recently - something which was almost never seen 20 years ago. Regardless, I don't think having the situation where the programmer must know (guess) whether autoload will/could execute during the evaluation of code they write is tenable and am beginning to suspect it may be an Emacs bug OR a subtle bug in org-mode as a result to the transition to lexical binding as the default. My recommendation would be to come up with a non-org specific example which reproduces the behaviour and then ask on emacs-devel, using the example to demonstrate the issue. > Reading the code I noticed `org-capture-templates-contexts' so I wonder if it > might help for the original use case. I thought about that as well. However, from re-reading the OP's posts, I suspect not. org-capture-templates-contexts seems to be useful when you want to restrict access to some templates based on context. However, from reading the OP's posts, I get the impression that what they want is for templates to be different based on context i.e. they still want the template associated with 'd', but want its definition to be different. It is possible org-capture-template-contexts might provide an alternative solution where you don't need to dynamically modify/add templates in this manner. For example, you could have all your templates defined, but only offer those relevant based on context. However, I guess this would mean having to have different template keys, which might be an issue.