From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: Org Clock Error Date: Thu, 14 Jan 2016 10:59:16 -0500 Message-ID: <87twmg5ezv.fsf@alphaville.usersys.redhat.com> References: <87ziw9aqxi.fsf@pierrot.dokosmarshall.org> <84fuy0mtvq.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58550) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJkJQ-0006pT-UZ for emacs-orgmode@gnu.org; Thu, 14 Jan 2016 10:59:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJkJL-00055f-R9 for emacs-orgmode@gnu.org; Thu, 14 Jan 2016 10:59:48 -0500 Received: from plane.gmane.org ([80.91.229.3]:40535) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJkJL-00055T-Ke for emacs-orgmode@gnu.org; Thu, 14 Jan 2016 10:59:43 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aJkJI-0006LS-Vh for emacs-orgmode@gnu.org; Thu, 14 Jan 2016 16:59:41 +0100 Received: from nat-pool-bos-t.redhat.com ([66.187.233.206]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Jan 2016 16:59:40 +0100 Received: from ndokos by nat-pool-bos-t.redhat.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Jan 2016 16:59:40 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Marco Wahl writes: > Nick Dokos 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