Marco Wahl <marcowahls...@gmail.com> writes: > Nick Dokos <ndo...@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
