[BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Eric Schulte]

Hi,

Recently my Emacs start up fails when I (require 'org) because the
function `org-load-noerror-mustsuffix' is undefined.  I was able to fix
this by checking out the version previous to commit 5484a33b [1].

Best,

Footnotes: 
[1]  commit 5484a33b8d1382958095922bc9bc2bd6f1d9ffc6
Author: Achim Gratz <Stromeko@Stromeko.DE>
Date:   Sun Jan 6 18:24:56 2013 +0100

    Compatibility: Use org-load-noerror-mustsuffix
    
    * lisp/org-macs.el: New macro to allow the 5-argument form of load to
      be used where possible without breaking compatibility with XEmacs.
    
    * lisp/org.el (org-version, org-reload): Use
      `org-load-noerror-mustsuffix´ instead of adding a fifth argument to
      load directly.  Guard against undefined variable load-suffixes,
      which doesn't exist in XEmacs.
    
    Since load-suffixes doesn't exist in XEmacs, (org-reload 'uncompiled)
    will not work.  If it doesn't complicate the compatibility macro too
    much this can be added later.


-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Bastien]

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

Hi Eric,

Eric Schulte <schulte.eric@gmail.com> writes:

> Recently my Emacs start up fails when I (require 'org) because the
> function `org-load-noerror-mustsuffix' is undefined.  I was able to fix
> this by checking out the version previous to commit 5484a33b [1].

Does this patch help?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: org-macs.el.patch --]
[-- Type: text/x-patch, Size: 474 bytes --]

diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index e5d6100..974a366 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -426,6 +426,7 @@ the value in cdr."
     (cons (list (car flat) (cadr flat))
 	  (org-make-parameter-alist (cddr flat)))))
 
+;;;###autoload
 (defmacro org-load-noerror-mustsuffix (file)
   "Load FILE with optional arguments NOERROR and MUSTSUFFIX.  Drop the MUSTSUFFIX argument for XEmacs, which doesn't recognize it."
   (if (featurep 'xemacs)

[-- Attachment #3: Type: text/plain, Size: 14 bytes --]


-- 
 Bastien

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Eric Schulte]

Nope,

Even with the addition of that autoload statement I get the same error

  let: Symbol's function definition is void: org-load-noerror-mustsuffix

Best,

Bastien <bzg@altern.org> writes:

> Hi Eric,
>
> Eric Schulte <schulte.eric@gmail.com> writes:
>
>> Recently my Emacs start up fails when I (require 'org) because the
>> function `org-load-noerror-mustsuffix' is undefined.  I was able to fix
>> this by checking out the version previous to commit 5484a33b [1].
>
> Does this patch help?

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Bastien]

Eric Schulte <schulte.eric@gmail.com> writes:

> Even with the addition of that autoload statement I get the same error
>
>   let: Symbol's function definition is void:
>   org-load-noerror-mustsuffix

Do you have any Org function called before (require 'org)?

`org-load-noerror-mustsuffix' is part of org-macs.el which is
required in org.el.

-- 
 Bastien

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Eric Schulte]

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

Bastien <bzg@altern.org> writes:

> Eric Schulte <schulte.eric@gmail.com> writes:
>
>> Even with the addition of that autoload statement I get the same error
>>
>>   let: Symbol's function definition is void:
>>   org-load-noerror-mustsuffix
>
> Do you have any Org function called before (require 'org)?
>
> `org-load-noerror-mustsuffix' is part of org-macs.el which is
> required in org.el.

The attached init.el is sufficient to trip this error (note: I do have a
recent Org-mode version installed through ELPA, which is initialized
before the init.el is run).


[-- Attachment #2: init.el --]
[-- Type: application/emacs-lisp, Size: 137 bytes --]

[-- Attachment #3: Type: text/plain, Size: 286 bytes --]


Sadly I have no backtrace to share, even starting with --debug-init, I
only get the following in my *Messages* buffer (and no *Backtrace*
buffer).

  let: Symbol's function definition is void: org-load-noerror-mustsuffix

Hope this helps,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Nick Dokos]

Eric Schulte <schulte.eric@gmail.com> wrote:

> Bastien <bzg@altern.org> writes:
> 
> > Eric Schulte <schulte.eric@gmail.com> writes:
> >
> >> Even with the addition of that autoload statement I get the same error
> >>
> >>   let: Symbol's function definition is void:
> >>   org-load-noerror-mustsuffix
> >
> > Do you have any Org function called before (require 'org)?
> >
> > `org-load-noerror-mustsuffix' is part of org-macs.el which is
> > required in org.el.
> 
> The attached init.el is sufficient to trip this error (note: I do have a
> recent Org-mode version installed through ELPA, which is initialized
> before the init.el is run).
> 
> (add-hook 'after-init-hook
>  `(lambda ()
>     (require 'org)
>     (load-file "~/.emacs.d/src/org-mode/lisp/org.el")
>     (org-reload)))
> 
> Sadly I have no backtrace to share, even starting with --debug-init, I
> only get the following in my *Messages* buffer (and no *Backtrace*
> buffer).
> 
>   let: Symbol's function definition is void: org-load-noerror-mustsuffix
> 

So, which org-macs are you loading? If the (require 'org) loads the ELPA
org-macs (which presumably does not have the macro), then the (load-file
...) will not reload it (and even if it did, it would probably get the
ELPA one again). What happens if, after the (require 'org), you delete
org-macs from the features list, set the load path to pick up things
from ~/.emacs.d/src/org-mode/lisp, load org.el and then try the
org-reload?

Nick

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Eric Schulte]

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

Nick Dokos <nicholas.dokos@hp.com> writes:

> Eric Schulte <schulte.eric@gmail.com> wrote:
>
>> Bastien <bzg@altern.org> writes:
>> 
>> > Eric Schulte <schulte.eric@gmail.com> writes:
>> >
>> >> Even with the addition of that autoload statement I get the same error
>> >>
>> >>   let: Symbol's function definition is void:
>> >>   org-load-noerror-mustsuffix
>> >
>> > Do you have any Org function called before (require 'org)?
>> >
>> > `org-load-noerror-mustsuffix' is part of org-macs.el which is
>> > required in org.el.
>> 
>> The attached init.el is sufficient to trip this error (note: I do have a
>> recent Org-mode version installed through ELPA, which is initialized
>> before the init.el is run).
>> 
>> (add-hook 'after-init-hook
>>  `(lambda ()
>>     (require 'org)
>>     (load-file "~/.emacs.d/src/org-mode/lisp/org.el")
>>     (org-reload)))
>> 
>> Sadly I have no backtrace to share, even starting with --debug-init, I
>> only get the following in my *Messages* buffer (and no *Backtrace*
>> buffer).
>> 
>>   let: Symbol's function definition is void: org-load-noerror-mustsuffix
>> 
>
> So, which org-macs are you loading? If the (require 'org) loads the ELPA
> org-macs (which presumably does not have the macro), then the (load-file
> ...) will not reload it (and even if it did, it would probably get the
> ELPA one again). What happens if, after the (require 'org), you delete
> org-macs from the features list, set the load path to pick up things
> from ~/.emacs.d/src/org-mode/lisp, load org.el and then try the
> org-reload?
>

I attempted to apply your suggestions to my init.el resulting in the
following


[-- Attachment #2: init.el --]
[-- Type: application/emacs-lisp, Size: 248 bytes --]

[-- Attachment #3: Type: text/plain, Size: 859 bytes --]


It yields these errors on startup

  *Messages*
  Loading /home/eschulte/.emacs.d/src/org-mode/lisp/org.el (source)...
  Package assoc is obsolete!
  Loading /home/eschulte/.emacs.d/elpa/org-20121231/org-loaddefs.el (source)...done
  Problems while trying to load feature `org-jsinfo'
  eval-buffer: Symbol's function definition is void: org-define-obsolete-function-alias

It looks like removing items from `features' is dangerous.

If this problem is specific to my situation I'm happy to ignore it until
I can update my elpa version of Org-mode to a newer one.  Alternately I
could just remove my ELPA install of Org-mode, as it was only installed
to answer questions on the mailing list, and I don't think side-by-side
ELPA and source Org-modes are necessarily something that needs to be
supported.

Thanks,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Bastien]

Hi Eric,

Eric Schulte <schulte.eric@gmail.com> writes:

> If this problem is specific to my situation I'm happy to ignore it until
> I can update my elpa version of Org-mode to a newer one.  Alternately I
> could just remove my ELPA install of Org-mode, as it was only installed
> to answer questions on the mailing list, and I don't think side-by-side
> ELPA and source Org-modes are necessarily something that needs to be
> supported.

I confirm `org-load-noerror-mustsuffix' is *not* in the ELPA tarball,
so somehow your initialization (auto)loads recent Org files, and then
the ELPA load path takes over.

As said in http://orgmode.org/elpa.html:

,----
| By default, Emacs loads packages after it loads your Emacs init file.
| 
| We recommend intializing packages as early as possible in your Emacs
| init file so that your Org configuration will be correctly handled:
| 
| ;; -*- emacs-lisp -*-
| (package-initialize)                ;; Initialize & Install Package
| ;; (setq org-...)                   ;; Your custom settings
| 
| The package initialization should happen before you require Org and
| set any Org options.
`----

So yes, I'd suggest removing Org ELPA version completely..

-- 
 Bastien

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Eric Schulte]

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

Bastien <bzg@altern.org> writes:

> Hi Eric,
>
> Eric Schulte <schulte.eric@gmail.com> writes:
>
>> If this problem is specific to my situation I'm happy to ignore it until
>> I can update my elpa version of Org-mode to a newer one.  Alternately I
>> could just remove my ELPA install of Org-mode, as it was only installed
>> to answer questions on the mailing list, and I don't think side-by-side
>> ELPA and source Org-modes are necessarily something that needs to be
>> supported.
>
> I confirm `org-load-noerror-mustsuffix' is *not* in the ELPA tarball,
> so somehow your initialization (auto)loads recent Org files, and then
> the ELPA load path takes over.
>
> As said in http://orgmode.org/elpa.html:
>
> ,----
> | By default, Emacs loads packages after it loads your Emacs init file.
> | 
> | We recommend intializing packages as early as possible in your Emacs
> | init file so that your Org configuration will be correctly handled:
> | 
> | ;; -*- emacs-lisp -*-
> | (package-initialize)                ;; Initialize & Install Package
> | ;; (setq org-...)                   ;; Your custom settings
> | 
> | The package initialization should happen before you require Org and
> | set any Org options.
> `----
>
> So yes, I'd suggest removing Org ELPA version completely..

This is done I now have no Org packages in my ELPA.  However I *still*
can't use any version of Org-mode post the 5484a33b commit.  For the
simplest possible reproduction instructions, try the following.

1. mv your init.el to a backup locate

2. replace your init.el with the attached (update paths as appropriate)


[-- Attachment #2: init.el --]
[-- Type: application/emacs-lisp, Size: 109 bytes --]

[-- Attachment #3: Type: text/plain, Size: 289 bytes --]


3. start Emacs

For me this minimal setup works with versions of Org-mode prior to
5484a33b, but fails with the current master branch.

As a side note, is it intended that users should have to load
org-compat.el before loading org.el?

Best,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Bastien]

Does your emacs fail if you simply point to the correct load path?

I.e. a one-line init.el with this:

  (add-to-list 'load-path "~/.emacs.d/src/org-mode/lisp/")

?

-- 
 Bastien

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Eric Schulte]

Bastien <bzg@altern.org> writes:

> Does your emacs fail if you simply point to the correct load path?
>
> I.e. a one-line init.el with this:
>
>   (add-to-list 'load-path "~/.emacs.d/src/org-mode/lisp/")
>
> ?

Excellent, that does indeed work, I should have tried it much earlier.

Sorry about the noise,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Eric Schulte]

Eric Schulte <schulte.eric@gmail.com> writes:

> Bastien <bzg@altern.org> writes:
>
>> Does your emacs fail if you simply point to the correct load path?
>>
>> I.e. a one-line init.el with this:
>>
>>   (add-to-list 'load-path "~/.emacs.d/src/org-mode/lisp/")
>>
>> ?
>
> Excellent, that does indeed work, I should have tried it much earlier.
>

Retracted.  This only works because,

  (add-to-list 'load-path "~/.emacs.d/src/org-mode/lisp/")
  (require 'org)

Does not in fact load up the newest version of Org-mode.

I'm surprised I'm the only person experiencing this problem.  Can anyone
else reproduce this locally?  To re-iterate, with no Org-mode installed
through ELPA, and with a clean (either with or without running make)
checkout of the master branch start up an "Emacs -Q", and then evaluate
the following in your scratch buffer.

  (load-file "path/to/org-mode/lisp/org.el")

Thanks,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Nick Dokos]

Eric Schulte <schulte.eric@gmail.com> wrote:

> Eric Schulte <schulte.eric@gmail.com> writes:
> 
> > Bastien <bzg@altern.org> writes:
> >
> >> Does your emacs fail if you simply point to the correct load path?
> >>
> >> I.e. a one-line init.el with this:
> >>
> >>   (add-to-list 'load-path "~/.emacs.d/src/org-mode/lisp/")
> >>
> >> ?
> >
> > Excellent, that does indeed work, I should have tried it much earlier.
> >
> 
> Retracted.  This only works because,
> 
>   (add-to-list 'load-path "~/.emacs.d/src/org-mode/lisp/")
>   (require 'org)
> 
> Does not in fact load up the newest version of Org-mode.
> 

Count me confused: what does it do?

> I'm surprised I'm the only person experiencing this problem.  Can anyone
> else reproduce this locally?  To re-iterate, with no Org-mode installed
> through ELPA, and with a clean (either with or without running make)
> checkout of the master branch start up an "Emacs -Q", and then evaluate
> the following in your scratch buffer.
> 
>   (load-file "path/to/org-mode/lisp/org.el")
> 

This has no chance of working: it will satisfy all the requires from the
org that's distributed with emacs. You must ``make autoloads'' and you
must set the load-path.

Nick

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Bastien]

Hi Eric,

Eric Schulte <schulte.eric@gmail.com> writes:

> Retracted.  This only works because,
>
>   (add-to-list 'load-path "~/.emacs.d/src/org-mode/lisp/")
>   (require 'org)
>
> Does not in fact load up the newest version of Org-mode.

How did you check?

You don't have the error about the missing function anymore, right?

> I'm surprised I'm the only person experiencing this problem.  Can anyone
> else reproduce this locally?  To re-iterate, with no Org-mode installed
> through ELPA, and with a clean (either with or without running make)
> checkout of the master branch start up an "Emacs -Q", and then evaluate
> the following in your scratch buffer.
>
>   (load-file "path/to/org-mode/lisp/org.el")

When you use Org from git, you need to run make autoloads at least.
Otherwise, yes, autoloads will not be correct.

-- 
 Bastien

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Eric Schulte]

Bastien <bzg@altern.org> writes:

> Hi Eric,
>
> Eric Schulte <schulte.eric@gmail.com> writes:
>
>> Retracted.  This only works because,
>>
>>   (add-to-list 'load-path "~/.emacs.d/src/org-mode/lisp/")
>>   (require 'org)
>>
>> Does not in fact load up the newest version of Org-mode.
>
> How did you check?
>
> You don't have the error about the missing function anymore, right?
>
>> I'm surprised I'm the only person experiencing this problem.  Can anyone
>> else reproduce this locally?  To re-iterate, with no Org-mode installed
>> through ELPA, and with a clean (either with or without running make)
>> checkout of the master branch start up an "Emacs -Q", and then evaluate
>> the following in your scratch buffer.
>>
>>   (load-file "path/to/org-mode/lisp/org.el")
>
> When you use Org from git, you need to run make autoloads at least.
> Otherwise, yes, autoloads will not be correct.

Alright, after adding the autoload declaration to the above function,
and running "make autoloads" in the checked out Org-mode directory, I am
able to load org.el successfully.  I just committed this change.

I guess we inherited the need to run "make autoloads" when we got rid of
org-install.el?

Perhaps the Org-mode build [1] page (the target of the "installing Org
mode" link at the top of the home page) shouldn't start with the
sentence "Org can be run directly from sources".

Thanks,

Footnotes: 
[1]  http://orgmode.org/worg/dev/org-build-system.html

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Bastien]

Hi Eric,

Eric Schulte <schulte.eric@gmail.com> writes:

> Alright, after adding the autoload declaration to the above function,
> and running "make autoloads" in the checked out Org-mode directory, I am
> able to load org.el successfully.  I just committed this change.

Are you sure adding ;;;###autoload was needed for this to work, 
or was it just because you used `make autoloads'?

> I guess we inherited the need to run "make autoloads" when we got rid of
> org-install.el?

Not really.  It was always needed to create autoloads (either in
org-install.el or now in org-loaddefs.el) when using Org from Git.

See `make autoloads' for Org 7.7 already creates org-install.el:
http://orgmode.org/cgit.cgi/org-mode.git/plain/Makefile?id=release_7.7

> Perhaps the Org-mode build [1] page (the target of the "installing Org
> mode" link at the top of the home page) shouldn't start with the
> sentence "Org can be run directly from sources".

Yes, I will update both the manual and the Worg page.  

Thanks!

-- 
 Bastien

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Bastien]

Hi Eric,

actually, digging your problem further, I finally committed this
patch: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=db7ece

Loading org-loaddefs.el through `org-load-noerror-mustsuffix' is 
asking for troubles.  I removed this.  

Thanks for the time spent on this,

-- 
 Bastien

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Eric Schulte]

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

Bastien <bzg@altern.org> writes:

> Hi Eric,
>
> actually, digging your problem further, I finally committed this
> patch: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=db7ece
>

Great, thank you for running this to ground.  After my last email I ran
into the problem again, but didn't have the energy to continue
debugging.

>
> Loading org-loaddefs.el through `org-load-noerror-mustsuffix' is
> asking for troubles.  I removed this.  
>

Makes sense.

>
> Thanks for the time spent on this,

To follow up on the instillation instructions.  Those in the manual look
pretty good (I'm speaking specifically of org.texi in the master branch
of the repository, not the online version of the manual which seems to
be out of date and quickly dives into "make help" specifics).  My only
suggestion would be that they include the following step.

  ;; emacs-lisp
  (require 'org)
  (org-reload)

Additionally, I think the attached change to the home page would be
helpful for those who want to get started quickly.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-quick-activation-instructions-on-the-front-page.patch --]
[-- Type: text/x-patch, Size: 922 bytes --]

From 783ea172b6a89ef5022f41f6cc3936dce522bab5 Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Fri, 11 Jan 2013 08:36:12 -0700
Subject: [PATCH] quick activation instructions on the front page

---
 index.org | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/index.org b/index.org
index 0d65fa5..c79bd00 100644
--- a/index.org
+++ b/index.org
@@ -37,6 +37,13 @@ Development version ([[http://orgmode.org/cgit.cgi/org-mode.git/][cgit]]):
 
 Daily snapshots: [[http://orgmode.org/org-latest.tar.gz][tar.gz]] or [[http://orgmode.org/org-latest.zip][zip]]
 
+To activate manual installs.
+#+begin_src emacs-lisp
+  (add-to-list 'load-path "~/path/to/orgdir/lisp")
+  (require 'org)
+  (org-reload) ;; <- on newer Emacs which already include Org
+#+end_src
+
 - [[file:features.org][List of features]]
 - [[#docs][Manuals and tutorials]]
 - [[file:talks.org][Talks about Org mode]]
-- 
1.8.1


[-- Attachment #3: Type: text/plain, Size: 46 bytes --]


-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Bastien]

Hi Eric,

Eric Schulte <schulte.eric@gmail.com> writes:

> Great, thank you for running this to ground.  After my last email I ran
> into the problem again, but didn't have the energy to continue
> debugging.

Yeah, I know how depressing this can be..

> To follow up on the instillation instructions.  Those in the manual look
> pretty good (I'm speaking specifically of org.texi in the master branch
> of the repository, not the online version of the manual which seems to
> be out of date and quickly dives into "make help" specifics).  My only
> suggestion would be that they include the following step.
>
>   ;; emacs-lisp
>   (require 'org)
>   (org-reload)

Both lines slow down Emacs startup quite a lot (especially the second
one!) and they are not necessary once the load-path is correct.

(require 'org) is only necessary when your are calling an org function
from within your .emacs.el, because we need to get the proper autoloads
before calling this function... I could add a note about this if you
think it's useful.

But normally, again, the load-path is enough.

As for (org-reload) I simply would like to get rid of it one day :)

-- 
 Bastien

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Achim Gratz]

Eric Schulte writes:
> My only suggestion would be that they include the following step.
>
>   ;; emacs-lisp
>   (require 'org)
>   (org-reload)

These are both not necessary in the general case and should probably not
be attempted to be solved this way even in special circumstances.

I'll say it again: if you do use Org from Git, then the correct thing to
do is to set the load-path before anything else in your init sequence.
This can be difficult when you have something creative in site-lisp for
instance, but you can always add to load-path on the command line (set
up a wrapper script or alias if you must) and then make sure you have
the correct autoloads:

(load "org-loaddefs")

Nothing else should need to be changed.  If that doesn't work, please
post the information I asked you for so we can figure out where it goes
wrong — it should not happen.


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

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Achim Gratz]

Bastien writes:
> Loading org-loaddefs.el through `org-load-noerror-mustsuffix' is 
> asking for troubles.  I removed this.  

However, in a situation where this is indeed the problem, you actually
don't solve it and it will just appear slightly later.

Also, this change again breaks installs where the autoloads file is
compressed (that was the reason for introduction of the more complicated
way to load this file that led to the introduction of the new macro).
In particular, when there is another org-loaddefs.el later on in the
loadpath, it will happily load that file, creating just the very problem
we were trying to avoid.


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

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> Also, this change again breaks installs where the autoloads file is
> compressed (that was the reason for introduction of the more complicated
> way to load this file that led to the introduction of the new
> macro).

There is this line at the end of org-loaddefs.el:

;; no-byte-compile: t

So my understanding is that org-loaddefs.el is never compressed.

Under which conditions is it compressed?

> In particular, when there is another org-loaddefs.el later on in the
> loadpath, it will happily load that file, creating just the very problem
> we were trying to avoid.

That's why the user needs to add the correct load-path in his
.emacs.el when using a tarball or a git clone.  I made it clear
in the docs.

This correct load-path is shadowed by the one of an ELPA install 
if the user does not take care of (package-initialize) at the very
beginning of his .emacs.el, but I also made it clear that users
should avoid mixing two installation methods.

So I think we're fine here.

-- 
 Bastien

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Achim Gratz]

Bastien writes:
> There is this line at the end of org-loaddefs.el:
>
> ;; no-byte-compile: t
>
> So my understanding is that org-loaddefs.el is never compressed.

Byte-compiled != compressed.

> Under which conditions is it compressed?

When calling gzip on it.

>> In particular, when there is another org-loaddefs.el later on in the
>> loadpath, it will happily load that file, creating just the very problem
>> we were trying to avoid.
>
> That's why the user needs to add the correct load-path in his
> .emacs.el when using a tarball or a git clone.  I made it clear
> in the docs.

No, it will load the wrong file even if the load-path is correct.  Try
it if you don't believe me — gotta run now.


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

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> Bastien writes:
>> There is this line at the end of org-loaddefs.el:
>>
>> ;; no-byte-compile: t
>>
>> So my understanding is that org-loaddefs.el is never compressed.
>
> Byte-compiled != compressed.

Yep, typo.  But the 'mustsuffix trick is to force loading ".el" (and
not ".elc" files, right?  My question is: when is it necessary?

>> Under which conditions is it compressed?
>
> When calling gzip on it.

Er... I'm not Spinoza, considering things "sub specie aeternitatis".

I'm trying to consider real use-cases, with a sense of "real" close to
"not so improbable".  I don't see why Org should take care of users
who are pervert enough to gzip their org-loaddefs.el... but maybe I
lack imagination, as usual :)

>>> In particular, when there is another org-loaddefs.el later on in the
>>> loadpath, it will happily load that file, creating just the very problem
>>> we were trying to avoid.
>>
>> That's why the user needs to add the correct load-path in his
>> .emacs.el when using a tarball or a git clone.  I made it clear
>> in the docs.
>
> No, it will load the wrong file even if the load-path is correct.  Try
> it if you don't believe me — gotta run now.

emacs -Q
M-: (add-to-list 'load-path "~/git/org-mode/lisp")
M-: (find-library "org")
M-: (buffer-file-name)
 => "~/git/org-mode/lisp/org.el"

emacs -Q
M-: (add-to-list 'load-path "~/git/org-mode/lisp" t)
M-: (find-library "org")
M-: (buffer-file-name)
 => "/usr/local/share/emacs/24.3.50/lisp/org/org.el"

But I know your answer, `find-library' does not give the library from
which functions have been autoloaded.

-- 
 Bastien

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Achim Gratz]

Bastien writes:
> Yep, typo.  But the 'mustsuffix trick is to force loading ".el" (and
> not ".elc" files, right?  My question is: when is it necessary?

The 'mustsuffix argument prevents consideration of the filename without
the extensions listed in load-suffixes.  In other words, when you are
trying to load feature 'x, a file named just "x" does not satisfy the
requirement as it otherwise would.  On the other hand, it does not
prevent using "x.el.gz" instead of "x.el" as 'nosuffix does.

> I'm trying to consider real use-cases, with a sense of "real" close to
> "not so improbable".  I don't see why Org should take care of users
> who are pervert enough to gzip their org-loaddefs.el... but maybe I
> lack imagination, as usual :)

This is a real use case.  Installation with compression is a standard
feature of Emacs and just currently not supported by the build system,
mainly due to "little" problems like the above.  Emacs' current
installer itself compresses the source files only when there's a
byte-compiled file around, so any recent Emacs would automatically have
a file "org-loaddefs.el" in load-path, although some packagers have
their own ideas about this.  You should generally expect that the
installed files, whether sources or byte-compiled files could have been
compressed.

Now if someone decides to compress the lisp folder for their own org
installation and aren't taking care to exclude the autoload files, then
this is what they get from 'emacs -Q":

--8<---------------cut here---------------start------------->8---
(require 'find-func)
=> find-func
(find-library-name "org-loaddefs.el")
=> "/usr/local/share/emacs/24.2/lisp/org/org-loaddefs.el"
(add-to-list 'load-path "~/lisp/org-mode/lisp")
=> (~/lisp/org-mode/lisp …)
(find-library-name "org-loaddefs.el")
"/home/gratz/lisp/org-mode/lisp/org-loaddefs.el.gz"
(load "org-loaddefs.el" t nil t)
=> Loading /usr/local/share/emacs/24.2/lisp/org/org-loaddefs.el (source)...done
--8<---------------cut here---------------end--------------->8---

This is decidedly not what you wanted to achieve and outright devious,
given that you don't even get the hint from *Messages* what file
actually got loaded when the second argument to load is also "t".

--8<---------------cut here---------------start------------->8---
(require 'org-macs)
(let ((load-suffixes (list ".el")))
  (org-load-noerror-mustsuffix "org-loaddefs"))
=> Loading /home/gratz/lisp/org-mode/lisp/org-loaddefs.el.gz...
=> uncompressing org-loaddefs.el.gz...done
=> Loading /home/gratz/lisp/org-mode/lisp/org-loaddefs.el.gz...done
--8<---------------cut here---------------end--------------->8---

This on the other hand is what was intended to happen.

The problem is that for the previous discussion "(require 'org-macs)"
was effectively a NOP because 'org-macs was already loaded from a
different place.  If you want to fix it, then that's where the effort
should be directed (org-reload already does that and it's not difficult
to do here either).

[…]
> But I know your answer, `find-library' does not give the library from
> which functions have been autoloaded.

I might harp too much about this, but it's not the answer to this
question.  But see above how find-library can fool you when you are
actually using load with optional arguments instead.


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

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Eric Schulte]

Achim Gratz <Stromeko@nexgo.de> writes:

> Bastien writes:
>> Yep, typo.  But the 'mustsuffix trick is to force loading ".el" (and
>> not ".elc" files, right?  My question is: when is it necessary?
>
> The 'mustsuffix argument prevents consideration of the filename without
> the extensions listed in load-suffixes.  In other words, when you are
> trying to load feature 'x, a file named just "x" does not satisfy the
> requirement as it otherwise would.  On the other hand, it does not
> prevent using "x.el.gz" instead of "x.el" as 'nosuffix does.
>
>> I'm trying to consider real use-cases, with a sense of "real" close to
>> "not so improbable".  I don't see why Org should take care of users
>> who are pervert enough to gzip their org-loaddefs.el... but maybe I
>> lack imagination, as usual :)
>
> This is a real use case.  Installation with compression is a standard
> feature of Emacs and just currently not supported by the build system,
> mainly due to "little" problems like the above.  Emacs' current
> installer itself compresses the source files only when there's a
> byte-compiled file around, so any recent Emacs would automatically have
> a file "org-loaddefs.el" in load-path, although some packagers have
> their own ideas about this.  You should generally expect that the
> installed files, whether sources or byte-compiled files could have been
> compressed.
>
> Now if someone decides to compress the lisp folder for their own org
> installation and aren't taking care to exclude the autoload files, then
> this is what they get from 'emacs -Q":
>
> --8<---------------cut here---------------start------------->8---
> (require 'find-func)
> => find-func
> (find-library-name "org-loaddefs.el")
> => "/usr/local/share/emacs/24.2/lisp/org/org-loaddefs.el"
> (add-to-list 'load-path "~/lisp/org-mode/lisp")
> => (~/lisp/org-mode/lisp …)
> (find-library-name "org-loaddefs.el")
> "/home/gratz/lisp/org-mode/lisp/org-loaddefs.el.gz"
> (load "org-loaddefs.el" t nil t)
> => Loading /usr/local/share/emacs/24.2/lisp/org/org-loaddefs.el (source)...done
> --8<---------------cut here---------------end--------------->8---
>
> This is decidedly not what you wanted to achieve and outright devious,
> given that you don't even get the hint from *Messages* what file
> actually got loaded when the second argument to load is also "t".
>
> --8<---------------cut here---------------start------------->8---
> (require 'org-macs)
> (let ((load-suffixes (list ".el")))
>   (org-load-noerror-mustsuffix "org-loaddefs"))
> => Loading /home/gratz/lisp/org-mode/lisp/org-loaddefs.el.gz...
> => uncompressing org-loaddefs.el.gz...done
> => Loading /home/gratz/lisp/org-mode/lisp/org-loaddefs.el.gz...done
> --8<---------------cut here---------------end--------------->8---
>
> This on the other hand is what was intended to happen.
>
> The problem is that for the previous discussion "(require 'org-macs)"
> was effectively a NOP because 'org-macs was already loaded from a
> different place.  If you want to fix it, then that's where the effort
> should be directed (org-reload already does that and it's not difficult
> to do here either).
>
> […]
>> But I know your answer, `find-library' does not give the library from
>> which functions have been autoloaded.
>
> I might harp too much about this, but it's not the answer to this
> question.  But see above how find-library can fool you when you are
> actually using load with optional arguments instead.
>

These sounds like a Emacs-wide (or possibly find-library) issues, rather
than anything specific to Org, outlining, agendas or plain text notes.

Shouldn't this sort of discussion and development be taking place on
emacs-dev and in non-org Emacs libraries.

In my opinion the only reason to try to solve these issues in Org-mode
proper is if we are testing out new functionality which will eventually
be adopted by core Emacs.  Otherwise I would argue that such development
within Org-mode is a waste of Org-mode development time, effort and code
complexity.

At the least perhaps such load/require mechanisms should be extracted
into a separate library with no Org-mode specific code.  Then Org-mode
could make use of these libraries, but so could other large systems
distributed with Emacs but developed independently (e.g., gnus).

Best,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Achim Gratz]

Eric Schulte writes:
> These sounds like a Emacs-wide (or possibly find-library) issues, rather
> than anything specific to Org, outlining, agendas or plain text notes.
>
> Shouldn't this sort of discussion and development be taking place on
> emacs-dev and in non-org Emacs libraries.

I've already taken this problem to emacs-devel since it is indeed a
general problem.

> In my opinion the only reason to try to solve these issues in Org-mode
> proper is if we are testing out new functionality which will eventually
> be adopted by core Emacs.  Otherwise I would argue that such development
> within Org-mode is a waste of Org-mode development time, effort and code
> complexity.

I might still propose a workaround for Org since it is unlikely that
Emacs 24.3 will already ship with an improved package manager and in any
case older Emacsen would not have it.  Also, Org is in a somewhat unique
position right now, being both in Emacs' core and ELPA at the same time
and this is what made the problem so highly visible (as I'm sure you're
painfully aware of by now).

> At the least perhaps such load/require mechanisms should be extracted
> into a separate library with no Org-mode specific code.  Then Org-mode
> could make use of these libraries, but so could other large systems
> distributed with Emacs but developed independently (e.g., gnus).

Yes, the plan (yet to be fully developed) is to add some basic
infrastructure to Emacs that an updated package manager can then use —
or individual libraries if they desire to do this, although I'd be happy
to leave it to package manager.


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

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Bastien]

Eric Schulte <schulte.eric@gmail.com> writes:

> Shouldn't this sort of discussion and development be taking place on
> emacs-dev and in non-org Emacs libraries.

Yes, it does.

-- 
 Bastien

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> Bastien writes:
>> Yep, typo.  But the 'mustsuffix trick is to force loading ".el" (and
>> not ".elc" files, right?  My question is: when is it necessary?
>
> The 'mustsuffix argument prevents consideration of the filename without
> the extensions listed in load-suffixes.  In other words, when you are
> trying to load feature 'x, a file named just "x" does not satisfy the
> requirement as it otherwise would.  On the other hand, it does not
> prevent using "x.el.gz" instead of "x.el" as 'nosuffix does.

(load "org-loaddefs.el" t t t) will *not* load gzipped version of
org-loaddefs.el.

>> I'm trying to consider real use-cases, with a sense of "real" close to
>> "not so improbable".  I don't see why Org should take care of users
>> who are pervert enough to gzip their org-loaddefs.el... but maybe I
>> lack imagination, as usual :)
>
> This is a real use case.  Installation with compression is a standard
> feature of Emacs and just currently not supported by the build system,
> mainly due to "little" problems like the above.  Emacs' current
> installer itself compresses the source files only when there's a
> byte-compiled file around, so any recent Emacs would automatically have
> a file "org-loaddefs.el" in load-path, although some packagers have
> their own ideas about this.  You should generally expect that the
> installed files, whether sources or byte-compiled files could have been
> compressed.

Please point at one distribution that actually distributes gzipped
autoloads files like loaddefs.el.

> Now if someone decides to compress the lisp folder for their own org
> installation 

Then we will tell him not to.  

Can we stop *imagining* people shouting themselves in the foot for
free?  I don't have time to build an hospital for them.

-- 
 Bastien

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Achim Gratz]

Bastien writes:
> (load "org-loaddefs.el" t t t) will *not* load gzipped version of
> org-loaddefs.el.

That's what I was trying to tell you and I consider that a bug.

> Please point at one distribution that actually distributes gzipped
> autoloads files like loaddefs.el.

Why should I?  People have been recusively compressing their lisp
folders for years.  It's supposed to work and it does, why do you need
to break it?

>> Now if someone decides to compress the lisp folder for their own org
>> installation 
>
> Then we will tell him not to.  
>
> Can we stop *imagining* people shouting themselves in the foot for
> free?  I don't have time to build an hospital for them.

It is not at all illegal to do this, so we shouldn't be putting out code
that actively prevents this option.  That Emacs currently doesn't do
this has different reasons and looking at the code Emacs uses makes it
abundantly clear that they've gone to great lengths to enable this for
all files.  Currently it usually is faster to read non-compressed files
from disk if they aren't larger than a single allocation unit of the
underlying file system (which is why the files Emacs uses most often,
that is .elc files and autoloads are kept uncompressed), but there are
situations were there is a clear advantage of using compression and
there are also situations where compressing _all_ files is the only
thing left to do.


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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> Bastien writes:
>> (load "org-loaddefs.el" t t t) will *not* load gzipped version of
>> org-loaddefs.el.
>
> That's what I was trying to tell you and I consider that a bug.

I don't.

>> Please point at one distribution that actually distributes gzipped
>> autoloads files like loaddefs.el.
>
> Why should I?  

Please do send a link to a loaddefs.el.gz anywhere on the web or
anywhere in an Emacs package or provide a way to install Emacs which
generates loaddefs.el.gz.

> It is not at all illegal to do this, so we shouldn't be putting out code
> that actively prevents this option.  That Emacs currently doesn't do
> this has different reasons and looking at the code Emacs uses makes it
> abundantly clear that they've gone to great lengths to enable this for
> all files.  Currently it usually is faster to read non-compressed files
> from disk if they aren't larger than a single allocation unit of the
> underlying file system (which is why the files Emacs uses most often,
> that is .elc files and autoloads are kept uncompressed), but there are
> situations were there is a clear advantage of using compression and
> there are also situations where compressing _all_ files is the only
> thing left to do.

If you want to fix Emacs with respect to allowing loaddefs.el and
org-loaddefs.el compression, please do.

-- 
 Bastien

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Achim Gratz]

Bastien writes:
> If you want to fix Emacs with respect to allowing loaddefs.el and
> org-loaddefs.el compression, please do.

There is nothing to fix in Emacs, it doesn't care if loaddefs is
compressed or not.


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

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Achim Gratz]

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

Achim Gratz writes:
> The problem is that for the previous discussion "(require 'org-macs)"
> was effectively a NOP because 'org-macs was already loaded from a
> different place.  If you want to fix it, then that's where the effort
> should be directed (org-reload already does that and it's not difficult
> to do here either).

The attached patch series will implement a workaround that unloads any
features that have already been loaded with a different load-path so
that the correct files from the current load-path will prevail.  This
should solve the reported problems with the init file using parts of Org
before the load-path is set up.  The implementation uses unload-feature,
so customizations loaded previously (instead of at the very end as they
should) might vanish.  Please report if any init systems do this.

Package manager will still fail in certain situations when Org is
installed via ELPA in an Emacs session that has already used another
version of Org.  This needs to be fixed in package manager, there's no
workaround to do this from Org's side.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Revert-org.el-org-loaddefs.el-use-load-not-org-load-.patch --]
[-- Type: text/x-patch, Size: 2855 bytes --]

From c6b5e0daafb2f6e43ba936a85969b134037ff912 Mon Sep 17 00:00:00 2001
From: Achim Gratz <Stromeko@Stromeko.DE>
Date: Sat, 12 Jan 2013 08:55:07 +0100
Subject: [PATCH 1/3] Revert "org.el ("org-loaddefs.el"): use `load', not
 `org-load-noerror-mustsuffix'"

This reverts commit db7ece9fa2e27944d9482961af9bfd9d08bb3b51.
---
 lisp/org.el | 47 ++++++++++++++++++++++++-----------------------
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 1c2ee9a..e979b35 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -78,11 +78,12 @@ (defvar org-table-formula-constants-local nil
 (require 'find-func)
 (require 'format-spec)
 
-(load "org-loaddefs.el" t t t)
-
 (require 'org-macs)
 (require 'org-compat)
 
+(let ((load-suffixes (list ".el")))
+  (org-load-noerror-mustsuffix "org-loaddefs"))
+
 ;; `org-outline-regexp' ought to be a defconst but is let-binding in
 ;; some places -- e.g. see the macro org-with-limited-levels.
 ;;
@@ -16901,27 +16902,6 @@ (defun org-date-from-calendar ()
       (org-insert-time-stamp
        (encode-time 0 0 0 (nth 1 cal-date) (car cal-date) (nth 2 cal-date))))))
 
-(defcustom org-effort-durations
-  `(("h" . 60)
-    ("d" . ,(* 60 8))
-    ("w" . ,(* 60 8 5))
-    ("m" . ,(* 60 8 5 4))
-    ("y" . ,(* 60 8 5 40)))
-  "Conversion factor to minutes for an effort modifier.
-
-Each entry has the form (MODIFIER . MINUTES).
-
-In an effort string, a number followed by MODIFIER is multiplied
-by the specified number of MINUTES to obtain an effort in
-minutes.
-
-For example, if the value of this variable is ((\"hours\" . 60)), then an
-effort string \"2hours\" is equivalent to 120 minutes."
-  :group 'org-agenda
-  :version "24.1"
-  :type '(alist :key-type (string :tag "Modifier")
-		:value-type (number :tag "Minutes")))
-
 (defun org-minutes-to-clocksum-string (m)
   "Format number of minutes as a clocksum string.
 The format is determined by `org-time-clocksum-format',
@@ -17031,6 +17011,27 @@ (defun org-hh:mm-string-to-minutes (s)
     (string-to-number (match-string 1 s)))
    (t 0)))
 
+(defcustom org-effort-durations
+  `(("h" . 60)
+    ("d" . ,(* 60 8))
+    ("w" . ,(* 60 8 5))
+    ("m" . ,(* 60 8 5 4))
+    ("y" . ,(* 60 8 5 40)))
+  "Conversion factor to minutes for an effort modifier.
+
+Each entry has the form (MODIFIER . MINUTES).
+
+In an effort string, a number followed by MODIFIER is multiplied
+by the specified number of MINUTES to obtain an effort in
+minutes.
+
+For example, if the value of this variable is ((\"hours\" . 60)), then an
+effort string \"2hours\" is equivalent to 120 minutes."
+  :group 'org-agenda
+  :version "24.1"
+  :type '(alist :key-type (string :tag "Modifier")
+		:value-type (number :tag "Minutes")))
+
 (defcustom org-image-actual-width t
   "Should we use the actual width of images when inlining them?
 
-- 
1.8.1


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Revert-org-load-noerror-mustsuffix-requires-an-autol.patch --]
[-- Type: text/x-patch, Size: 860 bytes --]

From 6e158e45fad2c56c37e3cacee772102aec89dbd3 Mon Sep 17 00:00:00 2001
From: Achim Gratz <Stromeko@Stromeko.DE>
Date: Sat, 12 Jan 2013 08:55:51 +0100
Subject: [PATCH 2/3] Revert "`org-load-noerror-mustsuffix' requires an
 autoload"

This reverts commit f94d81a17e2c947a474e0f3b274c46afc3aa99a9.
---
 lisp/org-macs.el | 1 -
 1 file changed, 1 deletion(-)

diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index 974a366..e5d6100 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -426,7 +426,6 @@ (defun org-make-parameter-alist (flat)
     (cons (list (car flat) (cadr flat))
 	  (org-make-parameter-alist (cddr flat)))))
 
-;;;###autoload
 (defmacro org-load-noerror-mustsuffix (file)
   "Load FILE with optional arguments NOERROR and MUSTSUFFIX.  Drop the MUSTSUFFIX argument for XEmacs, which doesn't recognize it."
   (if (featurep 'xemacs)
-- 
1.8.1


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0003-org.el-advice-around-require-to-defuse-mixed-install.patch --]
[-- Type: text/x-patch, Size: 2945 bytes --]

From dd67ebfa2366ba5a275886c7c68f96643c59280b Mon Sep 17 00:00:00 2001
From: Achim Gratz <Stromeko@Stromeko.DE>
Date: Sat, 12 Jan 2013 11:50:27 +0100
Subject: [PATCH 3/3] org.el: advice around require to defuse mixed-install
 scenario

* lisp/org.el (require-reloads-when-shadowed): Advice around require
  to check and correct for the situation where some parts of Org have
  already been loaded, then the load-path has been changed and Org is
  now about to be activated.  To do this, unload the previously loaded
  feature named "org", "ob" or starting with "org-" or "ob-" so that
  the original require function does load the requested feature from
  the current load-path.  Move some requires up in the file so that
  the advice can be removed as early as possible.
---
 lisp/org.el | 38 +++++++++++++++++++++++++++-----------
 1 file changed, 27 insertions(+), 11 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index e979b35..e94442d 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -78,8 +78,35 @@ (defvar org-table-formula-constants-local nil
 (require 'find-func)
 (require 'format-spec)
 
+;; some parts of Org might already have been used from a different
+;; place, try to reload these parts from the current load-path
+(require 'loadhist)
+(defadvice require (before org-require-reload-when-shadowed
+			   (feature &optional filename noerror)
+			   activate compile preactivate)
+  "Check whether a required feature has been shadowed by changing
+`load-path' after it has been loaded and reload that feature from
+current load-path in this case."
+  (when (featurep feature)
+    (let ((feature-name (or filename (symbol-name feature))))
+      (when (string-match "^\\(org\\|ob\\)\\(-.*\\)?$" feature-name)
+	(let ((feature-lib  (file-name-directory (or (locate-library feature-name) "")))
+	      (feature-dir  (file-name-directory (feature-file feature))))
+	  ;(message "require-reload-when shadowed %s\n\t%s\n\t%s" feature-name feature-lib feature-dir)
+	  (when (not (string= feature-lib feature-dir))
+	    (message "Reloading %s" feature-name)
+	    (unload-feature feature t)))))))
 (require 'org-macs)
 (require 'org-compat)
+(require 'org-entities)
+(require 'org-faces)
+(require 'org-list)
+(require 'org-pcomplete)
+(require 'org-src)
+(require 'org-footnote)
+;; babel
+(require 'ob)
+(eval-and-compile (ad-unadvise 'require))
 
 (let ((load-suffixes (list ".el")))
   (org-load-noerror-mustsuffix "org-loaddefs"))
@@ -4991,17 +5018,6 @@ (defvar buffer-face-mode-face)
 (require 'easymenu)
 (require 'overlay)
 
-;; (require 'org-macs) moved higher up in the file before it is first used
-(require 'org-entities)
-;; (require 'org-compat) moved higher up in the file before it is first used
-(require 'org-faces)
-(require 'org-list)
-(require 'org-pcomplete)
-(require 'org-src)
-(require 'org-footnote)
-
-;; babel
-(require 'ob)
 
 ;;;###autoload
 (define-derived-mode org-mode outline-mode "Org"
-- 
1.8.1


[-- Attachment #5: Type: text/plain, Size: 188 bytes --]



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: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Bastien]

Thanks for the patch, it made me realize Org breaks Emacs coding
conventions by allowing advice in several places.  I will work on
removing them.

Also, the series rintroduces a warning because it moves
`org-effort-durations'.

Finally, as far as I understand, you are arguing that users may want
to compress their Org files, and that (load "org-loaddefs.el") will
fail if they do, and that's why they need this patch.

If the additional complexity is just for this, I'm not convinced by
the patch.  If it fixes something else, please let me know.

-- 
 Bastien

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Achim Gratz]

Bastien writes:
> Also, the series rintroduces a warning because it moves
> `org-effort-durations'.

Yes, only in single-file compilation mode and it is completely
irrelevant to the problem at hand and can be fixed easily, so I opted to
get the code out to be tested and fix this later.

> Finally, as far as I understand, you are arguing that users may want
> to compress their Org files, and that (load "org-loaddefs.el") will
> fail if they do, and that's why they need this patch.

No, not at all.  That's what reverting db7ece9fa2 does.  And if you
really want to flip off folks with strange Org installations instead of
helping them survive, then leave out that third "t", i.e. just change
that line to:

(load "org-loaddefs" 'noerror 'nomessage)

That will wreak havoc for someone who managed to pull all stops and
byte-compile org-loaddefs anyway, but any sane setup will work as
intended.

> If the additional complexity is just for this, I'm not convinced by
> the patch.  If it fixes something else, please let me know.

Please go back to the beginning of the thread and read about Eric's
problem, that's what the patch is trying to solve.  Based on the
comments in bug#10125 by Jambunathan, borked setups with partly loaded
Org versions are much more common than I would have thought.

In other words something like this:

--8<---------------cut here---------------start------------->8---
(require 'org-compat)
(require 'org-macs)
(add-to-list 'load-path "/home/org-mode/lisp")
(require 'org)
--8<---------------cut here---------------end--------------->8---

will result in a correctly loaded Org with the patch, but yield either a
not-correctly working Org (silently wrong and producing strange results
that nobody can reproduce) or a failure to load Org at all (you get an
error at least) without it.

It is also an experiment to determine if Emacs should do something like
this (by default or as an option) and how to best implement it.  Even if
it eventually moved into Emacs however, Org would still have to
implement it as a workaround for older Emacsen that don't have it.


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: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Bastien]

> No, not at all.  That's what reverting db7ece9fa2 does.  And if you
> really want to flip off folks with strange Org installations instead of
> helping them survive, then leave out that third "t", i.e. just change
> that line to:

Please lower your tone.

I'm not "flipping off" anybody.

> In other words something like this:
>
> (require 'org-compat)
> (require 'org-macs)
> (add-to-list 'load-path "/home/org-mode/lisp")
> (require 'org)

Anybody can see this is wrong, and instead of letting users shoot
themselves in the foot with a wrong setup, we should educate them to
use a correct one like

(add-to-list 'load-path "/home/org-mode/lisp")
(require 'org)

which shouldn't be that hard.

> will result in a correctly loaded Org with the patch, but yield either a
> not-correctly working Org (silently wrong and producing strange results
> that nobody can reproduce) or a failure to load Org at all (you get an
> error at least) without it.

I'm fine with not fixing this right now.

> It is also an experiment to determine if Emacs should do something like
> this (by default or as an option) and how to best implement it.  Even if
> it eventually moved into Emacs however, Org would still have to
> implement it as a workaround for older Emacsen that don't have it.

Again, I'm fine with any experiment that can be done on Emacs side so
that Emacs autoloads are always correct.  But I won't allow a patch
that advise `require' in Org for now.

Thanks,

-- 
 Bastien

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Achim Gratz]

Bastien writes:
>> In other words something like this:
>>
>> (require 'org-compat)
>> (require 'org-macs)
>> (add-to-list 'load-path "/home/org-mode/lisp")
>> (require 'org)
>
> Anybody can see this is wrong, and instead of letting users shoot
> themselves in the foot with a wrong setup, we should educate them to
> use a correct one like

Yes, if it's in four consecutive lines its easy to see.  The cold truth
is that the first two lines may not be visible to the user at all.


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: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> Please go back to the beginning of the thread and read about Eric's
> problem, that's what the patch is trying to solve.

Also, sorry to insist, but Eric bumped on a bug you introduced and
committed just before the merge with Emacs emacs-24, which is bad.

What would help would be a flag like "[exp]" on patches that are
really just experimental and for exploration only -- like the ones
you just posted.

-- 
 Bastien

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Achim Gratz]

Bastien writes:
>> Please go back to the beginning of the thread and read about Eric's
>> problem, that's what the patch is trying to solve.
>
> Also, sorry to insist, but Eric bumped on a bug you introduced and
> committed just before the merge with Emacs emacs-24, which is bad.

Sorry, but there is no bug.  The change only switches the failure mode
from "fall over some time later" to "stop with an error now" for the
wrong init sequence that Eric tried.  Also:

Bastien writes:
> Please feel free to apply those patch, thanks a lot.


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

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Achim Gratz]

Eric Schulte <schulte.eric <at> gmail.com> writes:
> Alright, after adding the autoload declaration to the above function,
> and running "make autoloads" in the checked out Org-mode directory, I am
> able to load org.el successfully.  I just committed this change.

You are getting ahead of yourself, there is no need to do this.

> I guess we inherited the need to run "make autoloads" when we got rid of
> org-install.el?

No, it is way older than that.


Regards,
Achim.

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Stelian Iancu]

> Retracted.  This only works because,
> 
>  (add-to-list 'load-path "~/.emacs.d/src/org-mode/lisp/")
>  (require 'org)
> 
> Does not in fact load up the newest version of Org-mode.
> 
> I'm surprised I'm the only person experiencing this problem.  Can anyone
> else reproduce this locally?  To re-iterate, with no Org-mode installed
> through ELPA, and with a clean (either with or without running make)
> checkout of the master branch start up an "Emacs -Q", and then evaluate
> the following in your scratch buffer.
> 
>  (load-file "path/to/org-mode/lisp/org.el")
> 

I did exactly this and I get the following:

let: Symbol's function definition is void: org-load-noerror-mustsuffix

Latest code from git, did run make. 

Emacs is the latest pretest:

GNU Emacs 24.2.92.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2013-01-10 on bob.porkrind.org

Indeed, when doing (require 'org) I don't get this problem. So even though the latest code is in the load-path, somehow it's not loaded.

Stelian

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Stelian Iancu]

> Retracted.  This only works because,
> 
>  (add-to-list 'load-path "~/.emacs.d/src/org-mode/lisp/")
>  (require 'org)
> 
> Does not in fact load up the newest version of Org-mode.
> 
> I'm surprised I'm the only person experiencing this problem.  Can anyone
> else reproduce this locally?  To re-iterate, with no Org-mode installed
> through ELPA, and with a clean (either with or without running make)
> checkout of the master branch start up an "Emacs -Q", and then evaluate
> the following in your scratch buffer.
> 
>  (load-file "path/to/org-mode/lisp/org.el")
> 

I did exactly this and I get the following:

let: Symbol's function definition is void: org-load-noerror-mustsuffix

Latest code from git, did run make. 

Emacs is the latest pretest:

GNU Emacs 24.2.92.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2013-01-10 on bob.porkrind.org

Indeed, when doing (require 'org) I don't get this problem. So even though the latest code is in the load-path, somehow it's not loaded.

Stelian

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Achim Gratz]

Eric Schulte writes:
> This is done I now have no Org packages in my ELPA.  However I *still*
> can't use any version of Org-mode post the 5484a33b commit.  For the
> simplest possible reproduction instructions, try the following.
>
> 1. mv your init.el to a backup locate
>
> 2. replace your init.el with the attached (update paths as appropriate)
>
> (load-file "~/.emacs.d/src/org-mode/lisp/org-compat.el")
> (load-file "~/.emacs.d/src/org-mode/lisp/org.el")
>
> 3. start Emacs
>
> For me this minimal setup works with versions of Org-mode prior to
> 5484a33b, but fails with the current master branch.

Which version of Emacs, any old org-remnants in site-lisp and where do
you set load-path?  It would be easier for all of us if you could do a
step-by-step evaluation in the scratch buffer from "emacs -Q".


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

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Eric Schulte]

Achim Gratz <Stromeko@nexgo.de> writes:

> Eric Schulte writes:
>> This is done I now have no Org packages in my ELPA.  However I *still*
>> can't use any version of Org-mode post the 5484a33b commit.  For the
>> simplest possible reproduction instructions, try the following.
>>
>> 1. mv your init.el to a backup locate
>>
>> 2. replace your init.el with the attached (update paths as appropriate)
>>
>> (load-file "~/.emacs.d/src/org-mode/lisp/org-compat.el")
>> (load-file "~/.emacs.d/src/org-mode/lisp/org.el")
>>
>> 3. start Emacs
>>
>> For me this minimal setup works with versions of Org-mode prior to
>> 5484a33b, but fails with the current master branch.
>
> Which version of Emacs,

Fairly recent from the bzr repository.

    GNU Emacs 24.3.50.1
    Copyright (C) 2012 Free Software Foundation, Inc.
    GNU Emacs comes with ABSOLUTELY NO WARRANTY.
    You may redistribute copies of Emacs
    under the terms of the GNU General Public License.
    For more information about these matters, see the file named COPYING.

> any old org-remnants in site-lisp

No, only the Org-mode distributed as part of Emacs.

> and where do you set load-path?

No load path customization, just those two lines above are enough to
cause the error.

> It would be easier for all of us if you could do a step-by-step
> evaluation in the scratch buffer from "emacs -Q".
>

alright, starting with emacs -Q, evaluate the following in your scratch
buffer.

  (load-file "~/.emacs.d/src/org-mode/lisp/org.el")

it may complain (void-function org-define-obsolete-function-alias), in
which case evaluate the following in your scratch buffer

  (load-file "~/.emacs.d/src/org-mode/lisp/org-compat.el")
  (load-file "~/.emacs.d/src/org-mode/lisp/org.el")

The above works prior to the offending commit, but now it throws an
error.

Can you reproduce this?

Thanks,

>
>
> Regards,
> Achim.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Nick Dokos]

Eric Schulte <schulte.eric@gmail.com> wrote:

> alright, starting with emacs -Q, evaluate the following in your scratch
> buffer.
> 
>   (load-file "~/.emacs.d/src/org-mode/lisp/org.el")
> 
> it may complain (void-function org-define-obsolete-function-alias), in
> which case evaluate the following in your scratch buffer
> 
>   (load-file "~/.emacs.d/src/org-mode/lisp/org-compat.el")
>   (load-file "~/.emacs.d/src/org-mode/lisp/org.el")
> 
> The above works prior to the offending commit, but now it throws an
> error.
> 

I doubt that it works in either case: it may not throw an error but you
still have a mixed install where most of the org stuff will come from
the org that's distributed with emacs.

> Can you reproduce this?
> 

I don't know what error you get: I get a recursive load

insert-file-contents: Recursive load: "/usr/local/share/emacs/24.3.50/lisp/jka-compr.el.gz",\
		       "/usr/local/share/emacs/24.3.50/lisp/jka-compr.el.gz",\
		        "/usr/local/share/emacs/24.3.50/lisp/jka-compr.el.gz",\
			 "/usr/local/share/emacs/24.3.50/lisp/jka-compr.el.gz",\
			  "/usr/local/share/emacs/24.3.50/lisp/jka-compr.el.gz",\
			   "/usr/local/share/emacs/24.3.50/lisp/emacs-lisp/debug.el.gz",\
			    "/home/nick/src/emacs/org/org-mode/lisp/org.el"

No idea why.

But as I said before, you can not expect this to work.

Nick

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Achim Gratz]

Eric Schulte <schulte.eric <at> gmail.com> writes:
> > and where do you set load-path?
> 
> No load path customization, just those two lines above are enough to
> cause the error.

How do you expect Emacs to recognize that you'll want to use a different Org?

> alright, starting with emacs -Q, evaluate the following in your scratch
> buffer.
> 
>   (load-file "~/.emacs.d/src/org-mode/lisp/org.el")

You must set the load-path to start with the expansion of
~/.emacs.d/src/org-mode/lisp/
first.
 
> it may complain (void-function org-define-obsolete-function-alias), in
> which case evaluate the following in your scratch buffer
> 
>   (load-file "~/.emacs.d/src/org-mode/lisp/org-compat.el")

Don't know what you're trying to achieve there.  This should be absolutely
uneccesary.

>   (load-file "~/.emacs.d/src/org-mode/lisp/org.el")

Ditto (we're still talking about 'emacs -Q', yes?).

> The above works prior to the offending commit, but now it throws an
> error.

As it should; and I remark that it didn't work before, you've just not been
getting an error.  Your load-path points to Emacs' core, and then you're trying
to load a single out-of-core file from a later version of Org.

Start Emacs with -Q, make sure the autoloads have been generated in the Git
worktree (org-loaddefs.el must exist).  Then evaluate step-by-step the following
lines in *scratch* (C-j at the end of each sexp):

features
load-history
(symbol-file 'org-release)
(add-to-list 'load-path "~/.emacs.d/src/org-mode/lisp")
(load-library "org-loaddefs")
(org-version t t)
features
load-history
(symbol-file 'org-release)
(org-reload)

Please post the output in *scratch* and *Messages*.

Thanks,
Achim.

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Nick Dokos]

Eric Schulte <schulte.eric@gmail.com> wrote:

> I attempted to apply your suggestions to my init.el resulting in the
> following
> 
> 
> (add-hook 'after-init-hook
>  `(lambda ()
>     (require 'org)
>     (setq features (remove 'org-macs features))
>     (add-to-list 'load-path "~/.emacs.d/src/org-mode/lisp/")
>     (load-file "~/.emacs.d/src/org-mode/lisp/org.el")
>     (org-reload)))
> 

> 
> It yields these errors on startup
> 
>   *Messages*
>   Loading /home/eschulte/.emacs.d/src/org-mode/lisp/org.el (source)...
>   Package assoc is obsolete!
>   Loading /home/eschulte/.emacs.d/elpa/org-20121231/org-loaddefs.el (source)...done
>   Problems while trying to load feature `org-jsinfo'
>   eval-buffer: Symbol's function definition is void: org-define-obsolete-function-alias
> 
> It looks like removing items from `features' is dangerous.
> 

I don't think so: I got the org-define-obsolete-function-alias error
when trying to org-reload this morning (resolved by manually loading
org-compat.el before doing the org-reload again): it's another instance
of the same problem.

You also don't seem to have an org-loaddefs.el in the git clone, so it
loads the one it finds in the ELPA dir. You should ``make autoloads''.

> If this problem is specific to my situation I'm happy to ignore it until
> I can update my elpa version of Org-mode to a newer one.  Alternately I
> could just remove my ELPA install of Org-mode, as it was only installed
> to answer questions on the mailing list, and I don't think side-by-side
> ELPA and source Org-modes are necessarily something that needs to be
> supported.
> 

I'm pretty sure it is. It would probably be better to have two separate
installations and have different init files for each. The side-by-side
installations is an invitation to a franken-install.

Nick

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Achim Gratz]

Eric Schulte writes:
> Recently my Emacs start up fails when I (require 'org) because the
> function `org-load-noerror-mustsuffix' is undefined.  I was able to fix
> this by checking out the version previous to commit 5484a33b [1].

Your Emacs loads an outdated org-macs.el.  Additionally, you have no
autoloads generated in the Git work tree:

--8<---------------cut here---------------start------------->8---
  *Messages*
  Loading /home/eschulte/.emacs.d/src/org-mode/lisp/org.el (source)...
  Package assoc is obsolete!
  Loading /home/eschulte/.emacs.d/elpa/org-20121231/org-loaddefs.el (source)...done
  Problems while trying to load feature `org-jsinfo'
  eval-buffer: Symbol's function definition is void: org-define-obsolete-function-alias
--8<---------------cut here---------------end--------------->8---

This makes Emacs pick up the (wrong) autoloads from the ELPA directory,
although the root cause for your failure is that Org has been partly
loaded before the load-path were pointing to the Git work tree and other
parts have been loaded after the load-path changed.  Please remove or
deactivate the ELPA package.


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Thorsten Jolitz]

Achim Gratz <Stromeko@nexgo.de> writes:

> Eric Schulte writes:
>> Recently my Emacs start up fails when I (require 'org) because the
>> function `org-load-noerror-mustsuffix' is undefined.  I was able to fix
>> this by checking out the version previous to commit 5484a33b [1].
>
> Your Emacs loads an outdated org-macs.el.  Additionally, you have no
> autoloads generated in the Git work tree:
>
>   *Messages*
>   Loading /home/eschulte/.emacs.d/src/org-mode/lisp/org.el (source)...
>   Package assoc is obsolete!
>   Loading /home/eschulte/.emacs.d/elpa/org-20121231/org-loaddefs.el (source)...done
>   Problems while trying to load feature `org-jsinfo'
>   eval-buffer: Symbol's function definition is void: org-define-obsolete-function-alias
>
> This makes Emacs pick up the (wrong) autoloads from the ELPA directory,
> although the root cause for your failure is that Org has been partly
> loaded before the load-path were pointing to the Git work tree and other
> parts have been loaded after the load-path changed.  Please remove or
> deactivate the ELPA package.


I just updated Org-mode from Git a few minutes ago, and, after having
problems, deleted the repo and cloned it again, ran make and make
autoloads, but still cannot load org.el (or start with my usual
starter-kit customizations):

Symbol's function definition is void: 
org-define-obsolete-function-alias

Loading org-compat.el first does not help. 

I do not have the original Org-mode that came with Emacs anymore - I
replaced it with a link to the git-repo, i.e. /usr/share/emacs/24.2/ is
a symlink. 

I do not have an Org-mode version in my Elpa directory (only
org-magit.el).

I followed the advice from this thread and evaluated a list of
expressions in the scratch buffer after loading Emacs -Q, and post the
output below. This is quite a long thread, I'm not sure if I have
exactly the same problem described, and, since I seem to have only the
Org-mode git-version and not a mixed installation, I'm not sure about
the proposed solution.

GNU Emacs 24.2.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.6.2) of
2012-11-18 on eric

org-version
"7.9.3d"

;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, visit that file with C-x C-f,
;; then enter the text in that file's own buffer.

features
(time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image ...)
(symbol-file 'org-release)
nil
(add-to-list 'load-path "~/gitclone/org-mode/lisp")
("~/gitclone/org-mode/lisp" "/usr/share/emacs/24.2/lisp" "/usr/share/emacs/24.2/lisp/vc" "/usr/share/emacs/24.2/lisp/url" "/usr/share/emacs/24.2/lisp/textmodes" "/usr/share/emacs/24.2/lisp/progmodes" "/usr/share/emacs/24.2/lisp/play" "/usr/share/emacs/24.2/lisp/org" "/usr/share/emacs/24.2/lisp/org/contrib" "/usr/share/emacs/24.2/lisp/org/etc" "/usr/share/emacs/24.2/lisp/org/lisp" "/usr/share/emacs/24.2/lisp/org/mk" ...)
(load-library "org-loaddefs")
t
features
(org-loaddefs time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset ...)
load-history
(("/home/tj/gitclone/org-mode/lisp/org-loaddefs.el" (autoload . org-babel-execute-safely-maybe) (autoload . org-babel-execute-maybe) (autoload . org-babel-view-src-block-info) (autoload . org-babel-expand-src-block-maybe) (autoload . org-babel-load-in-session-maybe) (autoload . org-babel-pop-to-session-maybe) (autoload . org-babel-execute-src-block) (autoload . org-babel-expand-src-block) (autoload . org-babel-check-src-block) (autoload . org-babel-insert-header-arg) (autoload . org-babel-load-in-session) ...) ("/home/tj/git/dotemacsd/abbrev_defs" Buffer-menu-mode-abbrev-table Custom-mode-abbrev-table Rd-mode-abbrev-table bbdb-mode-abbrev-table bibtex-mode-abbrev-table bookmark-bmenu-mode-abbrev-table calendar-mode-abbrev-table change-log-mode-abbrev-table comint-mode-abbrev-table completion-list-mode-abbrev-table diary-fancy-display-mode-abbrev-table ...) ("/usr/share/emacs/24.2/lisp/calendar/time-date.elc" (defun . with-decoded-time-value) (defun . encode-time-value) (autoload . parse-time-string) (autoload . timezone-make-date-arpa-standard) (t . date-to-time) (defun . date-to-time) (t . seconds-to-time) (defun . seconds-to-time) (t . time-less-p) (defun . time-less-p) (t . days-to-time) ...) ("/usr/share/emacs/24.2/lisp/international/uni-mirrored.el") ("/usr/share/emacs/24.2/leim/leim-list.el" (autoload . ucs-input-activate) (autoload . hangul-input-method-activate)) ("/home/tj/gitclone/misc/subdirs.el") ("/usr/share/emacs/24.2/lisp/subdirs.el") ("/usr/share/emacs/24.2/lisp/tooltip.elc" tooltip-mode (defun . tooltip-mode) tooltip-delay tooltip-delay tooltip-short-delay tooltip-short-delay tooltip-recent-seconds tooltip-recent-seconds tooltip-hide-delay tooltip-hide-delay tooltip-x-offset ...) ("/usr/share/emacs/24.2/lisp/vc/ediff-hook.elc" menu-bar-ediff-misc-menu menu-bar-epatch-menu menu-bar-ediff-merge-menu menu-bar-ediff-menu (provide . ediff-hook)) ("/usr/share/emacs/24.2/lisp/vc/vc-hooks.elc" vc-ignore-vc-files vc-master-templates vc-ignore-dir-regexp vc-ignore-dir-regexp vc-handled-backends vc-handled-backends vc-directory-exclusion-list vc-directory-exclusion-list vc-make-backup-files vc-make-backup-files vc-follow-symlinks ...) ("/usr/share/emacs/24.2/lisp/emacs-lisp/float-sup.elc" float-pi pi float-e degrees-to-radians radians-to-degrees (defun . degrees-to-radians) (defun . radians-to-degrees) (provide . lisp-float-type)) ("/usr/share/emacs/24.2/lisp/mwheel.elc" (require . custom) (require . timer) (defun . mouse-wheel-change-button) mouse-wheel-down-button mouse-wheel-down-event mouse-wheel-down-event mouse-wheel-up-button mouse-wheel-up-event mouse-wheel-up-event mouse-wheel-click-button mouse-wheel-click-event ...) ...)
load-history
(("/home/tj/gitclone/org-mode/lisp/org-loaddefs.el" (autoload . org-babel-execute-safely-maybe) (autoload . org-babel-execute-maybe) (autoload . org-babel-view-src-block-info) (autoload . org-babel-expand-src-block-maybe) (autoload . org-babel-load-in-session-maybe) (autoload . org-babel-pop-to-session-maybe) (autoload . org-babel-execute-src-block) (autoload . org-babel-expand-src-block) (autoload . org-babel-check-src-block) (autoload . org-babel-insert-header-arg) (autoload . org-babel-load-in-session) ...) ("/home/tj/git/dotemacsd/abbrev_defs" Buffer-menu-mode-abbrev-table Custom-mode-abbrev-table Rd-mode-abbrev-table bbdb-mode-abbrev-table bibtex-mode-abbrev-table bookmark-bmenu-mode-abbrev-table calendar-mode-abbrev-table change-log-mode-abbrev-table comint-mode-abbrev-table completion-list-mode-abbrev-table diary-fancy-display-mode-abbrev-table ...) ("/usr/share/emacs/24.2/lisp/calendar/time-date.elc" (defun . with-decoded-time-value) (defun . encode-time-value) (autoload . parse-time-string) (autoload . timezone-make-date-arpa-standard) (t . date-to-time) (defun . date-to-time) (t . seconds-to-time) (defun . seconds-to-time) (t . time-less-p) (defun . time-less-p) (t . days-to-time) ...) ("/usr/share/emacs/24.2/lisp/international/uni-mirrored.el") ("/usr/share/emacs/24.2/leim/leim-list.el" (autoload . ucs-input-activate) (autoload . hangul-input-method-activate)) ("/home/tj/gitclone/misc/subdirs.el") ("/usr/share/emacs/24.2/lisp/subdirs.el") ("/usr/share/emacs/24.2/lisp/tooltip.elc" tooltip-mode (defun . tooltip-mode) tooltip-delay tooltip-delay tooltip-short-delay tooltip-short-delay tooltip-recent-seconds tooltip-recent-seconds tooltip-hide-delay tooltip-hide-delay tooltip-x-offset ...) ("/usr/share/emacs/24.2/lisp/vc/ediff-hook.elc" menu-bar-ediff-misc-menu menu-bar-epatch-menu menu-bar-ediff-merge-menu menu-bar-ediff-menu (provide . ediff-hook)) ("/usr/share/emacs/24.2/lisp/vc/vc-hooks.elc" vc-ignore-vc-files vc-master-templates vc-ignore-dir-regexp vc-ignore-dir-regexp vc-handled-backends vc-handled-backends vc-directory-exclusion-list vc-directory-exclusion-list vc-make-backup-files vc-make-backup-files vc-follow-symlinks ...) ("/usr/share/emacs/24.2/lisp/emacs-lisp/float-sup.elc" float-pi pi float-e degrees-to-radians radians-to-degrees (defun . degrees-to-radians) (defun . radians-to-degrees) (provide . lisp-float-type)) ("/usr/share/emacs/24.2/lisp/mwheel.elc" (require . custom) (require . timer) (defun . mouse-wheel-change-button) mouse-wheel-down-button mouse-wheel-down-event mouse-wheel-down-event mouse-wheel-up-button mouse-wheel-up-event mouse-wheel-up-event mouse-wheel-click-button mouse-wheel-click-event ...) ...)
(symbol-file 'org-release)
"org-version"
(org-reload)

-- 
cheers,
Thorsten

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Stelian Iancu]

On Jan 13, 2013, at 11:08 PM, Thorsten Jolitz <tjolitz@googlemail.com> wrote:

> Achim Gratz <Stromeko@nexgo.de> writes:
> 
>> Eric Schulte writes:
>>> Recently my Emacs start up fails when I (require 'org) because the
>>> function `org-load-noerror-mustsuffix' is undefined.  I was able to fix
>>> this by checking out the version previous to commit 5484a33b [1].
>> 
>> Your Emacs loads an outdated org-macs.el.  Additionally, you have no
>> autoloads generated in the Git work tree:
>> 
>>  *Messages*
>>  Loading /home/eschulte/.emacs.d/src/org-mode/lisp/org.el (source)...
>>  Package assoc is obsolete!
>>  Loading /home/eschulte/.emacs.d/elpa/org-20121231/org-loaddefs.el (source)...done
>>  Problems while trying to load feature `org-jsinfo'
>>  eval-buffer: Symbol's function definition is void: org-define-obsolete-function-alias
>> 
>> This makes Emacs pick up the (wrong) autoloads from the ELPA directory,
>> although the root cause for your failure is that Org has been partly
>> loaded before the load-path were pointing to the Git work tree and other
>> parts have been loaded after the load-path changed.  Please remove or
>> deactivate the ELPA package.
> 
> 
> I just updated Org-mode from Git a few minutes ago, and, after having
> problems, deleted the repo and cloned it again, ran make and make
> autoloads, but still cannot load org.el (or start with my usual
> starter-kit customisations):
> 

[SNIP]

Just my 2c: in my case, all I did was: 
- clone the git repo
- add org-mode/lisp to the load-path
- make autoloads
- require 'org

After that, M-x org-version returns the correct org version and path: Org-mode version 7.9.3c (release_7.9.3c-816-g409ee8 @ /Users/stelianiancu/.emacs-live-packs/orgmode-pack/lib/org-mode/lisp/)

Emacs version: GNU Emacs 24.2.92.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2013-01-10 on bob.porkrind.org

HTH, 
Stelian

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Thorsten Jolitz]

Stelian Iancu <lists@siancu.net> writes:

>> I just updated Org-mode from Git a few minutes ago, and, after having
>> problems, deleted the repo and cloned it again, ran make and make
>> autoloads, but still cannot load org.el (or start with my usual
>> starter-kit customisations):
>> 
>
> [SNIP]
>
> Just my 2c: in my case, all I did was: 
> - clone the git repo
> - add org-mode/lisp to the load-path
> - make autoloads
> - require 'org
>
> After that, M-x org-version returns the correct org version and path:
> Org-mode version 7.9.3c (release_7.9.3c-816-g409ee8 @
> /Users/stelianiancu/.emacs-live-packs/orgmode-pack/lib/org-mode/lisp/)
>
> Emacs version: GNU Emacs 24.2.92.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2013-01-10 on bob.porkrind.org

I my case, org is a symlink in the Emacs folder:

/usr/share/emacs/24.2/lisp/
  drwxr-xr-x  2 root root    4096 18. Nov 08:40 nxml
  drwxr-xr-x  2 root root    4096 18. Nov 08:40 obsolete
  lrwxrwxrwx  1 root root      26 30. Apr 2012  org -> /home/tj/gitclone/org-mode
  -rw-r--r--  1 root root   10926 23. Aug 07:33 outline.el.gz
  -rw-r--r--  1 root root   35745 24. Aug 11:58 outline.elc
  -rw-r--r--  1 root root    3151 23. Aug 07:33 

and the load-path points to this folder:

C-v load-path
...
"/usr/share/emacs/24.2/lisp/org" 
"/usr/share/emacs/24.2/lisp/org/contrib" 
"/usr/share/emacs/24.2/lisp/org/etc" 
"/usr/share/emacs/24.2/lisp/org/lisp" 
"/usr/share/emacs/24.2/lisp/org/mk" 
"/usr/share/emacs/24.2/lisp/org/testing" 
"/usr/share/emacs/24.2/lisp/org/contrib/babel" 
"/usr/share/emacs/24.2/lisp/org/contrib/lisp" 
"/usr/share/emacs/24.2/lisp/org/contrib/scripts" 
"/usr/share/emacs/24.2/lisp/org/etc/schema" 
"/usr/share/emacs/24.2/lisp/org/etc/styles" 
"/usr/share/emacs/24.2/lisp/org/testing/examples" 
"/usr/share/emacs/24.2/lisp/org/testing/jump" 
"/usr/share/emacs/24.2/lisp/org/testing/lisp" 
"/usr/share/emacs/24.2/lisp/org/contrib/babel/langs" 
"/usr/share/emacs/24.2/lisp/org/contrib/scripts/staticmathjax" 
"/usr/share/emacs/24.2/lisp/org/contrib/scripts/staticmathjax/chrome" 
"/usr/share/emacs/24.2/lisp/org/contrib/scripts/staticmathjax/defaults" 
"/usr/share/emacs/24.2/lisp/org/contrib/scripts/staticmathjax/chrome/content" 
"/usr/share/emacs/24.2/lisp/org/contrib/scripts/staticmathjax/defaults/preferences" 
...

this worked before.
If I try org-version or (require 'org), I always get:
Symbol's function definition is void: org-define-obsolete-function-alias

-- 
cheers,
Thorsten

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Eric Schulte]

Thorsten Jolitz <tjolitz@googlemail.com> writes:

> Stelian Iancu <lists@siancu.net> writes:
>
>>> I just updated Org-mode from Git a few minutes ago, and, after having
>>> problems, deleted the repo and cloned it again, ran make and make
>>> autoloads, but still cannot load org.el (or start with my usual
>>> starter-kit customisations):
>>> 
>>
>> [SNIP]
>>
>> Just my 2c: in my case, all I did was: 
>> - clone the git repo
>> - add org-mode/lisp to the load-path
>> - make autoloads
>> - require 'org
>>

If you are using the starter-kit, then Org-mode is required as the first
step of your Emacs initialization.  This is necessary so that the
`org-babel-load-file' function can be used to load your customization
from .org files.  In this case the best (only) way to ensure that the
most recent version of Org-mode is loaded is to add the path to your
Org-mode install to the emacs command line with something like the
following.

  emacs --eval "(add-to-list 'load-path \"~/src/org-mode/lisp/\")"

This may be simplified with a command line alias like the following.

  alias emacs="emacs --eval '(add-to-list (quote load-path) \"~/src/org-mode/lisp/\")'"

When I find time I plan to add this to the starter-kit documentation.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Thorsten Jolitz]

Eric Schulte <schulte.eric@gmail.com> writes:

> If you are using the starter-kit, then Org-mode is required as the first
> step of your Emacs initialization.  This is necessary so that the
> `org-babel-load-file' function can be used to load your customization
> from .org files.  In this case the best (only) way to ensure that the
> most recent version of Org-mode is loaded is to add the path to your
> Org-mode install to the emacs command line with something like the
> following.
>
>   emacs --eval "(add-to-list 'load-path \"~/src/org-mode/lisp/\")"
>
> This may be simplified with a command line alias like the following.
>
>   alias emacs="emacs --eval '(add-to-list (quote load-path) \"~/src/org-mode/lisp/\")'"
>
> When I find time I plan to add this to the starter-kit documentation.

That would be a good idea, I remember having exactly that problem in the
past using the starter-kit, but I worked it out somehow.

At the moment I seem to have a more basic problem, since starting with
emacs -Q the system knows about the org directory:

M-x locate-library RET org.el:
Library is file /usr/share/emacs/24.2/lisp/org/lisp/org.el

which is a symlink to /home/tj/gitclone/org-mode/lisp/org.el:

  /usr/share/emacs/24.2/lisp:
  drwxr-xr-x  2 root root    4096 18. Nov 08:40 obsolete
  lrwxrwxrwx  1 root root      26 30. Apr 2012  org -> /home/tj/gitclone/org-mode
  -rw-r--r--  1 root root   10926 23. Aug 07:33 outline.el.gz
  -rw-r--r--  1 root root   35745 24. Aug 11:58 outline.elc

but when I try to load org.el (e.g. from dired) I get an error. 

Evaluating (load-library "org.el") in the *scratch* buffer gave me a
better error message than before, so the problems seems to be in line
16185-16186 in org.el:

(org-define-obsolete-function-alias
  'org-days-to-time 'org-time-stamp-to-now "24.3")


Debugger entered--Lisp error: (void-function org-define-obsolete-function-alias)
  (org-define-obsolete-function-alias (quote org-days-to-time) (quote org-time-stamp-to-now) "24.3")
  eval-buffer(#<buffer  *load*> nil "/usr/share/emacs/24.2/lisp/org/lisp/org.el" nil t)  ; Reading at buffer position 623963
  load-with-code-conversion("/usr/share/emacs/24.2/lisp/org/lisp/org.el" "/usr/share/emacs/24.2/lisp/org/lisp/org.el" nil nil)
  load("org.el")
  load-library("org.el")
  eval((load-library "org.el") nil)
  eval-last-sexp-1(t)
  eval-last-sexp(t)
  eval-print-last-sexp()
  call-interactively(eval-print-last-sexp nil nil)


(symbol-file 'org-mode)
"/home/tj/gitclone/org-mode/lisp/org-loaddefs.el"

but 

(symbol-file 'org-define-obsolete-function-alias)
nil


-- 
cheers,
Thorsten

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Eric Schulte]

Thorsten Jolitz <tjolitz@googlemail.com> writes:

> Eric Schulte <schulte.eric@gmail.com> writes:
>
>> If you are using the starter-kit, then Org-mode is required as the first
>> step of your Emacs initialization.  This is necessary so that the
>> `org-babel-load-file' function can be used to load your customization
>> from .org files.  In this case the best (only) way to ensure that the
>> most recent version of Org-mode is loaded is to add the path to your
>> Org-mode install to the emacs command line with something like the
>> following.
>>
>>   emacs --eval "(add-to-list 'load-path \"~/src/org-mode/lisp/\")"
>>
>> This may be simplified with a command line alias like the following.
>>
>>   alias emacs="emacs --eval '(add-to-list (quote load-path) \"~/src/org-mode/lisp/\")'"
>>
>> When I find time I plan to add this to the starter-kit documentation.
>
> That would be a good idea, I remember having exactly that problem in the
> past using the starter-kit, but I worked it out somehow.
>
> At the moment I seem to have a more basic problem, since starting with
> emacs -Q the system knows about the org directory:
>
> M-x locate-library RET org.el:
> Library is file /usr/share/emacs/24.2/lisp/org/lisp/org.el
>

Org-mode is built into Emacs, so there will be an Org-mode in the load
path from the moment Emacs starts.  This is not a problem in and of
itself.

The important thing is to put the path to the Org-mode you want to use
on the front of the load path (either with the command line flag above
or with an `add-to-list' in your config) *before* the first time
Org-mode is required with a (require 'org).  That should be sufficient.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Thorsten Jolitz]

Eric Schulte <schulte.eric@gmail.com> writes:

> Thorsten Jolitz <tjolitz@googlemail.com> writes:
>
>> Eric Schulte <schulte.eric@gmail.com> writes:
>>
>>> If you are using the starter-kit, then Org-mode is required as the first
>>> step of your Emacs initialization.  This is necessary so that the
>>> `org-babel-load-file' function can be used to load your customization
>>> from .org files.  In this case the best (only) way to ensure that the
>>> most recent version of Org-mode is loaded is to add the path to your
>>> Org-mode install to the emacs command line with something like the
>>> following.
>>>
>>>   emacs --eval "(add-to-list 'load-path \"~/src/org-mode/lisp/\")"
>>>
>>> This may be simplified with a command line alias like the following.
>>>
>>>   alias emacs="emacs --eval '(add-to-list (quote load-path) \"~/src/org-mode/lisp/\")'"
>>>
>>> When I find time I plan to add this to the starter-kit documentation.
>>
>> That would be a good idea, I remember having exactly that problem in the
>> past using the starter-kit, but I worked it out somehow.
>>
>> At the moment I seem to have a more basic problem, since starting with
>> emacs -Q the system knows about the org directory:
>>
>> M-x locate-library RET org.el:
>> Library is file /usr/share/emacs/24.2/lisp/org/lisp/org.el
>>
>
> Org-mode is built into Emacs, so there will be an Org-mode in the load
> path from the moment Emacs starts.  This is not a problem in and of
> itself.

I do have my bad experiences with mixed installations, so the first
thing I do when I install or update Emacs is to trash the Org-mode that
comes with Emacs and replace it with a symlink to the git version. 

> The important thing is to put the path to the Org-mode you want to use
> on the front of the load path (either with the command line flag above
> or with an `add-to-list' in your config) *before* the first time
> Org-mode is required with a (require 'org).  That should be sufficient.

Now I started Emacs with:

$ emacs --eval "(add-to-list 'load-path \"~/gitclone/org-mode/lisp/\")"

and the load-path looks like this:

load-path
("~/gitclone/org-mode/lisp/" "/home/tj/.emacs.d/elpa/auctex-11.86/"...)

but nevertheless, opening an .org file gives me:
File mode specification error:
(void-function org-define-obsolete-function-alias)

So this seems to be a different problem, maybe related to this recent
message from Paul Sexton:

From: Paul Sexton <psexton.2a@gmail.com>
Subject: Re: Fixes for org-capture-templates-contexts
Newsgroups: gmane.emacs.orgmode
To: emacs-orgmode@gnu.org
Date: Mon, 14 Jan 2013 22:21:20 +0000 (UTC) (13 hours, 8 minutes ago)

(...)
Also, very important. I updated to master in order to make the patch and found
the current orgmode does not compile or even load. This is because
ob-eval.el uses 'declare-function' which is undefined (it is defined in
org-macs.el but ob-eval.el does not require that file).
(...)

-- 
cheers,
Thorsten

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Nick Dokos]

Thorsten Jolitz <tjolitz@googlemail.com> wrote:

> Eric Schulte <schulte.eric@gmail.com> writes:
> 
> > Thorsten Jolitz <tjolitz@googlemail.com> writes:
> >
> >> Eric Schulte <schulte.eric@gmail.com> writes:
> >>
> >>> If you are using the starter-kit, then Org-mode is required as the first
> >>> step of your Emacs initialization.  This is necessary so that the
> >>> `org-babel-load-file' function can be used to load your customization
> >>> from .org files.  In this case the best (only) way to ensure that the
> >>> most recent version of Org-mode is loaded is to add the path to your
> >>> Org-mode install to the emacs command line with something like the
> >>> following.
> >>>
> >>>   emacs --eval "(add-to-list 'load-path \"~/src/org-mode/lisp/\")"
> >>>
> >>> This may be simplified with a command line alias like the following.
> >>>
> >>>   alias emacs="emacs --eval '(add-to-list (quote load-path) \"~/src/org-mode/lisp/\")'"
> >>>
> >>> When I find time I plan to add this to the starter-kit documentation.
> >>
> >> That would be a good idea, I remember having exactly that problem in the
> >> past using the starter-kit, but I worked it out somehow.
> >>
> >> At the moment I seem to have a more basic problem, since starting with
> >> emacs -Q the system knows about the org directory:
> >>
> >> M-x locate-library RET org.el:
> >> Library is file /usr/share/emacs/24.2/lisp/org/lisp/org.el
> >>
> >
> > Org-mode is built into Emacs, so there will be an Org-mode in the load
> > path from the moment Emacs starts.  This is not a problem in and of
> > itself.
> 
> I do have my bad experiences with mixed installations, so the first
> thing I do when I install or update Emacs is to trash the Org-mode that
> comes with Emacs and replace it with a symlink to the git version. 
> 
> > The important thing is to put the path to the Org-mode you want to use
> > on the front of the load path (either with the command line flag above
> > or with an `add-to-list' in your config) *before* the first time
> > Org-mode is required with a (require 'org).  That should be sufficient.
> 
> Now I started Emacs with:
> 
> $ emacs --eval "(add-to-list 'load-path \"~/gitclone/org-mode/lisp/\")"
> 
> and the load-path looks like this:
> 
> load-path
> ("~/gitclone/org-mode/lisp/" "/home/tj/.emacs.d/elpa/auctex-11.86/"...)
> 
> but nevertheless, opening an .org file gives me:
> File mode specification error:
> (void-function org-define-obsolete-function-alias)
> 

There is no such function in current org (either defined or used). The
remaining instance was deleted in this commit:

,----
| commit 655ba9f9391e9dafb72a97cea1e327692ac83855
| Author: Nicolas Goaziou <n.goaziou@gmail.com>
| Date:   Sun Jan 13 20:58:21 2013 +0100
| 
|     Remove left-over `org-define-obsolete-function-alias'
`----

which you probably don't have. Update org would be my advice.

Nick

> So this seems to be a different problem, maybe related to this recent
> message from Paul Sexton:
> 
> From: Paul Sexton <psexton.2a@gmail.com>
> Subject: Re: Fixes for org-capture-templates-contexts
> Newsgroups: gmane.emacs.orgmode
> To: emacs-orgmode@gnu.org
> Date: Mon, 14 Jan 2013 22:21:20 +0000 (UTC) (13 hours, 8 minutes ago)
> 
> (...)
> Also, very important. I updated to master in order to make the patch and found
> the current orgmode does not compile or even load. This is because
> ob-eval.el uses 'declare-function' which is undefined (it is defined in
> org-macs.el but ob-eval.el does not require that file).
> (...)
> 
> -- 
> cheers,
> Thorsten
> 
> 

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Thorsten Jolitz]

Nick Dokos <nicholas.dokos@hp.com> writes:

>> but nevertheless, opening an .org file gives me:
>> File mode specification error:
>> (void-function org-define-obsolete-function-alias)
>> 
>
> There is no such function in current org (either defined or used). The
> remaining instance was deleted in this commit:
>
> ,----
> | commit 655ba9f9391e9dafb72a97cea1e327692ac83855
> | Author: Nicolas Goaziou <n.goaziou@gmail.com>
> | Date:   Sun Jan 13 20:58:21 2013 +0100
> | 
> |     Remove left-over `org-define-obsolete-function-alias'
> `----
>
> which you probably don't have. Update org would be my advice.

Updating again solved the problem, thanks. So I simply had the bad luck
to update my Org-mode at the very moment when the actual org.el wouldn't
load due to some forgotten left-over in the file.

-- 
cheers,
Thorsten

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Nick Dokos]

Thorsten Jolitz <tjolitz@googlemail.com> wrote:

> Nick Dokos <nicholas.dokos@hp.com> writes:
> 
> >> but nevertheless, opening an .org file gives me:
> >> File mode specification error:
> >> (void-function org-define-obsolete-function-alias)
> >> 
> >
> > There is no such function in current org (either defined or used). The
> > remaining instance was deleted in this commit:
> >
> > ,----
> > | commit 655ba9f9391e9dafb72a97cea1e327692ac83855
> > | Author: Nicolas Goaziou <n.goaziou@gmail.com>
> > | Date:   Sun Jan 13 20:58:21 2013 +0100
> > | 
> > |     Remove left-over `org-define-obsolete-function-alias'
> > `----
> >
> > which you probably don't have. Update org would be my advice.
> 
> Updating again solved the problem, thanks. So I simply had the bad luck
> to update my Org-mode at the very moment when the actual org.el wouldn't
> load due to some forgotten left-over in the file.
> 

Exactly.

Nick

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Achim Gratz]

Thorsten Jolitz writes:
> I do have my bad experiences with mixed installations, so the first
> thing I do when I install or update Emacs is to trash the Org-mode that
> comes with Emacs and replace it with a symlink to the git version. 

What you do doesn't work the way you think it does, since you're not
updating loaddefs.el — you've created a train wreck waiting to happen.
Leave the Emacs install alone and properly install Org into site-lisp.



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

Re: [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Thorsten Jolitz]

Achim Gratz <Stromeko@nexgo.de> writes:

> Thorsten Jolitz writes:
>> I do have my bad experiences with mixed installations, so the first
>> thing I do when I install or update Emacs is to trash the Org-mode that
>> comes with Emacs and replace it with a symlink to the git version. 
>
> What you do doesn't work the way you think it does, since you're not
> updating loaddefs.el — you've created a train wreck waiting to happen.
> Leave the Emacs install alone and properly install Org into site-lisp.

I would rather not like to see that train wreck. 

Which loaddefs.el do you refer to? This one:

  ,--------------------------------------------------------------------------------
  | /usr/share/emacs/24.2/lisp:
  | -rw-r--r--  1 root root 1265779 18. Nov 08:38 loaddefs.el
  | ...
  | lrwxrwxrwx  1 root root      26 30. Apr 2012  org -> /home/tj/gitclone/org-mode
  `--------------------------------------------------------------------------------

or this one:

,-----------------------------------------------
| home/tj/gitclone/org-mode/lisp/org-loaddefs.el
`-----------------------------------------------

I don't know which one is updated when I run 'make autoloads' in
'home/tj/gitclone/org-mode/', but even if the
'/usr/share/emacs/24.2/lisp/loaddefs.el' doesn't get updated in the
process, where is the desaster looming if there is only one single
Org-mode installation on the machine? And what about runnung 'make
autoloads' in ' /usr/share/emacs/24.2/lisp' after replacing the org
folder with a symlink?

I would like to understand this better to avoid future trouble. 

-- 
cheers,
Thorsten