Ignacio Casso writes:
>> Please don't use ditto. (what does it even mean?)
>
> It means the same thing again. I saw it in the message of the Emacs
> commit I referenced earlier in this thread, so I assumed it was standard
> practice. I have replaced it with "The same". But if the problem is that
>> Subject: [PATCH] use `set-default-toplevel-value' in `defcustom' setters
>^Use
>
>> * lisp/ob-lilypond.el (org-babel-lilypond-commands): use
>^Use
>> `set-default-toplevel-value' instead of `set' or `set-default' in
>>
Ignacio Casso writes:
>> LGTM! Unless others have objections, I am inclined to merge the patch
>> fully. But please add changlog entries to the commit message.
>
> Done. I attach the patch with the new commit message.
Thanks! Some more comments.
> Subject: [PATCH] use
On 11/06/2022 20:32, Ihor Radchenko wrote:
Ignacio Casso writes:
Then we should decide if we want to use autoload cookies for custom
variables to make this work also with lexical binding. Otherwise, code
like the snippet above would produce an error in Emacs 29, and in Emacs
27 the let binding
> LGTM! Unless others have objections, I am inclined to merge the patch
> fully. But please add changlog entries to the commit message.
Done. I attach the patch with the new commit message.
>From 26d157aedfaf1496174682a1f9033d83160a06c2 Mon Sep 17 00:00:00 2001
From: Ignacio Casso
Date: Sat,
Ignacio Casso writes:
> Then we should decide if we want to use autoload cookies for custom
> variables to make this work also with lexical binding. Otherwise, code
> like the snippet above would produce an error in Emacs 29, and in Emacs
> 27 the let binding would be ignored (although at least
Hello,
The bug I reported about this to the Emacs devel mailing list
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54399) has now been
closed, and some documentation has been updated in commit 071722e41120.
Basically, the problem is that in order for
(let ((custom-variable local-value) ...)
> I'll write now the email to emacs-devel with all these issues and
> mention in this thread the corresponding debbugs thread in case anyone
> wants to follow it.
54...@debbugs.gnu.org
>>> 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.
After trying to build a simple example I have realized a part of my
analysis was
>>> 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
On 15/03/2022 02:43, Ignacio Casso wrote:
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
Ignacio Casso writes:
>> 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
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
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
> 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
>
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,
Ignacio Casso writes:
> Max Nikulin writes:
>
>> Ignacio, I think, you can add (require 'org-capture) inside your
>> function just before `let' and it would work almost as lazy loading.
>
> Thanks, I was already using (require 'org-capture) in my init file to
> solve this. As I said, it's not
Max Nikulin writes:
> Ignacio, I think, you can add (require 'org-capture) inside your
> function just before `let' and it would work almost as lazy loading.
Thanks, I was already using (require 'org-capture) in my init file to
solve this. As I said, it's not really a problem for me, I was
On 11/03/2022 01:00, Ignacio Casso wrote:
Max Nikulin writes:
On 10/03/2022 19:53, Ignacio Casso wrote:
For example, if we call this:
(let ((org-capture-templates
'(("d" "default" entry
(file+headline org-default-notes-file "Tasks")
"* %?"
Max Nikulin writes:
> On 10/03/2022 19:53, Ignacio Casso wrote:
>> For example, if we call this:
>>(let ((org-capture-templates
>> '(("d" "default" entry
>> (file+headline org-default-notes-file "Tasks")
>> "* %?"
>> (org-capture nil "d")))
>>
On 10/03/2022 19:53, Ignacio Casso wrote:
For example, if we call this:
(let ((org-capture-templates
'(("d" "default" entry
(file+headline org-default-notes-file "Tasks")
"* %?"
(org-capture nil "d")))
It produces the error:
(error "No
Hello,
I think I've found a bug with org-capture autoload. If the first time
you use org-capture before it's actually loaded is within a let form binding
org-capture-templates, it produces an error saying that the template was
not found.
For example, if we call this:
(let
22 matches
Mail list logo
