Symbol's value as variable is void: org-planning-line-re

Symbol's value as variable is void: org-planning-line-re

[Jeff Kowalczyk]

Using org-mode a4a1d85 or 2df0785, I see multiple errors, including:

Using M-q to fill a paragraph, error on the line at point:

  user-error: An element cannot be parsed line 7149

  user-error: An element cannot be parsed line 7141

When using M-RET to insert a heading:

  byte-code: Symbol's value as variable is void: org-planning-line-re

When using C-c to update the duration of a clocked time line:

  byte-code: Symbol's value as variable is void: org-planning-line-re

I reverted to 288ffa, ran make clean && make, and the problems are
no longer present.

Thanks,
Jeff

Re: Symbol's value as variable is void: org-planning-line-re

[Nicolas Goaziou]

Hello,

Jeff Kowalczyk <jeff.kowalczyk@gmail.com> writes:

> Using org-mode a4a1d85 or 2df0785, I see multiple errors, including:
>
> Using M-q to fill a paragraph, error on the line at point:
>
>   user-error: An element cannot be parsed line 7149
>
>   user-error: An element cannot be parsed line 7141
>
> When using M-RET to insert a heading:
>
>   byte-code: Symbol's value as variable is void: org-planning-line-re
>
> When using C-c to update the duration of a clocked time line:
>
>   byte-code: Symbol's value as variable is void: org-planning-line-re

`org-planning-line-re' is a defconst defined in "org.el". It looks like
a mixed installation.


Regards,

-- 
Nicolas Goaziou

Re: Symbol's value as variable is void: org-planning-line-re

[Jeff Kowalczyk]

Nicolas Goaziou <mail <at> nicolasgoaziou.fr> writes:
>
> Jeff Kowalczyk <jeff.kowalczyk <at> gmail.com> writes:
> 
> > Using org-mode a4a1d85 or 2df0785, I see multiple errors, including:
> >
> > Using M-q to fill a paragraph, error on the line at point:
> >
> >   user-error: An element cannot be parsed line 7149
> >
> >   user-error: An element cannot be parsed line 7141
> >
> > When using M-RET to insert a heading:
> >
> >   byte-code: Symbol's value as variable is void: org-planning-line-re
> >
> > When using C-c to update the duration of a clocked time line:
> >
> >   byte-code: Symbol's value as variable is void: org-planning-line-re
> 
> `org-planning-line-re' is a defconst defined in "org.el". It looks like
> a mixed installation.

It's possible, how do I confirm? I build org daily with
'make clean && make'. git status shows clean tree (d4e4b1e today).

$ find . -iname 'org.el*'
./lisp/org.el

$ find . -iname '.el[c~]'
(no output)

Jeff

Re: Symbol's value as variable is void: org-planning-line-re

[Nicolas Goaziou]

Jeff Kowalczyk <jeff.kowalczyk@gmail.com> writes:

> Nicolas Goaziou <mail <at> nicolasgoaziou.fr> writes:
>>
>> Jeff Kowalczyk <jeff.kowalczyk <at> gmail.com> writes:
>> 
>> > Using org-mode a4a1d85 or 2df0785, I see multiple errors, including:
>> >
>> > Using M-q to fill a paragraph, error on the line at point:
>> >
>> >   user-error: An element cannot be parsed line 7149
>> >
>> >   user-error: An element cannot be parsed line 7141
>> >
>> > When using M-RET to insert a heading:
>> >
>> >   byte-code: Symbol's value as variable is void: org-planning-line-re
>> >
>> > When using C-c to update the duration of a clocked time line:
>> >
>> >   byte-code: Symbol's value as variable is void: org-planning-line-re
>> 
>> `org-planning-line-re' is a defconst defined in "org.el". It looks like
>> a mixed installation.
>
> It's possible, how do I confirm?

M-x org-version might tell you.  You can also try to "make autoloads".

Regards,

-- 
Nicolas Goaziou

Re: Symbol's value as variable is void: org-planning-line-re

[Jeff Kowalczyk]

Nicolas Goaziou <mail <at> nicolasgoaziou.fr> writes:
>
> >> `org-planning-line-re' is a defconst defined in "org.el". It looks like
> >> a mixed installation.
> >
> > It's possible, how do I confirm?
> 
> M-x org-version might tell you.  You can also try to "make autoloads".

You are correct, there is a discrepancy in versions:

M-x org-version:

Org-mode version 8.2.6 (release_8.2.6-1 @ ~/.emacs.d/el-get/org-mode/lisp/)

Make output @401bf2:

org-version: 8.3beta (release_8.3beta-310-g38d0eb)

I tried the following, restart-testing each step with no change
in M-x org-version reported version:

- org-mode git pull, make clean && make && make autoloads

- remove el-get .loaddefs.el, restart emacs (which rebuilds .loaddefs)

- el-get update org-mode

For comparison to bundled org version, I am using Emacs bzr upstream:

GNU Emacs 24.4.50.1 (x86_64-pc-linux-gnu, X toolkit) of 2014-09-01

Thanks,
Jeff

Re: Symbol's value as variable is void: org-planning-line-re

[Nick Dokos]

Jeff Kowalczyk <jeff.kowalczyk@gmail.com> writes:

> Nicolas Goaziou <mail <at> nicolasgoaziou.fr> writes:
>>
>> >> `org-planning-line-re' is a defconst defined in "org.el". It looks like
>> >> a mixed installation.
>> >
>> > It's possible, how do I confirm?
>> 
>> M-x org-version might tell you.  You can also try to "make autoloads".
>
> You are correct, there is a discrepancy in versions:
>
> M-x org-version:
>
> Org-mode version 8.2.6 (release_8.2.6-1 @ ~/.emacs.d/el-get/org-mode/lisp/)
>
> Make output @401bf2:
>
> org-version: 8.3beta (release_8.3beta-310-g38d0eb)
>
> I tried the following, restart-testing each step with no change
> in M-x org-version reported version:
>
> - org-mode git pull, make clean && make && make autoloads
>

Strictly speaking, you don't need `make autoloads' here : `make' is
equivalent to `make all' and the `all' target depends on the `autoloads'
target, so just `make' is enough. OTOH, it does not hurt (other than it
duplicates work that is already done).

> - remove el-get .loaddefs.el, restart emacs (which rebuilds .loaddefs)
>
> - el-get update org-mode
>
> For comparison to bundled org version, I am using Emacs bzr upstream:
>
> GNU Emacs 24.4.50.1 (x86_64-pc-linux-gnu, X toolkit) of 2014-09-01
>

Check your load-path. 

--
Nick

Re: Symbol's value as variable is void: org-planning-line-re

[Jeff Kowalczyk]

Nick Dokos <ndokos <at> gmail.com> writes:

> Check your load-path.

Thanks. My load-path seems to put Org from git first. Moving that 
checkout back to 288ffa fixes, newer versions have the problem
behaviors. Am I overlooking something that could still lead to a
mixed Org version?:

("/home/myuser/.emacs.d/el-get/package/elpa/ido-ubiquitous-2.9"
 ...
 "/home/myuser/.emacs.d/el-get/org-mode/lisp"
 "/home/myuser/.emacs.d/el-get/org-mode/contrib/lisp"
 "/home/myuser/.emacs.d/el-get/org-mode"
 ...
 "~/.emacs.d/el-get/"
 "/home/myuser/.emacs.d/el-get/el-get/methods"
 "~/.emacs.d/el-get/el-get"
 "/etc/emacs"
 "/usr/share/emacs/site-lisp"
 "/usr/share/emacs/site-lisp/site-gentoo.d"
 "/usr/share/emacs/24.4.50/lisp"
 ...
 "/usr/share/emacs/24.4.50/lisp/org"
 ...)

Jeff

Re: Symbol's value as variable is void: org-planning-line-re

[Achim Gratz]

Jeff Kowalczyk writes:
> Thanks. My load-path seems to put Org from git first. Moving that 
> checkout back to 288ffa fixes, newer versions have the problem
> behaviors. Am I overlooking something that could still lead to a
> mixed Org version?:

Yes, you may not use anything from Org before the load-path gets set up.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada