From: Ignacio Casso <ignaciocasso@hotmail.com>
To: Tim Cross <theophilusx@gmail.com>
Cc: Max Nikulin <manikulin@gmail.com>, emacs-orgmode@gnu.org
Subject: Re: [BUG] org-capture autoload bug? [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]
Date: Mon, 14 Mar 2022 20:43:10 +0100 [thread overview]
Message-ID: <PAXPR06MB77602336C5ED470F8FC834CCC60F9@PAXPR06MB7760.eurprd06.prod.outlook.com> (raw)
In-Reply-To: <87tuc0mjjj.fsf@gmail.com>
I've also investigated the issue a little bit further and wrote and
email with my conclusions about the same time Max wrote his. I comment
inline about a few of your thoughts:
> 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.
Not really, all defcustoms have a :set attribute, be it passed
explicitly as a parameter or the default value, set-default. This issue
happens with all autoload functions that use a custom variable: if they
are called inside a let form binding that variable and the feature was
not loaded yet, the let-binding will have no effect.
> 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:
> 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.
See my other email where I explain what I think that defcustom of a
variable is doing when called inside a let-binding of that variable.
>> 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))
But the conclusion is that right now it does not work, so I think that warning
is needed.
> 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.
That is right, it seems it was added for backwards compatibility when a
new template format was added. However, it's not actually needed, since
org-capture-select-template also calls that function to ensure they are
in the new format. It needs to do so in order to allow
setting org-capture-templates also with setq, or let-binding
org-capture-templates as I do. That's not the problem anyway, as I
explained above.
> 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
> 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.
I agree. I'm on it.
>> 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.
If I recall correctly template contexts allow to redefine the template
key, so that would not be an issue. And yes, using template contexts
could probably be a solution to my use case, as it would be having an
org-capture version with template parameter. But don't worry too much
about my use case, since a simple (require 'org-capture) is enough to
keep doing what I was doing.
next prev parent reply other threads:[~2022-03-14 20:28 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-10 12:53 [BUG] org-capture autoload bug? [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)] Ignacio Casso
2022-03-10 16:32 ` Max Nikulin
2022-03-10 18:00 ` Ignacio Casso
2022-03-11 10:07 ` Max Nikulin
2022-03-11 10:38 ` Ignacio Casso
2022-03-11 19:59 ` Tim Cross
2022-03-14 10:42 ` Ignacio Casso
2022-03-14 14:52 ` Max Nikulin
2022-03-14 18:42 ` Tim Cross
2022-03-14 19:43 ` Ignacio Casso [this message]
2022-03-14 22:54 ` Tim Cross
2022-03-15 9:02 ` Ignacio Casso
2022-03-15 15:59 ` Ignacio Casso
2022-03-15 12:04 ` Max Nikulin
2022-03-15 12:26 ` Ignacio Casso
-- strict thread matches above, loose matches on Subject: below --
2022-06-11 7:50 Ignacio Casso
2022-06-11 13:32 ` Ihor Radchenko
2022-06-11 17:25 ` Ignacio Casso
2022-06-14 4:02 ` Ihor Radchenko
2022-06-14 7:49 ` Ignacio Casso
2022-06-14 13:58 ` Ihor Radchenko
2022-06-12 12:36 ` Max Nikulin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=PAXPR06MB77602336C5ED470F8FC834CCC60F9@PAXPR06MB7760.eurprd06.prod.outlook.com \
--to=ignaciocasso@hotmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=manikulin@gmail.com \
--cc=theophilusx@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).