From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Lundin Subject: [BUG] org clock history no longer loaded from org-clock-persist-file Date: Mon, 04 Jan 2016 09:32:16 -0600 Message-ID: <8760z98inz.fsf@fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49531) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG77Q-0006fN-4W for emacs-orgmode@gnu.org; Mon, 04 Jan 2016 10:32:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aG77L-0001ub-60 for emacs-orgmode@gnu.org; Mon, 04 Jan 2016 10:32:24 -0500 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:42021) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG77K-0001tw-Ok for emacs-orgmode@gnu.org; Mon, 04 Jan 2016 10:32:18 -0500 Received: from archthink (c-50-172-132-15.hsd1.il.comcast.net [50.172.132.15]) by mail.messagingengine.com (Postfix) with ESMTPA id C1077C016F3 for ; Mon, 4 Jan 2016 10:32:16 -0500 (EST) 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: Org Mode With the shift to lexical-binding in org-clock.el (commit 35bc1c8853c5cfe37930e3540a944a328af5198b), the function org-load-clock fails to load the stored data in org-clock-persist-file. These are the relevant setting in my .emacs: (setq org-clock-persist t) (setq org-clock-persist-file "~/data/org-clock-save.el") (org-clock-persistence-insinuate) Expected result: After calling the agenda for the first time, the variable org-clock-history is populated with data. Actual result: org-clock-history remains nil. As far as I can tell, the problem lies with the call to load-file (line 2986). Because of the lexical binding, the (setq stored-clock-history ....) statement stored in the org-clock-persist-file is evaluated but because of the lexical scoping it has no effect on the stored-clock-history in org-clock-load. Ironically, this also means that stored-clock-history is defined as an irrelevant global variable even while it remains undefined within org-load-clock as a local variable. (Before lexical binding, the opposite was the case: the call to load-file bound stored-clock-history locally, but not globally). Best, Matt