[bug] org-capture fails with undefined org-time-was-given variable

[bug] org-capture fails with undefined org-time-was-given variable

[Eric S Fraga]

Hello,

I have the following org capture template:

#+begin_src emacs-lisp
(setq org-capture-templates '(("j" "journal" entry (file+datetree+prompt "~/s/notes/journal.org")
                               "* %(format-time-string \"%H:%M\") %^{Entry} %^G\n%i%?")))
#+end_src

(other rules elided for clarity).  Trying this today (after not using it
for a long time), I get the following error:

,----
| Debugger entered--Lisp error: (void-variable org-time-was-given)
|   org-capture-set-target-location()
|   org-capture(nil)
|   call-interactively(org-capture nil nil)
|   command-execute(org-capture)
`----

I don't actually use this rule any longer as I prefer to clock in and
out but I was trying to show a friend how he could use org for
journalling.

I've had a look at the source (reasonably up to date) but this variable
does not seem to be something I should be setting.  Is my capture rule
somehow wrong?  Or is this a bug in org-capture?

Any suggestions or pointers welcome!

Thanks,
eric

-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_8.0.3-144-gf1b99a

Re: [bug] org-capture fails with undefined org-time-was-given variable

[Nick Dokos]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> Hello,
>
> I have the following org capture template:
>
> #+begin_src emacs-lisp
> (setq org-capture-templates '(("j" "journal" entry (file+datetree+prompt "~/s/notes/journal.org")
>                                "* %(format-time-string \"%H:%M\") %^{Entry} %^G\n%i%?")))
> #+end_src
>
> (other rules elided for clarity).  Trying this today (after not using it
> for a long time), I get the following error:
>
> ,----
> | Debugger entered--Lisp error: (void-variable org-time-was-given)
> |   org-capture-set-target-location()
> |   org-capture(nil)
> |   call-interactively(org-capture nil nil)
> |   command-execute(org-capture)
> `----
>
> I don't actually use this rule any longer as I prefer to clock in and
> out but I was trying to show a friend how he could use org for
> journalling.
>
> I've had a look at the source (reasonably up to date) but this variable
> does not seem to be something I should be setting.  Is my capture rule
> somehow wrong?  Or is this a bug in org-capture?
>

FWIW, I tried the capture rule in a minimal emacs and it's working fine
for me:

Org-mode version 8.0.3 (release_8.0.3-144-gbd09fe @
/home/nick/elisp/org-mode/lisp/)

That includes a bunch of private commits, but when I look at git history
I don't find the commit you mention in your org version, f1b99a, so
maybe you have your own bunch of private commits and one or more of them
broke something? Maybe try a vanilla org?

The variable is indeed not to be set by you: it's a dynamically scoped
variable, so somebody binds it at some level and then every callee
(direct or indirect) can access it. Stepping through
org-capture-set-location shows that it is unbound up until the call to
org-read-date (line 907-909 in org-capture.el) and it is bound on return
from that function, at least in my case.

> Any suggestions or pointers welcome!
>
> Thanks,
> eric

-- 
Nick

Re: [bug] org-capture fails with undefined org-time-was-given variable

[Bastien]

Hi Eric,

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> I've had a look at the source (reasonably up to date) but this variable
> does not seem to be something I should be setting.  Is my capture rule
> somehow wrong?  Or is this a bug in org-capture?

I can't reproduce this... can you reproduce the problem with emacs -Q?

-- 
 Bastien

Re: [bug] org-capture fails with undefined org-time-was-given variable

[Eric S Fraga]

Dear Nick & Bastien,

Thanks for your responses.

Both of you indicated that you don't have the problem with Emacs -Q.  I
don't either.  Sorry, I should have tried a minimal example before
posting.

In any case, I have tracked down the offending line in my customisation
that leads to the error:

  (setq org-popup-calendar-for-date-prompt nil)

The default is t which allows my capture to work but I don't want a
calendar popup.  Note that there is a new name for this variable,
org-read-date-popup-calendar but it makes no difference which name I
use.

I have tried tracing this through but have failed to figure out why the
setting of this variable makes a difference.  See below.

> Org-mode version 8.0.3 (release_8.0.3-144-gbd09fe @
> /home/nick/elisp/org-mode/lisp/)
>
> That includes a bunch of private commits, but when I look at git history
> I don't find the commit you mention in your org version, f1b99a, so
> maybe you have your own bunch of private commits and one or more of them
> broke something? Maybe try a vanilla org?

My org *is* vanilla!  I try to keep it as such.  I live dangerously
enough by tracking the development version on a relative frequent basis
... :-)

It's very strange that you could not find the commit.  But I have
updated org since then unfortunately so cannot reproduce the
situation.  I am sending this email from a different system so it has a
different org version (long story).

> The variable is indeed not to be set by you: it's a dynamically scoped
> variable, so somebody binds it at some level and then every callee
> (direct or indirect) can access it. Stepping through
> org-capture-set-location shows that it is unbound up until the call to
> org-read-date (line 907-909 in org-capture.el) and it is bound on return
> from that function, at least in my case.

Yes.  The only place I can find where the variable is actually given a
value is in org-data-analyze (sic) but I can't figure out the trail that
leads to this happening (it involves org-end-time-was-given).

I may try later to see if I can figure this out.  In any case, this is
not mission critical in any sense!  I was just surprised when the error
happened.

Thanks again,
eric

-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_8.0.2-101-gce5988

Re: [bug] org-capture fails with undefined org-time-was-given variable

[Bastien]

Hi Eric,

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> I have tried tracing this through but have failed to figure out why the
> setting of this variable makes a difference.

Thanks for the directions, fixed in maint now.

-- 
 Bastien