mixed orgmode installation

mixed orgmode installation

[Johannes Rainer]

[-- Attachment #1: Type: text/plain, Size: 281 bytes --]

hi all!

is there a "clean" way to disable the built in org from emacs? I'm loading
org mode from git externally, but newer emacs always come with org mode
included.
would just deleting the org folder in the emacs (am using Emacs.app on mac)
installation help?

thanks in advance!

[-- Attachment #2: Type: text/html, Size: 386 bytes --]

Re: mixed orgmode installation

[Thorsten Jolitz]

Johannes Rainer <johannes.rainer@gmail.com> writes:

> hi all!
>
> is there a "clean" way to disable the built in org from emacs? I'm
> loading org mode from git externally, but newer emacs always come with
> org mode included. would just deleting the org folder in the emacs (am
> using Emacs.app on mac) installation help?
>
> thanks in advance!

Using the git version too, I had lots of trouble with mixed installs.
Therefore the first thing I do is deleting the org folder in the emacs
installation, although I have been told on this list this would be a
recipe for desaster (since autoloads will be messed up or so ...). 
But desaster never happened, in fact I did not have any misterious
problems with (multiple) org-mode(s) on my machine anymore since then.

I just replace the installation org-mode folder with a symlink to the
git folder and add a 'subdirs.el' to the git folder, then it works.

-- 
cheers,
Thorsten

Re: mixed orgmode installation

[Johannes Rainer]

[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]

On Wed, Sep 4, 2013 at 4:19 PM, Thorsten Jolitz <tjolitz@gmail.com> wrote:

> Johannes Rainer <johannes.rainer@gmail.com> writes:
>
> > hi all!
> >
> > is there a "clean" way to disable the built in org from emacs? I'm
> > loading org mode from git externally, but newer emacs always come with
> > org mode included. would just deleting the org folder in the emacs (am
> > using Emacs.app on mac) installation help?
> >
> > thanks in advance!
>
> Using the git version too, I had lots of trouble with mixed installs.
> Therefore the first thing I do is deleting the org folder in the emacs
> installation, although I have been told on this list this would be a
> recipe for desaster (since autoloads will be messed up or so ...).
> But desaster never happened, in fact I did not have any misterious
> problems with (multiple) org-mode(s) on my machine anymore since then.
>
> I just replace the installation org-mode folder with a symlink to the
> git folder and add a 'subdirs.el' to the git folder, then it works.
>
> hm, that's an option.
based on your suggestion I created now my own little makefile to install
the git org-mode and directly over-write the one located in
/Applications/Emacs.app/Resources/lisp/org . actually, I first delete all
files in this org directory and install the one from git into the dir again.

thanks!


> --
> cheers,
> Thorsten
>
>
>

[-- Attachment #2: Type: text/html, Size: 2218 bytes --]

Re: mixed orgmode installation

[Suvayu Ali]

On Wed, Sep 04, 2013 at 04:52:34PM +0200, Johannes Rainer wrote:
> hm, that's an option.
> based on your suggestion I created now my own little makefile to install
> the git org-mode and directly over-write the one located in
> /Applications/Emacs.app/Resources/lisp/org . actually, I first delete all
> files in this org directory and install the one from git into the dir again.

This can actually cause difficult to diagnose problems sometimes.  The
simplest way to do it right is to setup your load-path early in your
init file.  To get an idea, you can take a look at my setup.

  <https://github.com/suvayu/.emacs.d/blob/master/init.el>

Look at the first 18 lines; after this I can customise, load, do
whatever I want with org.  You will notice I load a kill-old-org.el.
That line is experimental and optional, and you may skip it.

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

Re: mixed orgmode installation

[Achim Gratz]

Johannes Rainer writes:
> is there a "clean" way to disable the built in org from emacs?

Short answer: no.

> I'm loading org mode from git externally, but newer emacs always come
> with org mode included.

That's not a problem as long as you set up the load-path to point to the
install made via Git before loading Org.  I don't recommend working from
a Git tree directly because it's just too easy to mess up with the
autoloads or have stale byte-compiled files somewhere that you forgot
about.

> would just deleting the org folder in the emacs (am using Emacs.app on
> mac) installation help?

No.  Leave your Emacs installation alone, unless you fancy compiling
your own Emacs.  Install Org into site-lisp, whereever that is on Mac.


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

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: mixed orgmode installation

[adam]

> -----Original Message-----
> From: Suvayu Ali <fatkasuvayu+linux@gmail.com>
> To: emacs-orgmode@gnu.org
> Subject: Re: [O] mixed orgmode installation
> Date: Wed, 4 Sep 2013 17:07:49 +0200
> 
> On Wed, Sep 04, 2013 at 04:52:34PM +0200, Johannes Rainer wrote:
> > hm, that's an option.
> > based on your suggestion I created now my own little makefile to install
> > the git org-mode and directly over-write the one located in
> > /Applications/Emacs.app/Resources/lisp/org . actually, I first delete all
> > files in this org directory and install the one from git into the dir again.
> 
> This can actually cause difficult to diagnose problems sometimes.  The
> simplest way to do it right is to setup your load-path early in your
> init file.  To get an idea, you can take a look at my setup.
> 
>   <https://github.com/suvayu/.emacs.d/blob/master/init.el>
> 
> Look at the first 18 lines; after this I can customise, load, do
> whatever I want with org.  You will notice I load a kill-old-org.el.
> That line is experimental and optional, and you may skip it.
> 
> Hope this helps, 
 
Very interesting thread. 

Being a novice, I grab the tgz snapshot, unarchive into a 
folder, and simply have that folder in the load-path early 
in .emacs. 

I don't  'make && make install'  so perhaps I am missing some 
things as a result. I just leave the old version Emacs-supplied 
Org as-is. 

Re: mixed orgmode installation

[John Hendy]

On Wed, Sep 4, 2013 at 2:20 PM, Achim Gratz <Stromeko@nexgo.de> wrote:
> Johannes Rainer writes:
>> is there a "clean" way to disable the built in org from emacs?
>
> Short answer: no.
>
>> I'm loading org mode from git externally, but newer emacs always come
>> with org mode included.
>
> That's not a problem as long as you set up the load-path to point to the
> install made via Git before loading Org.  I don't recommend working from
> a Git tree directly because it's just too easy to mess up with the
> autoloads or have stale byte-compiled files somewhere that you forgot
> about.
>

Could you elaborate on this? I'd always thought the exact opposite due
to being burned in the past by stale junk littered around /usr/lib,
/usr/bin, /usr/local/[bin/sbin]. Thus, for some things, I prefer to
run them from the git repository since I know where they'll be vs.
where `make install` might desire to put them.

What happens, for example, in this situation:
- git clone
- make && make install
- some file.el gets moved from org.git/contrib/lisp to org.git/lisp in master
- git pull
- make && make install

Are there now two copies of file.el somewhere in the system?

Anyway, if there's more to read on some of your situations, I'd love
to know as I've been doing exactly that and want to stop if it's
recommended against! Thanks for mentioning the potential risk, as I
had no idea!


Best regards,
John


>> would just deleting the org folder in the emacs (am using Emacs.app on
>> mac) installation help?
>
> No.  Leave your Emacs installation alone, unless you fancy compiling
> your own Emacs.  Install Org into site-lisp, whereever that is on Mac.
>
>
> Regards,
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>
> SD adaptation for Waldorf microQ V2.22R2:
> http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
>
>

Re: mixed orgmode installation

[John Hendy]

On Sun, Sep 8, 2013 at 12:40 AM, adam <ahcnz@orcon.net.nz> wrote:
>
>> -----Original Message-----
>> From: Suvayu Ali <fatkasuvayu+linux@gmail.com>
>> To: emacs-orgmode@gnu.org
>> Subject: Re: [O] mixed orgmode installation
>> Date: Wed, 4 Sep 2013 17:07:49 +0200
>>
>> On Wed, Sep 04, 2013 at 04:52:34PM +0200, Johannes Rainer wrote:
>> > hm, that's an option.
>> > based on your suggestion I created now my own little makefile to install
>> > the git org-mode and directly over-write the one located in
>> > /Applications/Emacs.app/Resources/lisp/org . actually, I first delete all
>> > files in this org directory and install the one from git into the dir again.
>>
>> This can actually cause difficult to diagnose problems sometimes.  The
>> simplest way to do it right is to setup your load-path early in your
>> init file.  To get an idea, you can take a look at my setup.
>>
>>   <https://github.com/suvayu/.emacs.d/blob/master/init.el>
>>
>> Look at the first 18 lines; after this I can customise, load, do
>> whatever I want with org.  You will notice I load a kill-old-org.el.
>> That line is experimental and optional, and you may skip it.
>>
>> Hope this helps,
>
> Very interesting thread.
>
> Being a novice, I grab the tgz snapshot, unarchive into a
> folder, and simply have that folder in the load-path early
> in .emacs.
>
> I don't  'make && make install'  so perhaps I am missing some
> things as a result. I just leave the old version Emacs-supplied
> Org as-is.

It might be worth waiting for some others to chime in. While this is
one potential route (make install), I do exactly what you did, and it
works fine as far as I know. I haven't seen a concrete response above
as to what exactly can go wrong -- Achim hinted that it's not trivial
to disable the built-in org, but said it shouldn't matter if one loads
the git org early on (it's the first line in my .emacs), so I'm not
sure if it matters that the built-in org sort of "lives on" beneath
the surface.

On that note, is there a recommended "diagnosis" route someone could
recommend other than simply `M-x org-version`? Is it possible to get,
e.g. 8.0.7, from that command but be pulling from mixed org locations
(org shipped with Emacs, and org from tgz or git)? If so, I was
unaware, so it'd be great to understand how one can do a full
diagnostic.

If not, great, I won't worry about it and I'll view the `make install`
recommendations as more of a housekeeping suggestion vs. a functional
one (risk of mixed install).


Thanks,
John

>
>
>
>
>
>

Re: mixed orgmode installation

[Suvayu Ali]

On Sun, Sep 08, 2013 at 09:37:23AM -0500, John Hendy wrote:
> 
> On that note, is there a recommended "diagnosis" route someone could
> recommend other than simply `M-x org-version`? Is it possible to get,
> e.g. 8.0.7, from that command but be pulling from mixed org locations
> (org shipped with Emacs, and org from tgz or git)? If so, I was
> unaware, so it'd be great to understand how one can do a full
> diagnostic.

When in doubt, Worg is always your friend ;):

  <http://orgmode.org/worg/org-faq.html#mixed-install>

-- 
Suvayu

Open source is the future. It sets us free.

Re: mixed orgmode installation

[John Hendy]

On Sun, Sep 8, 2013 at 10:10 AM, Suvayu Ali <fatkasuvayu+linux@gmail.com> wrote:
> On Sun, Sep 08, 2013 at 09:37:23AM -0500, John Hendy wrote:
>>
>> On that note, is there a recommended "diagnosis" route someone could
>> recommend other than simply `M-x org-version`? Is it possible to get,
>> e.g. 8.0.7, from that command but be pulling from mixed org locations
>> (org shipped with Emacs, and org from tgz or git)? If so, I was
>> unaware, so it'd be great to understand how one can do a full
>> diagnostic.
>
> When in doubt, Worg is always your friend ;):
>
>   <http://orgmode.org/worg/org-faq.html#mixed-install>

I take it I'm a bad friend, as I apparently forget about that one
constantly with this list :)

So... from that page, here are my tools:
- `M-x org-version` : if that lists what you think it should via your
git or snapshot... so far so good

- If `M-x list-load-path-shadows` looks like...???... then you're
good. I'm assuming it should look like this:

#+begin_src list-load-path-shadows

~/.elisp/org.git/lisp/ob-latex hides /usr/share/emacs/24.3/lisp/org/ob-latex
~/.elisp/org.git/lisp/ob-scala hides /usr/share/emacs/24.3/lisp/org/ob-scala
~/.elisp/org.git/lisp/org-src hides /usr/share/emacs/24.3/lisp/org/org-src
~/.elisp/org.git/lisp/ob-java hides /usr/share/emacs/24.3/lisp/org/ob-java

[...]

94 Emacs Lisp load-path shadowings were found

#+end_src

I'm not sure how many there should be, but they all come from from my
git repo and shadow something in my emacs installation. That still
leaves two possibly redundant questions:

- How do I find out what's *not* shadowed?
- How do I find out how many Lisp load-path shadowings there *should
be* with a correct, non-mixed installation?

Then again, is Worg saying that if `M-x org-version` outputs the
"correct" answer... we're all set and there's nothing to worry about?
In other words, it won't output the correct, git-pointing,
version/path unless *everything* provided by the built-in Org has been
replaced by the snapshot/git version?


Thanks,
John

>
> --
> Suvayu
>
> Open source is the future. It sets us free.

Re: mixed orgmode installation

[Achim Gratz]

John Hendy writes:
> Could you elaborate on this? I'd always thought the exact opposite due
> to being burned in the past by stale junk littered around /usr/lib,
> /usr/bin, /usr/local/[bin/sbin]. Thus, for some things, I prefer to
> run them from the git repository since I know where they'll be vs.
> where `make install` might desire to put them.

Git provides and manages the source tree and nothing else.  To get a
reliable Org you need a self-consistent and complete installation — that
is usually provided by the build system.

http://orgmode.org/worg/dev/org-build-system.html

The most logical place for that Org installation is site-lisp (since
then load-path is already set up correctly), but you can install almost
anywhere as long as you know where load-path is pointing to at all
times.  You could then have multiple versions of Org installed and use
them for different instances or versiosn of Emacs (one at a time,
obviously).

> What happens, for example, in this situation:
> - git clone
> - make && make install

You just need to "make install" and it's been that way for over two
years now…

> - some file.el gets moved from org.git/contrib/lisp to org.git/lisp in master
> - git pull
> - make && make install

And this is what "make up2" is doing, plus testing so the install won't
be attempted if the tests don't pass.

> Are there now two copies of file.el somewhere in the system?

No, unless you've changed the install location inbetween.  If a file
would be removed (or renamed), then you'd need to first issue a "make
clean-install" to make sure it is really gone from your installation.

> Anyway, if there's more to read on some of your situations, I'd love
> to know as I've been doing exactly that and want to stop if it's
> recommended against! Thanks for mentioning the potential risk, as I
> had no idea!

I'm not exactly sure what problem you are talking about, maybe you could
clarify.  In any case it seems there's been a mixup of different problems
in this thread.


Regards,
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

Re: mixed orgmode installation

[Achim Gratz]

John Hendy writes:
> Then again, is Worg saying that if `M-x org-version` outputs the
> "correct" answer... we're all set and there's nothing to worry about?

The output of org-version is determined essentially by checking for two
files from the installation and comparing where they would be loaded
from.  This catches the most common problems, but certainly not all.  In
particular, it won't see when the load-path has been changed after some
parts of Org have already been loaded from someplace else (but
org-reload will give a warning for this case).


Regards,
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

Re: mixed orgmode installation

[John Hendy]

On Sun, Sep 8, 2013 at 11:41 AM, Achim Gratz <Stromeko@nexgo.de> wrote:
> John Hendy writes:
>> Could you elaborate on this? I'd always thought the exact opposite due
>> to being burned in the past by stale junk littered around /usr/lib,
>> /usr/bin, /usr/local/[bin/sbin]. Thus, for some things, I prefer to
>> run them from the git repository since I know where they'll be vs.
>> where `make install` might desire to put them.
>
> Git provides and manages the source tree and nothing else.  To get a
> reliable Org you need a self-consistent and complete installation — that
> is usually provided by the build system.
>

I'm with you so far. But if all of Org lives in /path/to/org.git/lisp,
what's to go wrong if it's there vs. /system/path/site-lisp?

> http://orgmode.org/worg/dev/org-build-system.html
>
> The most logical place for that Org installation is site-lisp (since
> then load-path is already set up correctly), but you can install almost
> anywhere as long as you know where load-path is pointing to at all
> times.  You could then have multiple versions of Org installed and use
> them for different instances or versiosn of Emacs (one at a time,
> obviously).
>
>> What happens, for example, in this situation:
>> - git clone
>> - make && make install
>
> You just need to "make install" and it's been that way for over two
> years now…
>

Sorry, I never do make install, so that was an oversight.

>> - some file.el gets moved from org.git/contrib/lisp to org.git/lisp in master
>> - git pull
>> - make && make install
>
> And this is what "make up2" is doing, plus testing so the install won't
> be attempted if the tests don't pass.
>
>> Are there now two copies of file.el somewhere in the system?
>
> No, unless you've changed the install location inbetween.  If a file
> would be removed (or renamed), then you'd need to first issue a "make
> clean-install" to make sure it is really gone from your installation.
>

I'm not sure I follow this one. Does `make up2` look for changed paths
(contrib/lisp vs lisp/) since the last `make up2` ? If not, how would
I know to do `make clean-install` vs. just `make install`?

>> Anyway, if there's more to read on some of your situations, I'd love
>> to know as I've been doing exactly that and want to stop if it's
>> recommended against! Thanks for mentioning the potential risk, as I
>> had no idea!
>
> I'm not exactly sure what problem you are talking about, maybe you could
> clarify.  In any case it seems there's been a mixup of different problems
> in this thread.

I'm talking about your original comment that running out of a git repo
can lead to:
- it being just to easy to mess up with the autoloads
- have stale byte-compiled files I forgot about somewhere


John

P.S. And yes, I derailed from the mixed install case due to your
comment as I thought it was worth looking into. I'm doing what you
advise against and I wanted to know the risks and more details about
what I might run into.

>
>
> Regards,
> 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
>
>

Re: mixed orgmode installation

[Achim Gratz]

John Hendy writes:
> I'm with you so far. But if all of Org lives in /path/to/org.git/lisp,
> what's to go wrong if it's there vs. /system/path/site-lisp?

It is only "there" when you've built Org and whenever you do something
in Git, it's "gone", only that you might not see that.  Having Org
installed in some other place decouples it from what you do in the work
tree.  That makes it less likely that you load up an Emacs session, do
something in Org, then do something in Git and then go back to sour
Emacs session and load some other parts of Org that won't fit with the
version you've started with.

> I'm not sure I follow this one. Does `make up2` look for changed paths
> (contrib/lisp vs lisp/) since the last `make up2` ? If not, how would
> I know to do `make clean-install` vs. just `make install`?

You should know if you changed something, I suppose.

> I'm talking about your original comment that running out of a git repo
> can lead to:
> - it being just to easy to mess up with the autoloads

Yes, if you forget to re-make them after a change to the source code.

> - have stale byte-compiled files I forgot about somewhere

Yes, because Emacs prefers the byte-compiled files over the sources,
even when it knows the sources are newer.  So when you update from Git,
but don't byte-compile, you will load an older version of Org rather
than the one you think you are using.  If you are running from a Git
tree, you should always keep Org uncompiled for this reason (that's why
that make target exists).

> P.S. And yes, I derailed from the mixed install case due to your
> comment as I thought it was worth looking into. I'm doing what you
> advise against and I wanted to know the risks and more details about
> what I might run into.

You can do whatever you want as long as you can deal with the resulting
problems.  Depending on how careful you are you may never encounter one,
but the most frequent reasons for mixed installs are forgetting to
generate the autoload files or using an init sequence that loads Org
from two different places.


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

Re: mixed orgmode installation

[Justin Gordon]

Achim Gratz <Stromeko <at> nexgo.de> writes:

> 
> John Hendy writes:
> > Then again, is Worg saying that if `M-x org-version` outputs the
> > "correct" answer... we're all set and there's nothing to worry about?
> 
> The output of org-version is determined essentially by checking for two
> files from the installation and comparing where they would be loaded
> from.  This catches the most common problems, but certainly not all.  In
> particular, it won't see when the load-path has been changed after some
> parts of Org have already been loaded from someplace else (but
> org-reload will give a warning for this case).
> 
> Regards,
> Achim.


If I byte compile a file, I get this message:
In org-jekyll-publish-to-html:
ox-jekyll.el:280:4:Warning: org-publish-org-to called with 5 arguments, but
    accepts only 4

This is because my installation is pointing to the emacs default version rather 
than my version  from git. If I do C-h f and look up this function, I get pointed
to the emacs default version.

However, if I do org-version, I get the proper new version.

However, if I do list-load-path-shadows, I can verify that org-publish is not 
shadowed, and that's probably due to the fact that the new file is called 
ox-publish.

How do I fix this???


I've tried  

Re: mixed orgmode installation

[Sharon Kimble]

[-- Attachment #1: Type: text/plain, Size: 2082 bytes --]

On Thu, 2 Jan 2014 08:06:46 +0000 (UTC)
Justin Gordon <justin.gordon@gmail.com> wrote:

> Achim Gratz <Stromeko <at> nexgo.de> writes:
> 
> > 
> > John Hendy writes:
> > > Then again, is Worg saying that if `M-x org-version` outputs the
> > > "correct" answer... we're all set and there's nothing to worry
> > > about?
> > 
> > The output of org-version is determined essentially by checking for
> > two files from the installation and comparing where they would be
> > loaded from.  This catches the most common problems, but certainly
> > not all.  In particular, it won't see when the load-path has been
> > changed after some parts of Org have already been loaded from
> > someplace else (but org-reload will give a warning for this case).
> > 
> > Regards,
> > Achim.
> 
> 
> If I byte compile a file, I get this message:
> In org-jekyll-publish-to-html:
> ox-jekyll.el:280:4:Warning: org-publish-org-to called with 5
> arguments, but accepts only 4
> 
> This is because my installation is pointing to the emacs default
> version rather than my version  from git. If I do C-h f and look up
> this function, I get pointed to the emacs default version.
> 
> However, if I do org-version, I get the proper new version.
> 
> However, if I do list-load-path-shadows, I can verify that
> org-publish is not shadowed, and that's probably due to the fact that
> the new file is called ox-publish.
> 
> How do I fix this???
> 
> 
> I've tried  

You’ve tried what? You seem to have cut off in mid-sentence. 

I had the same problem on debian testing which I resolved by removing
the debian version and going solely with the one from ELPA, in your
case from git. I'm pretty sure that the git version will be more
up-to-date than your distro version! :)

Sharon.
-- 
A taste of linux = http://www.sharons.org.uk
efever = http://www.efever.blogspot.com/
efever = http://sharon04.livejournal.com/
my git repo = https://bitbucket.org/boudiccas/dots
Debian testing, Fluxbox 1.3.5, LibreOffice 4.1.4.2
Registered Linux user 561944

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: mixed orgmode installation

[Justin Gordon]

[-- Attachment #1: Type: text/plain, Size: 2774 bytes --]

My problem was because I had a line

    (require 'org-publish)

It would be super if there was a way to clearly flag this as an error after
an upgrade. Maybe renamed files should have old skeleton files that produce
an error indicating the new file name?



On Thu, Jan 2, 2014 at 10:43 PM, Sharon Kimble <boudiccas@talktalk.net>wrote:

> On Thu, 2 Jan 2014 08:06:46 +0000 (UTC)
> Justin Gordon <justin.gordon@gmail.com> wrote:
>
> > Achim Gratz <Stromeko <at> nexgo.de> writes:
> >
> > >
> > > John Hendy writes:
> > > > Then again, is Worg saying that if `M-x org-version` outputs the
> > > > "correct" answer... we're all set and there's nothing to worry
> > > > about?
> > >
> > > The output of org-version is determined essentially by checking for
> > > two files from the installation and comparing where they would be
> > > loaded from.  This catches the most common problems, but certainly
> > > not all.  In particular, it won't see when the load-path has been
> > > changed after some parts of Org have already been loaded from
> > > someplace else (but org-reload will give a warning for this case).
> > >
> > > Regards,
> > > Achim.
> >
> >
> > If I byte compile a file, I get this message:
> > In org-jekyll-publish-to-html:
> > ox-jekyll.el:280:4:Warning: org-publish-org-to called with 5
> > arguments, but accepts only 4
> >
> > This is because my installation is pointing to the emacs default
> > version rather than my version  from git. If I do C-h f and look up
> > this function, I get pointed to the emacs default version.
> >
> > However, if I do org-version, I get the proper new version.
> >
> > However, if I do list-load-path-shadows, I can verify that
> > org-publish is not shadowed, and that's probably due to the fact that
> > the new file is called ox-publish.
> >
> > How do I fix this???
> >
> >
> > I've tried
>
> You’ve tried what? You seem to have cut off in mid-sentence.
>
> I had the same problem on debian testing which I resolved by removing
> the debian version and going solely with the one from ELPA, in your
> case from git. I'm pretty sure that the git version will be more
> up-to-date than your distro version! :)
>
> Sharon.
> --
> A taste of linux = http://www.sharons.org.uk
> efever = http://www.efever.blogspot.com/
> efever = http://sharon04.livejournal.com/
> my git repo = https://bitbucket.org/boudiccas/dots
> Debian testing, Fluxbox 1.3.5, LibreOffice 4.1.4.2
> Registered Linux user 561944
>



-- 
Justin Gordon | 808-877-6461 | m: 808-281-7272
www.railsonmaui.com | twitter: @railsonmaui<https://twitter.com/railsonmaui>
 | sugarranchmaui.com <http://www.sugarranchmaui.com/> | Sugar Ranch
Blog<https://www.facebook.com/SugarRanch>

[-- Attachment #2: Type: text/html, Size: 4577 bytes --]

Re: mixed orgmode installation

[John Hendy]

On Thu, Jan 2, 2014 at 2:06 AM, Justin Gordon <justin.gordon@gmail.com> wrote:
> Achim Gratz <Stromeko <at> nexgo.de> writes:
>
>>
>> John Hendy writes:
>> > Then again, is Worg saying that if `M-x org-version` outputs the
>> > "correct" answer... we're all set and there's nothing to worry about?
>>
>> The output of org-version is determined essentially by checking for two
>> files from the installation and comparing where they would be loaded
>> from.  This catches the most common problems, but certainly not all.  In
>> particular, it won't see when the load-path has been changed after some
>> parts of Org have already been loaded from someplace else (but
>> org-reload will give a warning for this case).
>>
>> Regards,
>> Achim.
>
>
> If I byte compile a file, I get this message:
> In org-jekyll-publish-to-html:
> ox-jekyll.el:280:4:Warning: org-publish-org-to called with 5 arguments, but
>     accepts only 4
>
> This is because my installation is pointing to the emacs default version rather
> than my version  from git. If I do C-h f and look up this function, I get pointed
> to the emacs default version.

I had this issue on Windows the other day and had a draft composed
asking for help before I realized it was my own issue. I got all kinds
of errors like that when I was trying to byte compile via the "Compile
without make tools" section on Worg [1]. Turned out I had my load-path
pointed to the wrong location after I wiped the old git repo and just
cloned a new one in what I thought was a "better/saner" location,
forgetting to update .emacs after doing so.

It might help if you could respond with the following information
(with my example answers provided):

1) how did you download Org and where is the directory located?
- I did `git clone http://orgmode.org/org-mode.git`
- The dir is at /home/jwhendy/.emacs.d/org.git

2) Please post a minimal emacs config you're trying to use

#+begin_src emacs-min

(add-to-list 'load-path "~/.emacs.d/org.git/lisp")
(add-to-list 'load-path "~/.emacs.d/org.git/contrib/lisp")
(add-to-list 'load-path "~/.emacs.d/ess-13.05/lisp")
(add-to-list 'load-path "~/.emacs.d/site-lisp")

#+end_src

3) What happens when you start emacs with `emacs -Q` from
terminal/cmd, then run `M-x load-file` and enter the path to your
minimal config from above, and then:
- `M-x org-version`:
"Org-mode version 8.2.4 (8.2.4-fake @
c:/Users/a1rwhzz/AppData/Roaming/.emacs.d/org.git/lisp/)"

- `M-x org-reload`:
"Successfully reloaded Org
Org-mode version 8.2.4 (8.2.4-fake @
c:/Users/a1rwhzz/AppData/Roaming/.emacs.d/org.git/lisp/)"

There might be other pertinent questions, but those are what's coming
to mind for me right now. Perhaps your emacs version?

>
> However, if I do org-version, I get the proper new version.
>
> However, if I do list-load-path-shadows, I can verify that org-publish is not
> shadowed, and that's probably due to the fact that the new file is called
> ox-publish.
>

I agree it sounds like you have something mixed going on.

One other possibility... see this thread from when the new exporter
was first being pushed out with Org 8.0:
- http://lists.gnu.org/archive/html/emacs-orgmode/2013-05/msg00333.html

There are two ways to load backends, which are both listed clearly in
the documentation. During my own setup, however, what I did *not* find
anywhere in the documentation is how their treatment affects things
available in the environment. For example, since adding the backend to
the variable org-export-backends doesn't load it until you actually
use it... the help for the variables (or at least auto-completing)
also isn't available. I ran into this using method 1 originally, then
wanting to customize a variable related to, say, ox-odt or other, and
Org not finding anything when I did `M-x help RET v RET org-odt-TAB`.

Not sure that's what's going on at all, but it might be worth showing
us how you are bringing backends in to Org as well. Someone else would
know better, but I'm wondering if by chance it could be possible not
to have loaded ox-publish (since you haven't published yet), for Org
not to find it, and then to resort to searching in the Emacs-bundled
Org instead? Far-fetched, but came to mind.


[1] http://orgmode.org/worg/org-hacks.html#compiling-org-without-make

Best regards,
John

> How do I fix this???
>
>
> I've tried
>
>