[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] Org Clock Error
From: |
Nick Dokos |
Subject: |
Re: [O] Org Clock Error |
Date: |
Thu, 14 Jan 2016 10:59:16 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
Marco Wahl <address@hidden> writes:
> Nick Dokos <address@hidden> writes:
>
>> I'm not sure what the solution is (I haven't really followed the
>> upstream discussion), but I wonder if adding
>>
>> (defvar org-state)
>>
>> in org.el, just before the
>>
>> (defun org-todo ...
>>
>> line is enough to resolve the problem (basically letting org-todo know
>> that org-state is dynamically bound).
>>
>> Untested and possibly wrong.
>
> Manually tested your suggestion and it fixes the issue of '(void-variable
> org-state)'.
>
> Technically I'm not sure what a reliable fix looks like. There is
> e.g. already the line
>
> (defvar org-state) ;; dynamically scoped into this function
>
> in org-clock.el.
>
Right - and I think that allows the org-clock-* functions to treat
org-state as a dynamically bound variable.
But at the other end, org-todo has to set its value but since it does
not know that org-state is a special variable (I'm guessing while waving
hands violently), it creates its own lexical binding and sets that,
breaking the intended communication.
*Why* org-todo does not know that org-state is a special variable, is an
interesting question. I can see that if one byte-compiles org.el, the
compiler will not know that the variable is special without the defvar
and will translate any references to a stack offset. It is not clear to
me what happens if you run uncompiled: the specialness of the variable
should be globally available, so org-todo *should* be able to figure
things out - I have not tried it, so I don't know whether it does or not
- or whether this is a red herring. These are all guesses, untainted by
actual knowledge or research.
Corrections, clarifications, etc. to any of this are more than welcome.
--
Nick