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
