[-- Attachment #1: Type: text/plain, Size: 1053 bytes --] Since updating to org 7.9, I've had an odd problem with another package that depends on org-mode (org-toodledo). It reports that it can't find org-version. I did have org installed via git, but I decided, given that I'm running emacs24, to change over to the elpa install to see if that made any difference. It didn't. The following work-around patches the problem, but I was wondering how to "really" solve it: (require 'org-version) (setq org-version (org-release)) -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dr Benjamin Slade [ http://ling.uta.edu/~ben/ ] Dept. of Linguistics & TESOL - University of Texas at Arlington 132E Hammond Hall | Office Hours: tba ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {sent by [[http://www.djcbsoftware.nl/code/mu/index.html][mu4e]] on [[http://www.gnu.org/software/emacs][Emacs]] running under [[http://www.gnu.org/][GNU]]/[[http://www.linuxfoundation.org/][Linux]]} [-- Attachment #2.1: Type: text/html, Size: 1252 bytes --]
Da: Benjamin Slade <slade@jnanam.net> Inviato: Lunedì 3 Settembre 2012 5:46 > Since updating to org 7.9, I've had an odd problem with another package that depends on org-mode (org-toodledo). > It reports that it can't find org-version. So the problem is in org-toodledo. Did you ask its maintainer? > The following work-around patches the problem, > (require 'org-version) > (setq org-version (org-release)) > but I was wondering how to "really" solve it: hack org-toodledo. cheers, Giovanni
On Mon, Sep 03, 2012 at 08:23:54AM +0100, Giovanni Ridolfi wrote:
> Da: Benjamin Slade <slade@jnanam.net>
>
> Inviato: Lunedì 3 Settembre 2012 5:46
>
> > Since updating to org 7.9, I've had an odd problem with another package that depends on org-mode (org-toodledo).
>
> > It reports that it can't find org-version.
>
> So the problem is in org-toodledo. Did you ask its maintainer?
>
Not necessarily. The question is what does the OP see when he calls
M-x org-version. Is the version reported correctly? If an interactive
call to org-version returns the correct results then, we could conclude
the problem is in org-toodledoo.
I however strongly suspect the problem might be a mixed installation.
It would be worthwhile if the OP goes through the elpa version of org by
hand and ensures there is nothing left over.
--
Suvayu
Open source is the future. It sets us free.
[-- Attachment #1: Type: text/plain, Size: 1667 bytes --] I did indeed start up by asking the org-toodledo maintainer. He suggested that it must be something funny in my org-setup (and pointed to previous issues like http://thread.gmane.org/gmane.emacs.orgmode/59337 and http://comments.gmane.org/gmane.emacs.orgmode/55412 - but neither of those seems to be my problem), so I thought I'd ask here. The work-around I mentioned seems to work perfectly well, I was just worried that there was some underlying problem in my setup that might cause additional problems at some point. Giovanni Ridolfi writes: > Da: Benjamin Slade <slade@jnanam.net> > > Inviato: Lunedì 3 Settembre 2012 5:46 > >> Since updating to org 7.9, I've had an odd problem with another package that depends on org-mode (org-toodledo). > >> It reports that it can't find org-version. > > So the problem is in org-toodledo. Did you ask its maintainer? > > >> The following work-around patches the problem, > > >> (require 'org-version) >> (setq org-version (org-release)) > >> but I was wondering how to "really" solve it: > > hack org-toodledo. > > cheers, > Giovanni -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dr Benjamin Slade [ http://ling.uta.edu/~ben/ ] Dept. of Linguistics & TESOL - University of Texas at Arlington 132E Hammond Hall | Office Hours: tba ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {sent by [[http://www.djcbsoftware.nl/code/mu/index.html][mu4e]] on [[http://www.gnu.org/software/emacs][Emacs]] running under [[http://www.gnu.org/][GNU]]/[[http://www.linuxfoundation.org/][Linux]]} [-- Attachment #2.1: Type: text/html, Size: 2212 bytes --]
I'm the maintainer of the org-toodledo and the OP did indeed contact me first. org-toodledo effectively does: (require 'org) Then uses the variable org-version. This has worked just fine for a few years, but when the OP upgraded to 7.9, the org-toodledo function that checks the org-version yields an error along the lines of variable not defined. I did some googling and came across these threads which seemed relevant: http://thread.gmane.org/gmane.emacs.orgmode/59337 http://comments.gmane.org/gmane.emacs.orgmode/55412 It seems wrong to me that hacking org-toodledo is the appropriate solution. As mentioned in one of the above threads, the version of a package is pretty fundamental and I'd expect it to be provided by the base require. ...cj On 9/3/12 12:23 AM, Giovanni Ridolfi wrote: > Da: Benjamin Slade <slade@jnanam.net> >> Since updating to org 7.9, I've had an odd problem with another package that depends on org-mode (org-toodledo). >> It reports that it can't find org-version. > > So the problem is in org-toodledo. Did you ask its maintainer?
On 9/3/12 12:23 AM, Giovanni Ridolfi wrote: >> Da: Benjamin Slade <slade@jnanam.net> >>> Since updating to org 7.9, I've had an odd problem with another package that depends on org-mode (org-toodledo). >>> It reports that it can't find org-version. >> >> So the problem is in org-toodledo. Did you ask its maintainer? > Da: Christopher J. White <orgmode@grierwhite.com> > Inviato: Lunedì 3 Settembre 2012 16:48 > I'm the maintainer of the org-toodledo and the OP did indeed contact me first. Hi, Christopher, > org-toodledo effectively does: > (require 'org) > Then uses the variable org-version. > This has worked just fine for a few years, but ... but since few months the place where org-version is defined has changed from org.el to org-version.el that is generated during compilation IIRC (!) If I'm wrong Achim Gratz will correct me. > when the OP upgraded to 7.9, the org-toodledo function that checks > the org-version yields an error along the lines of variable not defined. > I did some googling and came across these threads which seemed relevant: > http://thread.gmane.org/gmane.emacs.orgmode/59337 (august 2012) > http://comments.gmane.org/gmane.emacs.orgmode/55412 (april 2012, really old thread) > It seems wrong to me that hacking org-toodledo is the appropriate solution. I disagree. Would you please try to add (require 'org-install) instead of (require 'org) and see if org-toodledo works? > As mentioned in one of the above threads, the version of a package is pretty fundamental > and I'd expect it to be provided by the base require. The variable org-version *is indeed provided* but not in the file your code expects it. cheers, Giovanni
Hi Giovanni, On Tue, Sep 04, 2012 at 12:14:43PM +0100, Giovanni Ridolfi wrote: > > > org-toodledo effectively does: > > (require 'org) > > Then uses the variable org-version. > > This has worked just fine for a few years, but > > ... but since few months the place where org-version is defined has changed > from org.el > to org-version.el > that is generated during compilation IIRC (!) If I'm wrong Achim Gratz will correct me. > I think the change you mention above is transparent to both the end-user and thrid-party packages. It should be immaterial here. Of course Achim should correct me if I'm wrong. :) > > It seems wrong to me that hacking org-toodledo is the appropriate solution. > I disagree. > > Would you please try to add (require 'org-install) instead of (require > 'org) and see if org-toodledo works? > The (require 'org-install) bit is supposed to be user code, specific for each installation; it is highly dependent on the load-path. IMO, the problem here is the OP[1] has a mixed installation and neither org or org-toodledo needs any fix. There are many discussions about mixed installations in the archive and Worg. It would be worthwhile if the OP went through this one in particular: <http://orgmode.org/worg/org-faq.html#mixed-install>. Hope this helps, Cheers, PS: I wish there was a canonical way to diagnose mixed installs. :-| Footnotes: [1] I forgot who it was, sorry. -- Suvayu Open source is the future. It sets us free.
Giovanni Ridolfi <giovanni.ridolfi@yahoo.it> wrote:
> Would you please try to add (require 'org-install) instead of (require 'org) and see if org-toodledo works?
>
> > As mentioned in one of the above threads, the version of a package is pretty fundamental
> > and I'd expect it to be provided by the base require.
>
> The variable org-version *is indeed provided* but not in the file your code expects it.
>
>
Is it? I can only find a function named org-version, not a variable.
Nick
Da: Nick Dokos <nicholas.dokos@hp.com>
Inviato: Martedì 4 Settembre 2012 14:04
> Giovanni Ridolfi <giovanni.ridolfi@yahoo.it> wrote:
>> Would you please try to add (require 'org-install) instead of (require 'org) and see if org-toodledo works?
>>
>> > As mentioned in one of the above threads, the version of a package is pretty fundamental
>> > and I'd expect it to be provided by the base require.
> >
>> The variable org-version *is indeed provided* but not in the file your code expects it.
>>
> Is it? I can only find a function named org-version, not a variable.
Hi, Nick,
you're right, therfore, obviously ;-) I was wrong.
The function is org-version and it gets its arguments from the variables
org-release
and
org-git-version
defined in the file lisp/org-version.el
thanks for pointing it up.
cheers,
Giovanni
So in version 7.8 and earlier, org-version is both a variable and a
function. The function is not useful to coders because it displays the
version string as a message:
(org-version)
"Org-mode version 7.8.03 (release_7.8.03.437.g60ca.dirty)"
org-version
"7.8.03"
I used org-version as a variable because there was an incompatibility
between 7.7 and 7.8 for the function org-export-remove-or-extract-drawers.
So, what is the proper way to get the version number in 7.9? It seems
awkward to me that all clients would have to require something other
than just "org" to get the version number, but I can live with that.
What I don't want to do, though, is mess around with testing for the
existence of various functions and variables just to figure out where to
get the version number from.
Why not just keep the variable org-version around just like in 7.8 and
earlier?
Otherwise, can someone please post a code snippet that gets me the
version string "7.8.03" that will work with 7.7, 7.8 and 7.9?
...cj
On 9/4/12 6:13 AM, Giovanni Ridolfi wrote:
> Da: Nick Dokos <nicholas.dokos@hp.com>
>
> Inviato: Martedì 4 Settembre 2012 14:04
>
>> Giovanni Ridolfi <giovanni.ridolfi@yahoo.it> wrote:
>>> Would you please try to add (require 'org-install) instead of (require 'org) and see if org-toodledo works?
>>>
>>>> As mentioned in one of the above threads, the version of a package is pretty fundamental
>>>> and I'd expect it to be provided by the base require.
>>>
>>> The variable org-version *is indeed provided* but not in the file your code expects it.
>>>
>> Is it? I can only find a function named org-version, not a variable.
>
> Hi, Nick,
>
> you're right, therfore, obviously ;-) I was wrong.
>
> The function is org-version and it gets its arguments from the variables
> org-release
> and
> org-git-version
> defined in the file lisp/org-version.el
>
> thanks for pointing it up.
>
> cheers,
> Giovanni
>
>
>
Christopher J. White <orgmode@grierwhite.com> wrote: > So in version 7.8 and earlier, org-version is both a variable and a > function. The function is not useful to coders because it displays > the version string as a message: > Not so: there are three optional arguments - if the last one is nil (or not provided), no message is printed in the echo area. The others control whether to insert the string at point and whether to use the abbreviated version or the full git version. So just add one of the following at the beginning of org-toodledo and you should be set: (setq org-version (org-version)) or (setq org-version (org-version nil t)) depending on what string you want. Nick > (org-version) > "Org-mode version 7.8.03 (release_7.8.03.437.g60ca.dirty)" > > org-version > "7.8.03" > > I used org-version as a variable because there was an incompatibility > between 7.7 and 7.8 for the function > org-export-remove-or-extract-drawers. > > So, what is the proper way to get the version number in 7.9? It seems > awkward to me that all clients would have to require something other > than just "org" to get the version number, but I can live with that. > > What I don't want to do, though, is mess around with testing for the > existence of various functions and variables just to figure out where > to get the version number from. > > Why not just keep the variable org-version around just like in 7.8 and > earlier? > > Otherwise, can someone please post a code snippet that gets me the > version string "7.8.03" that will work with 7.7, 7.8 and 7.9? > > ...cj > > On 9/4/12 6:13 AM, Giovanni Ridolfi wrote: > > Da: Nick Dokos <nicholas.dokos@hp.com> > > > > Inviato: Martedì 4 Settembre 2012 14:04 > > > >> Giovanni Ridolfi <giovanni.ridolfi@yahoo.it> wrote: > >>> Would you please try to add (require 'org-install) instead of (require 'org) and see if org-toodledo works? > >>> > >>>> As mentioned in one of the above threads, the version of a package is pretty fundamental > >>>> and I'd expect it to be provided by the base require. > >>> > >>> The variable org-version *is indeed provided* but not in the file your code expects it. > >>> > >> Is it? I can only find a function named org-version, not a variable. > > > > Hi, Nick, > > > > you're right, therfore, obviously ;-) I was wrong. > > > > The function is org-version and it gets its arguments from the variables > > org-release > > and > > org-git-version > > defined in the file lisp/org-version.el > > > > thanks for pointing it up. > > > > cheers, > > Giovanni > > > > > > >
Christopher J. White <orgmode@grierwhite.com> wrote: > So in version 7.8 and earlier, org-version is both a variable and a > function. The function is not useful to coders because it displays > the version string as a message: > > (org-version) > "Org-mode version 7.8.03 (release_7.8.03.437.g60ca.dirty)" > > org-version > "7.8.03" > > I used org-version as a variable because there was an incompatibility > between 7.7 and 7.8 for the function > org-export-remove-or-extract-drawers. > > So, what is the proper way to get the version number in 7.9? It seems > awkward to me that all clients would have to require something other > than just "org" to get the version number, but I can live with that. > > What I don't want to do, though, is mess around with testing for the > existence of various functions and variables just to figure out where > to get the version number from. > Disregard my previous email: in 7.7 (and maybe 7.8), org-version (the function) does not return a simple "7.7". Here is a snippet of code that works in those two and in 7.9.1 as well: (setq version (if (boundp 'org-version) org-version (org-version)) It does not meet your requirements in the last paragraph above, but it's not too bad. I just hope that I haven't missed anything this time. Nick > Why not just keep the variable org-version around just like in 7.8 and > earlier? > > Otherwise, can someone please post a code snippet that gets me the > version string "7.8.03" that will work with 7.7, 7.8 and 7.9? > > ...cj > > On 9/4/12 6:13 AM, Giovanni Ridolfi wrote: > > Da: Nick Dokos <nicholas.dokos@hp.com> > > > > Inviato: Martedì 4 Settembre 2012 14:04 > > > >> Giovanni Ridolfi <giovanni.ridolfi@yahoo.it> wrote: > >>> Would you please try to add (require 'org-install) instead of (require 'org) and see if org-toodledo works? > >>> > >>>> As mentioned in one of the above threads, the version of a package is pretty fundamental > >>>> and I'd expect it to be provided by the base require. > >>> > >>> The variable org-version *is indeed provided* but not in the file your code expects it. > >>> > >> Is it? I can only find a function named org-version, not a variable. > > > > Hi, Nick, > > > > you're right, therfore, obviously ;-) I was wrong. > > > > The function is org-version and it gets its arguments from the variables > > org-release > > and > > org-git-version > > defined in the file lisp/org-version.el > > > > thanks for pointing it up. > > > > cheers, > > Giovanni > > > > > > >
Hi Nick,
On 9/4/12 10:15 AM, Nick Dokos wrote:
> Here is a snippet of code that works in those two and in 7.9.1 as well:
>
> (setq version (if (boundp 'org-version)
> org-version
> (org-version))
>
Thanks -- I do not have a copy of 7.9 available, so wasn't sure what
parameters to call.
I can certainly add this to org-toodledo.el, but I guess I fail to
understand why it was changed in the first place. The above solution
means that every package out there that is dependent on org and needs to
look up the version needs to change to work with 7.9 If org simply kept
the org-version as a variable, there would be no need for this.
If 7.9 is still an early release, I'd suggest adding the org-version
variable back to org so as not to break other packages that may also
depend the version string.
...cj
Benjamin Slade writes: > Since updating to org 7.9, I've had an odd problem with another > package that depends on org-mode (org-toodledo). It reports that it > can't find org-version. I did have org installed via git, but I > decided, given that I'm running emacs24, to change over to the elpa > install to see if that made any difference. It didn't. > > The following work-around patches the problem, but I was wondering how > to "really" solve it: > > > (require 'org-version) > (setq org-version (org-release)) The variable org-version was an internal one that has been removed. The org-toodledo package should not rely on internal variables, but rather use the official interface, in this case the function org-version. HTH, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Christopher J. White writes: > If 7.9 is still an early release, I'd suggest adding the org-version > variable back to org so as not to break other packages that may also > depend the version string. Your use of the variable org-version was completely unnecessary, so this is a non-issue. I've just answered your mail that you apparently sent off-list to me. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
As this is the standard way of checking against a package's version, and now that (org-version) does the right thing, I reintroduced the constant `org-version'. -- Bastien
Achim Gratz <Stromeko@nexgo.de> writes:
> The variable org-version was an internal one that has been removed. The
> org-toodledo package should not rely on internal variables, but rather
> use the official interface, in this case the function org-version.
In the real world, developers rely on a set of stable expectations.
Being able to check against `org-version' as a *variable* is one of
them, and a very stable one. IMO, it is counter-productive to deceive
this expectation and to ask developers to read org.el to know how they
can check against Org's version.
The way `org-version' is set internally is another topic, and I'm glad
you finally come up with something that relies only on make/git. But
geee... this has been a long and painful way to go, and I don't count
how many users are/were confused about this.
The original motivation for this was to spare the maintainer the sweat
of possible merge conflicts when syncing with Emacs... which were just
very unlikly to happen anyway.
So, let's focus more on the users, and less on conceptual purity.
--
Bastien
Bastien writes: > As this is the standard way of checking against a package's version, and > now that (org-version) does the right thing, I reintroduced the constant > `org-version'. You have tested you always get the correct result with Emacs 23 and 24, XEmacs 21.5, with and without compilation, with and without generated autoloads and org-version and with and without load-path shadowings both from Emacs' built-in Org and version installed by the user and via ELPA, both after requiring just 'org and 'org-install, right? 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
Bastien writes: > As this is the standard way of checking against a package's version, and > now that (org-version) does the right thing, I reintroduced the constant > `org-version'. You might want to fix this in maint (not master), BTW. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Achim Gratz <Stromeko@nexgo.de> writes:
> Bastien writes:
>> As this is the standard way of checking against a package's version, and
>> now that (org-version) does the right thing, I reintroduced the constant
>> `org-version'.
>
> You might want to fix this in maint (not master), BTW.
Yes, this is what I did.
--
Bastien