web site bug

web site bug

[Robert Klein]

Hi,

on the web site, the link to the HTML version of the compact guide
actually links to the full manual.

(http://orgmode.org/index.html#sec-4_1 first link)

Best regards
Robert

Re: web site bug

[David Maus]

[-- Attachment #1.1: Type: text/plain, Size: 337 bytes --]

Robert Klein wrote:
>on the web site, the link to the HTML version of the compact guide
>actually links to the full manual.

>(http://orgmode.org/index.html#sec-4_1 first link)

Thanks for reporting.  Seems this is already fixed.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de

[-- Attachment #1.2: Type: application/pgp-signature, Size: 230 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Web site bug

[Simon Thum]

Hi,

I just set up another machine and noticed that the ELPA install still 
recommends (require 'org-install).

http://orgmode.org/elpa.html

That worked but got me warnings.

Cheers,

Simon

Re: Web site bug

[Bastien]

Hi Simon,

Simon Thum <simon.thum@gmx.de> writes:

> I just set up another machine and noticed that the ELPA install still
> recommends (require 'org-install).
>
> http://orgmode.org/elpa.html
>
> That worked but got me warnings.

I added a note about (require 'org-install) not being required for
Org > 7.9.2 -- thanks!

-- 
 Bastien

Re: Web site bug

[Simon Thum]

On 10/25/2012 12:42 AM, Bastien wrote:
> Hi Simon,
>
> Simon Thum<simon.thum@gmx.de>  writes:
>
>> I just set up another machine and noticed that the ELPA install still
>> recommends (require 'org-install).
>>
>> http://orgmode.org/elpa.html
>>
>> That worked but got me warnings.
>
> I added a note about (require 'org-install) not being required for
> Org>  7.9.2 -- thanks!
>
Sorry but to me this just worsens the (or my) confusion around org-install.

In git we find this org-install.el:

;;; org-install.el --- autogenerated file, do not edit
;;
;;; Code:
(warn "The file org-install is obsolete.
Please change your configuration to (require 'org) instead.")

Apart from it not being autogenerated, it's confusing that I should use 
'org instead.

Which is the recommended thing in what setup? If ELPA needs not even 
'org, which AFAIK is not the case, then what? And what about git installs?

I guess I'm wholly confused now.

Cheers,

Simon

Re: Web site bug

[Bastien]

Hi Simon,

Simon Thum <simon.thum@gmx.de> writes:

> Sorry but to me this just worsens the (or my) confusion around
> org-install.
>
> In git we find this org-install.el:
>
> ;;; org-install.el --- autogenerated file, do not edit
> ;;
> ;;; Code:
> (warn "The file org-install is obsolete.
> Please change your configuration to (require 'org) instead.")

Yes, this was confusing.  I updated this file like this

  ;;; org-install.el --- backward compatibility file for obsolete configuration
  ;;
  ;;; Code:
  (warn "The file org-install is obsolete.
  It is provided here so that (require 'org-install) does not
  trigger an error for users with obsolete Emacs configuration.
  You can safely remove (require 'org-install) from your config.")
  
  (provide 'org-install)
  
  ;; Local Variables:
  ;; no-byte-compile: t
  ;; coding: utf-8
  ;; End:
  ;;; org-install.el ends here

I hope it is clearer.

> Apart from it not being autogenerated, it's confusing that I should use
> org instead.

Indeed.  The main message is: you don't need (require 'org-install)
anymore.  It used to be needed to get the correct autoloads but it is
not anymore, as autoloads are taken from org-autoloads.el, which is
either provided (in the distrib tar.gz/zip archives) or dynamically
generated (from "make").

> Which is the recommended thing in what setup? If ELPA needs not even 'org,
> which AFAIK is not the case, then what? And what about git installs?

If you use Org from Emacs, you don't need anything.

If you use Org from the distribution archives, you need to add the
directory with the extracted directory in your load-path and to add
(require 'org) after adding the Org directory to the load-path.

If you use Org from git, you need the above plus runing "make" or
"make autoloads" so that the correct autoloads are loaded.

If you use Org from ELPA, you just need to add (package-initialize)
before any Org configuration of the type (setq org-* ...).

> I guess I'm wholly confused now.

I hope I helped to clarify things.

I also remove any reference to org-install in
http://orgmode.org/elpa.html since the ELPA archive is produced
from maint, which is >7.9.2 anyway.

Thanks for the heads up,

-- 
 Bastien

Re: Web site bug

[Achim Gratz]

Simon Thum writes:
> Which is the recommended thing in what setup? If ELPA needs not even
> org, which AFAIK is not the case, then what? And what about git
> installs?
>
> I guess I'm wholly confused now.

You never needed to do anything extra for using Org as it comes with
Emacs, the autoloads are automatically loaded from loaddefs.el.  The
distribution contained an empty org-install for ease of transition.

The package manager generates and loads its own autoload file
(org-autoloads.el, it also re-generates org-loaddefs.el in 7.9.2 and
later), so again you don't need to do anything extra there.

If you were using a seperate Org install (from tarball or Git),
org-install needed to be loaded for getting the correct autoload
definitions.  With the introduction of org-loaddefs, things have become
muddled: in Emacs and with package manager, org-loaddefs only contains
those autoload definitions that become available _after_ Org has been
loaded, and the generally visible autoloads come from either loaddefs.el
or org-autoloads.el respectively.  The standalone Org does not have a
second autoload file for these first level autoloads, so they are rolled
into org-loaddefs as well.  As a result, you must now load org (which in
turn loads org-loaddefs).  I still think it would be better if Org had a
separate first-level autoloads file that must be explicitly required by
the user (and it would probably be easiest if it was still called
org-install).


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: Web site bug

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> As a result, you must now load org (which in turn loads org-loaddefs).

I don't think so.

With a fresh git clone in e.g. ~/org-mode/ and "make autoloads", 
or with the tar/zip archive unpacked in this directory, I get the
correct autoloads without (require 'org).  Here is how to reproduce:

1. emacs -Q
2. M-: (add-to-list 'load-path "~/org-mode/lisp/") RET
3. C-h f org-agenda RET

This will refer to the definition of org-agenda from the 
~/org-mode/lisp/org-agenda.el.

This is with a fresh Emacs (24.2.50.1) but should be the same with
older version.

-- 
 Bastien

Re: Web site bug

[Sebastien Vauban]

Hi Bastien,

Bastien wrote:
>> ;;; Code:
>> (warn "The file org-install is obsolete.
>> Please change your configuration to (require 'org) instead.")
>
> Yes, this was confusing.  I updated this file like this
>
>   ;;; org-install.el --- backward compatibility file for obsolete configuration
>   ;;
>   ;;; Code:
>   (warn "The file org-install is obsolete.
>   It is provided here so that (require 'org-install) does not
>   trigger an error for users with obsolete Emacs configuration.
>   You can safely remove (require 'org-install) from your config.")

Wouldn't it be better to tell users to require 'org-loaddefs instead, so that
they don't have a performance penalty when loading their .emacs file, until
they really access Org -- if they do, in that session?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Web site bug

[Bastien]

Hi Sébastien,

"Sebastien Vauban"
<wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:

> Wouldn't it be better to tell users to require 'org-loaddefs instead

No, (require 'org-loaddefs) is never needed IMHO.

> , so that
> they don't have a performance penalty when loading their .emacs file, until
> they really access Org -- if they do, in that session?

The "penalty" comes from requiring org explicitely but I don't see
why you would need to require org explicitely anyway.  Do you have
a use case example?

-- 
 Bastien

Re: Web site bug

[Achim Gratz]

Bastien writes:
> Achim Gratz <Stromeko@nexgo.de> writes:
>
>> As a result, you must now load org (which in turn loads org-loaddefs).
>
> I don't think so.

Fake an autoload refering to some non-existing file or function in
org-loaddefs.el in the Git worktree and try if you see that without
doing a (require 'org).  That some of the autoloads that come with Emacs
happen to fall back onto the correct file via load-path is not something
you want to rely on.  That aside, there have been quite a few changes
from at least Emacs 23 that moved functions to different files and/or
changed their signature.


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: Web site bug

[Simon Thum]

Hi Bastien,

thanks a lot for clarifying this. One nit left, see below.

I'm having a look at putting a summary in worg.

Thanks,

Simon

On 10/27/2012 09:33 AM, Bastien wrote:
> Hi Simon,
>
> Simon Thum<simon.thum@gmx.de>  writes:
>
>> Sorry but to me this just worsens the (or my) confusion around
>> org-install.
>>
>> In git we find this org-install.el:
>>
>> ;;; org-install.el --- autogenerated file, do not edit
>> ;;
>> ;;; Code:
>> (warn "The file org-install is obsolete.
>> Please change your configuration to (require 'org) instead.")
>
> Yes, this was confusing.  I updated this file like this
>
>    ;;; org-install.el --- backward compatibility file for obsolete configuration
>    ;;
>    ;;; Code:
>    (warn "The file org-install is obsolete.
>    It is provided here so that (require 'org-install) does not
>    trigger an error for users with obsolete Emacs configuration.
>    You can safely remove (require 'org-install) from your config.")

Judging from what you say further down there are use-cases left where 
this is bad advice, namely the distribution archives and git.


>
>    (provide 'org-install)
>
>    ;; Local Variables:
>    ;; no-byte-compile: t
>    ;; coding: utf-8
>    ;; End:
>    ;;; org-install.el ends here
>
> I hope it is clearer.
>
>> Apart from it not being autogenerated, it's confusing that I should use
>> org instead.
>
> Indeed.  The main message is: you don't need (require 'org-install)
> anymore.  It used to be needed to get the correct autoloads but it is
> not anymore, as autoloads are taken from org-autoloads.el, which is
> either provided (in the distrib tar.gz/zip archives) or dynamically
> generated (from "make").
>
>> Which is the recommended thing in what setup? If ELPA needs not even 'org,
>> which AFAIK is not the case, then what? And what about git installs?
>
> If you use Org from Emacs, you don't need anything.
>
> If you use Org from the distribution archives, you need to add the
> directory with the extracted directory in your load-path and to add
> (require 'org) after adding the Org directory to the load-path.
>
> If you use Org from git, you need the above plus runing "make" or
> "make autoloads" so that the correct autoloads are loaded.
>
> If you use Org from ELPA, you just need to add (package-initialize)
> before any Org configuration of the type (setq org-* ...).
>
>> I guess I'm wholly confused now.
>
> I hope I helped to clarify things.
>
> I also remove any reference to org-install in
> http://orgmode.org/elpa.html since the ELPA archive is produced
> from maint, which is>7.9.2 anyway.
>
> Thanks for the heads up,
>

Re: Web site bug

[Bastien]

Hi Simon,

Simon Thum <simon.thum@gmx.de> writes:

>>    ;;; org-install.el --- backward compatibility file for obsolete configuration
>>    ;;
>>    ;;; Code:
>>    (warn "The file org-install is obsolete.
>>    It is provided here so that (require 'org-install) does not
>>    trigger an error for users with obsolete Emacs configuration.
>>    You can safely remove (require 'org-install) from your config.")
>
> Judging from what you say further down there are use-cases left where this
> is bad advice, namely the distribution archives and git.

People using Org from the distribution archives don't get this warning
because the distribution archive still use the old way, org-install.el
containing autoloads when "make autoloads" is run.

People using from Git don't need (require 'org-install), and the
org-install.el provided in a Git clone is empty (not auto-generated),
with just this warning.

I hope this clarifies further :)

-- 
 Bastien

Re: Web site bug

[Achim Gratz]

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

Bastien writes:
> No, (require 'org-loaddefs) is never needed IMHO.

It is if you are using Org from Git and you only want the autoload
definitions pulled in on startup and not the whole of Org plus most of
its dependencies.  This is what a

(require 'org-install)

did before the change to org-loaddefs.el.  You can't rely on some older
Org version in Emacs or whereever to supply the correct autoload
definitions, so you eitehr need to

(require 'org-loaddefs)

which is horribly wrong in case you're not sing Org from Git; or

(require 'org)

which is pulling in too much stuff on startup.

Org from Git is currently missing the first-level autoloads file that
was implicitly introduced for all other use-cases with that change
(loaddefs.el for vanilla Emacs and org-autoloads.el for package
manager).  I propose to re-introduce org-install.el for this purpose for
standalone Org.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Re-introduce-org-install.el.patch --]
[-- Type: text/x-patch, Size: 3017 bytes --]

From 6b2d3f7689078f836cf1dbd8ee508131e8b22ef5 Mon Sep 17 00:00:00 2001
From: Achim Gratz <Stromeko@Stromeko.DE>
Date: Sun, 28 Oct 2012 08:23:22 +0100
Subject: [PATCH] Re-introduce org-install.el

* lisp/org-install.el: Delete from version control, is autogenerated
  again.  An empty file should be provided in Emacs and for ELPA as
  before.

* mk/org-fixup.el (org-make-org-loaddefs): Arrange for org-install to
  collect the "first-level" autoload definitions for standalone
  Org (like loaddefs.el for Emacs and org-autoloads.el for package
  manager).  The autoloads in org-loaddefs.el will be identical
  "second-level" for all installations.  The "first-level" autoload
  definitions are automatically loaded by EMacs or package manager,
  respectively.  For standalone Org, the user has to "(require
  'org-install)", as has been customary.

FIXME: this implementation does not support XEmacs.
---
 lisp/org-install.el | 13 -------------
 mk/org-fixup.el     | 15 ++++-----------
 2 files changed, 4 insertions(+), 24 deletions(-)
 delete mode 100644 lisp/org-install.el

diff --git a/lisp/org-install.el b/lisp/org-install.el
deleted file mode 100644
index a31d8b7..0000000
--- a/lisp/org-install.el
+++ /dev/null
@@ -1,13 +0,0 @@
-;;; org-install.el --- autogenerated file, do not edit
-;;
-;;; Code:
-(warn "The file org-install is obsolete.
-Please change your configuration to (require 'org) instead.")
-\f
-(provide 'org-install)
-\f
-;; Local Variables:
-;; no-byte-compile: t
-;; coding: utf-8
-;; End:
-;;; org-install.el ends here
diff --git a/mk/org-fixup.el b/mk/org-fixup.el
index 7b59efb..e5dee9a 100644
--- a/mk/org-fixup.el
+++ b/mk/org-fixup.el
@@ -67,17 +67,10 @@ (defun org-make-org-loaddefs ()
 be used by foreign build systems or installers to produce this
 file in the installation directory of org-mode.  Org will not
 work correctly if this file is not up-to-date."
-  (with-temp-buffer
-    (set-visited-file-name "org-loaddefs.el")
-    (insert ";;; org-loaddefs.el --- autogenerated file, do not edit\n;;\n;;; Code:\n")
-    (let ((files (directory-files default-directory nil "^\\(org\\|ob\\)\\(-.*\\)?\\.el$")))
-      (mapc (lambda (f) (generate-file-autoloads f)) files))
-    (insert "\f\n(provide 'org-loaddefs)\n")
-    (insert "\f\n;; Local Variables:\n;; version-control: never\n")
-    (insert ";; no-byte-compile: t\n;; no-update-autoloads: t\n")
-    (insert ";; coding: utf-8\n;; End:\n;;; org-loaddefs.el ends here\n")
-    (toggle-read-only 0)
-    (save-buffer)))
+  (write-region (autoload-rubric "org-install.el" nil "org-install") nil "org-install.el")
+  (write-region (autoload-rubric "org-loaddefs.el" nil "org-loaddefs") nil "org-install.el")
+  (let ((generated-autoload-file (expand-file-name "org-install.el" default-directory)))
+    (update-directory-autoloads (file-name-directory generated-autoload-file))))
 
 (defun org-make-autoloads (&optional compile force)
   "Make the files org-loaddefs.el and org-version.el in the install directory.
-- 
1.8.0


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




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: Web site bug

[Bastien]

Hi Achim,

Achim Gratz <Stromeko@nexgo.de> writes:

> It is if you are using Org from Git and you only want the autoload
> definitions pulled in on startup and not the whole of Org plus most of
> its dependencies.  This is what a
>
> (require 'org-install)
>
> did before the change to org-loaddefs.el.  You can't rely on some older
> Org version in Emacs or whereever to supply the correct autoload
> definitions, so you eitehr need to
>
> (require 'org-loaddefs)
>
> which is horribly wrong in case you're not using Org from Git; 

You mean "in case users install Org from a tar/zip archive that does
not contain org-loaddefs.el"?

For now the tar/zip archives does not contain org-loaddefs.el but it
will starting from Org 7.9.3.

(require 'org-loaddefs) is wrong in case users who cloned Org from Git
forget to "make" or "make autoloads".  It is just as wrong as (require
'org-install) was previously.  No?

> or
>
> (require 'org)
>
> which is pulling in too much stuff on startup.
>
> Org from Git is currently missing the first-level autoloads file that
> was implicitly introduced for all other use-cases with that change
> (loaddefs.el for vanilla Emacs and org-autoloads.el for package
> manager).  

You mean Org from Git is missing the org-loaddefs.el that is produced 
by "make" or "make autoloads"?

Yes, I don't think this is a problem. 

> I propose to re-introduce org-install.el for this purpose for
> standalone Org.

I don't really understand what this is supposed to fix... ?

> From 6b2d3f7689078f836cf1dbd8ee508131e8b22ef5 Mon Sep 17 00:00:00 2001
> From: Achim Gratz <Stromeko@Stromeko.DE>
> Date: Sun, 28 Oct 2012 08:23:22 +0100
> Subject: [PATCH] Re-introduce org-install.el
>
> * lisp/org-install.el: Delete from version control, is autogenerated
>   again.  An empty file should be provided in Emacs and for ELPA as
>   before.
>
> * mk/org-fixup.el (org-make-org-loaddefs): Arrange for org-install to
>   collect the "first-level" autoload definitions for standalone
>   Org (like loaddefs.el for Emacs and org-autoloads.el for package
>   manager).  The autoloads in org-loaddefs.el will be identical
>   "second-level" for all installations.  The "first-level" autoload
>   definitions are automatically loaded by EMacs or package manager,
>   respectively.  For standalone Org, the user has to "(require
>   'org-install)", as has been customary.
>
> FIXME: this implementation does not support XEmacs.
> ---
>  lisp/org-install.el | 13 -------------
>  mk/org-fixup.el     | 15 ++++-----------
>  2 files changed, 4 insertions(+), 24 deletions(-)
>  delete mode 100644 lisp/org-install.el
>
> diff --git a/lisp/org-install.el b/lisp/org-install.el
> deleted file mode 100644
> index a31d8b7..0000000
> --- a/lisp/org-install.el
> +++ /dev/null
> @@ -1,13 +0,0 @@
> -;;; org-install.el --- autogenerated file, do not edit
> -;;
> -;;; Code:
> -(warn "The file org-install is obsolete.
> -Please change your configuration to (require 'org) instead.")
> -\f
> -(provide 'org-install)
> -\f
> -;; Local Variables:
> -;; no-byte-compile: t
> -;; coding: utf-8
> -;; End:
> -;;; org-install.el ends here
> diff --git a/mk/org-fixup.el b/mk/org-fixup.el
> index 7b59efb..e5dee9a 100644
> --- a/mk/org-fixup.el
> +++ b/mk/org-fixup.el
> @@ -67,17 +67,10 @@ (defun org-make-org-loaddefs ()
>  be used by foreign build systems or installers to produce this
>  file in the installation directory of org-mode.  Org will not
>  work correctly if this file is not up-to-date."
> -  (with-temp-buffer
> -    (set-visited-file-name "org-loaddefs.el")
> -    (insert ";;; org-loaddefs.el --- autogenerated file, do not edit\n;;\n;;; Code:\n")
> -    (let ((files (directory-files default-directory nil "^\\(org\\|ob\\)\\(-.*\\)?\\.el$")))
> -      (mapc (lambda (f) (generate-file-autoloads f)) files))
> -    (insert "\f\n(provide 'org-loaddefs)\n")
> -    (insert "\f\n;; Local Variables:\n;; version-control: never\n")
> -    (insert ";; no-byte-compile: t\n;; no-update-autoloads: t\n")
> -    (insert ";; coding: utf-8\n;; End:\n;;; org-loaddefs.el ends here\n")
> -    (toggle-read-only 0)
> -    (save-buffer)))
> +  (write-region (autoload-rubric "org-install.el" nil "org-install") nil "org-install.el")
> +  (write-region (autoload-rubric "org-loaddefs.el" nil "org-loaddefs") nil "org-install.el")
                    ^^^^^^^^^^^^^^^

I don't know what "autoload-rubric" is.  Hint?

Thanks,

-- 
 Bastien

Re: Web site bug

[Achim Gratz]

Bastien writes:
> You mean "in case users install Org from a tar/zip archive that does
> not contain org-loaddefs.el"?
>
> For now the tar/zip archives does not contain org-loaddefs.el but it
> will starting from Org 7.9.3.
>
> (require 'org-loaddefs) is wrong in case users who cloned Org from Git
> forget to "make" or "make autoloads".  It is just as wrong as (require
> 'org-install) was previously.  No?

No, (require 'org-loaddefs) is wrong, plain and simple.  Except of
course when you want to just get the autoloads for an Org from Git
installation, since then _all_ autoloads for Org are in this file.

> You mean Org from Git is missing the org-loaddefs.el that is produced 
> by "make" or "make autoloads"?

No, it has _all_ autoloads in the same file, all other installations
split the autoloads between two files (and automatically load the first
and you never need to take care about the second).

> Yes, I don't think this is a problem. 

But it is a problem.

> I don't really understand what this is supposed to fix... ?

It splits the autoload definitions into two files like all other
installations.  Almost everybody can then safely forget about
org-loaddefs (since it is taken care of in org itself) and only needs to
load org-install for Org from Git.


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: Web site bug

[Bastien]

Hi Achim,

Bastien <bzg@altern.org> writes:

>> +  (write-region (autoload-rubric "org-install.el" nil "org-install") nil "org-install.el")
>> +  (write-region (autoload-rubric "org-loaddefs.el" nil "org-loaddefs") nil "org-install.el")
>
> I don't know what "autoload-rubric" is.  Hint?

You didn't reply to this comment.

What is "autoload-rubric"?

-- 
 Bastien

Re: Web site bug

[Bastien]

Hi Achim,

let's start fresh.

Can you point at an actual reproducible and simple bug with
the current way Org defines autoloads?

Thanks,

-- 
 Bastien

Re: Web site bug

[Achim Gratz]

Bastien writes:
> What is "autoload-rubric"?

C-h f autoload-rubric

autoload-rubric is a compiled Lisp function in `autoload.el'.

(autoload-rubric FILE &optional TYPE FEATURE)

Return a string giving the appropriate autoload rubric for FILE.
TYPE (default "autoloads") is a string stating the type of
information contained in FILE.  If FEATURE is non-nil, FILE
will provide a feature.  FEATURE may be a string naming the
feature, otherwise it will be based on FILE's name.

At present, a feature is in fact always provided, but this should
not be relied upon.


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: Web site bug

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> Bastien writes:
>> What is "autoload-rubric"?
>
> C-h f autoload-rubric
>
> autoload-rubric is a compiled Lisp function in `autoload.el'.

Thanks.  The function is not autoloaded, so I had to
(require 'autoload) before being able to access it.

-- 
 Bastien

Re: Web site bug

[Achim Gratz]

Bastien writes:
> Can you point at an actual reproducible and simple bug with
> the current way Org defines autoloads?

After the introduction of org-loaddefs, the autoloads should be
extracted into two files and only the first is supposed to be loaded
before org is actually used and the second, org-loaddefs, is supposed to
be loaded by Org itself.  But when using a standalone Org, that first
file doesn't exist and there's no mechanism for the generated autoloads
(all in org-loaddefs) to be loaded before Org is used.

You suggest that in a standalone installation the user doesn't need to
do anything by way of customization: that's a bug, because the autoloads
in org-loaddefs for the standalone Org are not present _at all_ in that
situation.  That there may be some autoloads present from another Org
version (from Emacs) that by accident may point to a file that will then
cause Org to be loaded anyway doesn't make this bug go away.

Standalone Org needs a file separate from org-loaddefs to collect the
autoload definitions into that will be loaded on startup.  For Emacs,
this is loaddefs; for package manager, this is org-autoloads; for Org
standalone, I posit that we should keep org-install.  If we keep a
different system of how to handle autoloads depending on the type of
installation, then it will be impossible to test that everything works
correctly[1], not to mention the confusion that this discussion so amply
demonstrates.


[1] For instance, any first-level autoloaded function that somehow calls
into these files:

ob, ob-keys, ob-lob, ob-tangle, org-archive, org-ascii, org-attach,
org-bbdb, org-clock, org-datetree, org-docbook, org-element, org-exp,
org-feed, org-footnote, org-freemind, org-html, org-icalendar, org-id,
org-indent, org-irc, org-latex, org-lparse, org-mobile, org-odt,
org-plot, org-publish, org-remember, org-table, org-taskjuggler,
org-timer, org-xoxo

needs to make sure that org-loaddefs has been loaded, which currently
only happens in org, but I have not been able to ascertain that each
codepath to one of these functions will actually go through it.


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: Web site bug

[Bastien]

Sorry, maybe I was unclear, but I'm looking forward to reading
a *recipe* to reproduce the bug.

I will re-read your email when I have time to parse it in full
details.

Thanks,

-- 
 Bastien

Re: Web site bug

[Achim Gratz]

Bastien writes:
> Sorry, maybe I was unclear, but I'm looking forward to reading
> a *recipe* to reproduce the bug.

Build an Emacs without Org or remove all autoload forms for Org from
loaddefs.el, then install a standalone Org and don't add any requires to
the startup files.  Try to use any Org function that should be
autoloaded.


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: Web site bug

[Eric S Fraga]

Bastien <bzg@altern.org> writes:

> Sorry, maybe I was unclear, but I'm looking forward to reading
> a *recipe* to reproduce the bug.

Bastien,

I think what Achim is saying is that, for those of us that install org
from git, the system of autoloading is *fragile* because it depends on
non-predictable behaviour of how an older version of org may have been
configured.  A recipe is not necessarily possible but the problem is
there nonetheless.

thanks,
eric

-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.2.50.1 and Org release_7.9.2-406-g2c78ca-git