Re: Org Clock Error

[Nick Dokos <ndokos@gmail.com>]

Marco Wahl <marcowahlsoft@gmail.com> writes:

> Nick Dokos <ndokos@gmail.com> 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