I have two machines: WinXP and Vista (64 bit) with Emacs 22.3 on both. Both are configured the same in terms of libraries and, specifically, the org-mode configuration is the same. However, the (require 'org-install) on the Vista system doesn't seem to work the same as it does on WinXP. When I type C-c a on the XP system I get the usual menu asking for the additional key for the type of agenda I want. On the Vista system, though, when I type C-c a I don't get this menu and it provides the agenda in the default format (which isn't really as useful to me). I do a C-h f on org-agenda and it tells me (on the Vista system) that it is an interactive Lisp function in 'org.el'. Apparently, even with the (require ...) in my .emacs file I am not loading 'org-install. Any ideas why this would be? Mark
I would check that you are running the same version of org on both -
call the function org-version.
On Tue, 03 Mar 2009 14:39:52 -0800
Mark Elston <m.elston@advantest-ard.com> wrote:
> I have two machines: WinXP and Vista (64 bit) with Emacs 22.3
> on both.
>
> Both are configured the same in terms of libraries and, specifically,
> the org-mode configuration is the same.
>
> However, the (require 'org-install) on the Vista system doesn't
> seem to work the same as it does on WinXP. When I type C-c a
> on the XP system I get the usual menu asking for the additional
> key for the type of agenda I want.
>
> On the Vista system, though, when I type C-c a I don't get this
> menu and it provides the agenda in the default format (which isn't
> really as useful to me).
>
> I do a C-h f on org-agenda and it tells me (on the Vista system)
> that it is an interactive Lisp function in 'org.el'.
>
> Apparently, even with the (require ...) in my .emacs file I am
> not loading 'org-install.
>
> Any ideas why this would be?
>
> Mark
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Also try locate-library. -- Myalgic encephalomyelitis denialism is causing death (decades early; Jason et al. 2006) and severe suffering, pain, and disability (worse than nearly all other serious diseases studied; Schweitzer et al. 1995) and grossly corrupting science. The denialism is worse than it ever was with even AIDS or MS. http://www.meactionuk.org.uk/What_Is_ME_What_Is_CFS.htm
Thanks, Mike. That was it. For some reason I had, on the
Vista machine, an old version (3.15) of org.el earlier in
the load-path than on the XP machine. I really don't know
where it came from... :(
Mark
* Mike Newman wrote (on 3/3/2009 3:26 PM):
> I would check that you are running the same version of org on both -
> call the function org-version.
>
> On Tue, 03 Mar 2009 14:39:52 -0800
> Mark Elston <m.elston@advantest-ard.com> wrote:
>
>> I have two machines: WinXP and Vista (64 bit) with Emacs 22.3
>> on both.
>>
>> Both are configured the same in terms of libraries and, specifically,
>> the org-mode configuration is the same.
>>
>> However, the (require 'org-install) on the Vista system doesn't
>> seem to work the same as it does on WinXP. When I type C-c a
>> on the XP system I get the usual menu asking for the additional
>> key for the type of agenda I want.
>>
>> On the Vista system, though, when I type C-c a I don't get this
>> menu and it provides the agenda in the default format (which isn't
>> really as useful to me).
>>
>> I do a C-h f on org-agenda and it tells me (on the Vista system)
>> that it is an interactive Lisp function in 'org.el'.
>>
>> Apparently, even with the (require ...) in my .emacs file I am
>> not loading 'org-install.
>>
>> Any ideas why this would be?
>>
>> Mark
>>
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Remember: use `Reply All' to send replies to the list.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
>
>
Hi, After I updated yesterday I have been having this problem. This is how I compile: $ make cleanall && make all and I load org from my init file like this: ;; the org repo is at ~/build/org-mode (add-to-list 'load-path (expand-file-name "~/build/org-mode/lisp")) (add-to-list 'load-path (expand-file-name "~/build/org-mode/contrib/lisp")) (require 'org-install) Now every time something needs to be loaded say org-latex during latex export or org-table when turning on orgtbl minor mode, I get errors like these: (file-error "Cannot open load file" "lisp/org") I see lisp/org-install.el has autoloads like these: (autoload 'org-mode "lisp/org" ...) I have faced this once earlier, not sure how I resolved it back then. What am I doing wrong here? -- Suvayu Open source is the future. It sets us free.
[-- Attachment #1: Type: text/plain, Size: 757 bytes --] On 26 Jun 2011, suvayu ali wrote: > $ make cleanall && make all > > and I load org from my init file like this: > > ;; the org repo is at ~/build/org-mode > (add-to-list 'load-path (expand-file-name "~/build/org-mode/lisp")) > (add-to-list 'load-path (expand-file-name "~/build/org-mode/contrib/lisp")) > > (require 'org-install) > > <snip> > > I have faced this once earlier, not sure how I resolved it back > then. What am I doing wrong here? I faced this, too. A fix/workaround is to adjust the loadpath to: (add-to-list 'load-path (expand-file-name "~/build/org-mode")) After quick browsing through the logs I found nothing that could have caused this, but my guess is that someone adjusted the autoloads from "file.el" to "lisp/file.el". Michael [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
Hi Michael,
On Mon, 27 Jun 2011 18:51:01 +0200
Michael Markert <markert.michael@googlemail.com> wrote:
> A fix/workaround is to adjust the loadpath to:
>
> (add-to-list 'load-path (expand-file-name "~/build/org-mode"))
>
> After quick browsing through the logs I found nothing that could have
> caused this, but my guess is that someone adjusted the autoloads from
> "file.el" to "lisp/file.el".
That seems to work for now. But I think this should still be addressed.
At least if this is how org behaves now, the instructions on Worg
should reflect that.
Thanks a lot. :)
--
Suvayu
Open source is the future. It sets us free.
[-- Attachment #1: Type: text/plain, Size: 724 bytes --] On 27 Jun 2011, Michael Markert wrote: > On 26 Jun 2011, suvayu ali wrote: > >> $ make cleanall && make all >> >> and I load org from my init file like this: >> >> ;; the org repo is at ~/build/org-mode (add-to-list 'load-path >> (expand-file-name "~/build/org-mode/lisp")) (add-to-list 'load-path >> (expand-file-name "~/build/org-mode/contrib/lisp")) >> >> (require 'org-install) >> >> <snip> >> >> I have faced this once earlier, not sure how I resolved it back >> then. What am I doing wrong here? > > I faced this, too. > > A fix/workaround is to adjust the loadpath to: > > (add-to-list 'load-path (expand-file-name "~/build/org-mode")) Scratch that. You need that line _additionally_ to the your other two. Michael [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
On Mon, 27 Jun 2011 20:08:26 +0200
Michael Markert <markert.michael@googlemail.com> wrote:
> > A fix/workaround is to adjust the loadpath to:
> >
> > (add-to-list 'load-path (expand-file-name "~/build/org-mode"))
>
> Scratch that. You need that line _additionally_ to the your other two.
I noticed something strange; if you do (load-library "org-capture") for
example (with the load path set to ~/build/orgmode/lisp), the
libraries get loaded without any errors and then on everything works as
usual. This seems like a strange behaviour to me.
--
Suvayu
Open source is the future. It sets us free.
[-- Attachment #1: Type: text/plain, Size: 1258 bytes --] On 27 Jun 2011, Suvayu Ali wrote: > On Mon, 27 Jun 2011 20:08:26 +0200 > Michael Markert <markert.michael@googlemail.com> wrote: > >>> A fix/workaround is to adjust the loadpath to: >>> >>> (add-to-list 'load-path (expand-file-name "~/build/org-mode")) >> >> Scratch that. You need that line _additionally_ to the your other >> two. > > I noticed something strange; if you do (load-library "org-capture") > for example (with the load path set to ~/build/orgmode/lisp), the > libraries get loaded without any errors and then on everything works > as usual. This seems like a strange behaviour to me. No, it's perfectly fine. With the autoloads you search for `lisp/file.el' so the directory that includes the lisp directory has to be in the load-path. If you search only for the `file.el' the `lisp' directory itself has to be in the load-path. This is exactly the problem if you change your load-path according to my first mail: If you (or a file -- in my case it was org-contacts.el) load the file directly, you'll fail. With org-mode this is especially hairy, because the bundled org-mode is by default still in the load-path, so you'll load the old ones -- in the best case this results in cryptic and incomprehensible error messages on load. Michael [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1035 bytes --] On 27 Jun 2011, Suvayu Ali wrote: > Hi Michael, > > On Mon, 27 Jun 2011 18:51:01 +0200 > Michael Markert <markert.michael@googlemail.com> wrote: > >> A fix/workaround is to adjust the loadpath to: >> >> (add-to-list 'load-path (expand-file-name "~/build/org-mode")) >> >> After quick browsing through the logs I found nothing that could have >> caused this, but my guess is that someone adjusted the autoloads from >> "file.el" to "lisp/file.el". > > That seems to work for now. But I think this should still be > addressed. At least if this is how org behaves now, the instructions > on Worg should reflect that. > > Thanks a lot. :) I think I tracked it down: The problem is emacs24, that is the autoload.el that it bundles. With emacs23 it doesn't honor the path of the file it's passed, but with emacs24 it does, resulting in "lisp/file" autoloads. I don't see an easy solution, that's not plain dirty.[1] Michael I consider adding the base directory along with the `lisp' and maybe `contrib/lisp' directories quite dirty ;) [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
Michael Markert <markert.michael@googlemail.com> wrote:
> On 27 Jun 2011, Suvayu Ali wrote:
> > Hi Michael,
> >
> > On Mon, 27 Jun 2011 18:51:01 +0200
> > Michael Markert <markert.michael@googlemail.com> wrote:
> >
> >> A fix/workaround is to adjust the loadpath to:
> >>
> >> (add-to-list 'load-path (expand-file-name "~/build/org-mode"))
> >>
> >> After quick browsing through the logs I found nothing that could have
> >> caused this, but my guess is that someone adjusted the autoloads from
> >> "file.el" to "lisp/file.el".
> >
> > That seems to work for now. But I think this should still be
> > addressed. At least if this is how org behaves now, the instructions
> > on Worg should reflect that.
> >
> > Thanks a lot. :)
>
> I think I tracked it down: The problem is emacs24, that is the
> autoload.el that it bundles.
>
> With emacs23 it doesn't honor the path of the file it's passed, but with
> emacs24 it does, resulting in "lisp/file" autoloads.
>
> I don't see an easy solution, that's not plain dirty.[1]
>
> Michael
>
> I consider adding the base directory along with the `lisp' and maybe
> `contrib/lisp' directories quite dirty ;)
I run emacs24 and I don't have this problem - and I made sure that I was
running emacs24 by modifying the makefile appropriately:
,----
| $ make lisp/org-install.el
| /usr/local/bin/emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))" -eval "(message (emacs-version))" --eval "(require 'autoload)" \
| --eval '(find-file "org-install.el")' \
| --eval '(erase-buffer)' \
| --eval '(mapc (lambda (x) (generate-file-autoloads (symbol-name x))) (quote (lisp/org.el lisp/org-agenda.el lisp/org-ascii.el lisp/org-attach.el lisp/org-archive.el lisp/org-bbdb.el lisp/org-beamer.el lisp/org-bibtex.el lisp/org-capture.el lisp/org-clock.el lisp/org-colview.el lisp/org-colview-xemacs.el lisp/org-compat.el lisp/org-pcomplete.el lisp/org-crypt.el lisp/org-ctags.el lisp/org-datetree.el lisp/org-docview.el lisp/org-entities.el lisp/org-exp.el lisp/org-exp-blocks.el lisp/org-docbook.el lisp/org-faces.el lisp/org-feed.el lisp/org-footnote.el lisp/org-freemind.el lisp/org-gnus.el lisp/org-habit.el lisp/org-html.el lisp/org-icalendar.el lisp/org-id.el lisp/org-indent.el lisp/org-info.el lisp/org-inlinetask.el lisp/org-jsinfo.el lisp/org-irc.el lisp/org-latex.el lisp/org-list.e
l lisp/org-mac-message.el lisp/org-macs.el lisp/org-mew.el lisp/org-mhe.el lisp/org-mks.el lisp/org-mobile.el lisp/org-mouse.el lisp/org-publish.el lisp/org-plot.el lisp/org-protocol.el lisp
/org-remember.el lisp/org-rmail.el lisp/org-special-blocks.el lisp/org-src.el lisp/org-table.el lisp/org-taskjuggler.el lisp/org-timer.el lisp/org-vm.el lisp/org-w3m.el lisp/org-wl.el lisp/org-xoxo.el lisp/ob.el lisp/ob-table.el lisp/ob-lob.el lisp/ob-ref.el lisp/ob-exp.el lisp/ob-tangle.el lisp/ob-comint.el lisp/ob-eval.el lisp/ob-keys.el lisp/ob-awk.el lisp/ob-C.el lisp/ob-calc.el lisp/ob-ditaa.el lisp/ob-haskell.el lisp/ob-perl.el lisp/ob-sh.el lisp/ob-R.el lisp/ob-dot.el lisp/ob-mscgen.el lisp/ob-latex.el lisp/ob-lisp.el lisp/ob-ledger.el lisp/ob-python.el lisp/ob-sql.el lisp/ob-asymptote.el lisp/ob-emacs-lisp.el lisp/ob-matlab.el lisp/ob-ruby.el lisp/ob-sqlite.el lisp/ob-clojure.el lisp/ob-ocaml.el lisp/ob-sass.el lisp/ob-css.el lisp/ob-gnuplot.el lisp/ob-octave.el lisp/ob-screen.el
lisp/ob-plantuml.el lisp/ob-org.el lisp/ob-js.el lisp/ob-scheme.el)))' \
| --eval '(insert "\n(provide (quote org-install))\n")' \
| --eval '(save-buffer)'
| GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0)
| of 2011-04-13 on alphaville.dokosmarshall.org
| Loading vc-git...
| Generating autoloads for lisp/org.el...
| Generating autoloads for lisp/org.el...done
| Generating autoloads for lisp/org-agenda.el...
| ...
`----
The generated org-install.el looks like this:
,----
| \f
| ;;;### (autoloads (org-customize org-reload org-require-autoloaded-modules
| ;;;;;; org-submit-bug-report org-cycle-agenda-files org-switchb
| ;;;;;; org-map-entries org-open-link-from-string org-open-at-point-global
| ;;;;;; org-insert-link-global org-store-link org-run-like-in-org-mode
| ;;;;;; turn-on-orgstruct++ turn-on-orgstruct orgstruct-mode org-global-cycle
| ;;;;;; org-mode org-babel-do-load-languages) "org" "lisp/org.el"
| ;;;;;; (19976 50297))
| ;;; Generated autoloads from lisp/org.el
|
| (autoload 'org-babel-do-load-languages "org" "\
| Load the languages defined in `org-babel-load-languages'.
|
| \(fn SYM VALUE)" nil nil)
|
| (autoload 'org-mode "org" "\
| Outline-based notes management and organizer, alias
| \"Carsten's outline-mode for keeping track of everything.\"
| ...
`----
Nick
Hi Nick, On Mon, 27 Jun 2011 20:13:25 -0400 Nick Dokos <nicholas.dokos@hp.com> wrote: > The generated org-install.el looks like this: > [...] > | > | (autoload 'org-mode "org" "\ > | Outline-based notes management and organizer, alias > | \"Carsten's outline-mode for keeping track of everything.\" > | ... > `---- > I also run emacs24 and my autoloads look like this. Obviously the leading lisp/ is the problem. (autoload 'org-mode "lisp/org" ...) This is my setup: emacs 24 is installed in /opt/emacs-lisp I changed the Makefile to point EMACS to /opt/emacs-lisp/bin/emacs and ran make. It still generates the same autoloads (with the leading lisp/). I setup org by evaluating the following lines in an emacs session started as emacs -Q: (add-to-list 'load-path (expand-file-name "~/build/org-mode/lisp")) (add-to-list 'load-path (expand-file-name "~/build/org-mode/contrib/lisp")) ;; activate org (require 'org-install) I get the same error again, its trying to load lisp/org instead of org. I tried this with a fresh clone of the org-mode repository. I can't see where I could have gone wrong here. > Nick -- Suvayu Open source is the future. It sets us free.
Suvayu Ali <fatkasuvayu+linux@gmail.com> wrote: > Hi Nick, > > On Mon, 27 Jun 2011 20:13:25 -0400 > Nick Dokos <nicholas.dokos@hp.com> wrote: > > > The generated org-install.el looks like this: > > > > [...] > > > | > > | (autoload 'org-mode "org" "\ > > | Outline-based notes management and organizer, alias > > | \"Carsten's outline-mode for keeping track of everything.\" > > | ... > > `---- > > > > I also run emacs24 and my autoloads look like this. Obviously the > leading lisp/ is the problem. > > (autoload 'org-mode "lisp/org" ...) > > This is my setup: > > emacs 24 is installed in /opt/emacs-lisp I changed the Makefile to point > EMACS to /opt/emacs-lisp/bin/emacs and ran make. It still generates the > same autoloads (with the leading lisp/). > > I setup org by evaluating the following lines in an emacs session > started as emacs -Q: > > (add-to-list 'load-path (expand-file-name "~/build/org-mode/lisp")) > (add-to-list 'load-path (expand-file-name "~/build/org-mode/contrib/lisp")) > > ;; activate org > (require 'org-install) > > I get the same error again, its trying to load lisp/org instead of org. > I tried this with a fresh clone of the org-mode repository. I can't see > where I could have gone wrong here. > Suvayu and I worked on this in an email exchange: it turns out that Michael was right in that (recent) emacs 24 is indeed the culprit. In particular, the variable generated-autoload-file is now initialized to nil: ,---- | (defvar generated-autoload-file nil | "File into which to write autoload definitions. | A Lisp file can set this in its local variables section to make | its autoloads go somewhere else. | | If this is a relative file name, the directory is determined as | follows: | - If a Lisp file defined `generated-autoload-file' as a | file-local variable, use its containing directory. | - Otherwise use the \"lisp\" subdirectory of `source-directory'. | | The autoload file is assumed to contain a trailer starting with a | FormFeed character.") `---- whereas before (e.g. in the version of emacs 24 that I'm running: GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of 2011-04-13) it was initialized to "loaddefs.el": ,---- | (defvar generated-autoload-file "loaddefs.el" | "*File \\[update-file-autoloads] puts autoloads into. | A `.el' file can set this in its local variables section to make its | autoloads go somewhere else. The autoload file is assumed to contain a | trailer starting with a FormFeed character.") `---- The particular value is not that important: the fact that it was a relative file name is, as indicated by the comment above. I think the following patch fixes it and does not break any earlier versions of org. Suvayu, Michael (and anybody else who cares to try it): would you mind checking and reporting back? Thanks, Nick diff --git a/Makefile b/Makefile index 239ab2e..08e3a08 100644 --- a/Makefile +++ b/Makefile @@ -230,6 +230,7 @@ autoloads: lisp/org-install.el lisp/org-install.el: $(LISPFILES0) Makefile $(BATCH) --eval "(require 'autoload)" \ + --eval '(setq generated-autoload-file "org-install.el")' \ --eval '(find-file "org-install.el")' \ --eval '(erase-buffer)' \ --eval '(mapc (lambda (x) (generate-file-autoloads (symbol-name x))) (quote ($(LISPFILES0))))' \
[-- Attachment #1: Type: text/plain, Size: 2506 bytes --] On 28 Jun 2011, Nick Dokos wrote: > <snip> > > Suvayu and I worked on this in an email exchange: it turns out that > Michael was right in that (recent) emacs 24 is indeed the culprit. In > particular, the variable generated-autoload-file is now initialized to > nil: > > ,---- > | (defvar generated-autoload-file nil > | "File into which to write autoload definitions. > | A Lisp file can set this in its local variables section to make > | its autoloads go somewhere else. > | > | If this is a relative file name, the directory is determined as > | follows: > | - If a Lisp file defined `generated-autoload-file' as a > | file-local variable, use its containing directory. > | - Otherwise use the \"lisp\" subdirectory of `source-directory'. > | > | The autoload file is assumed to contain a trailer starting with a > | FormFeed character.") > `---- > > whereas before (e.g. in the version of emacs 24 that I'm running: GNU > Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of > 2011-04-13) it was initialized to "loaddefs.el": > > > ,---- | (defvar generated-autoload-file "loaddefs.el" | "*File > \\[update-file-autoloads] puts autoloads into. | A `.el' file can set > this in its local variables section to make its | autoloads go > somewhere else. The autoload file is assumed to contain a | trailer > starting with a FormFeed character.") `---- > > The particular value is not that important: the fact that it was > a relative file name is, as indicated by the comment above. > > I think the following patch fixes it and does not break any earlier > versions of org. Suvayu, Michael (and anybody else who cares to try > it): would you mind checking and reporting back? Hi Nick, thanks for looking into it. But the patch doesn't work. I think that stems from the fact, that the first thing `generate-file-autoloads' does is to bind it new: ,---- | (defun generate-file-autoloads (file) | "Insert at point a loaddefs autoload section for FILE. | Autoloads are generated for defuns and defmacros in FILE | marked by `generate-autoload-cookie' (which see). | If FILE is being visited in a buffer, the contents of the buffer | are used. | Return non-nil in the case where no autoloads were added at point." | (interactive "fGenerate autoloads for file: ") | (let ((generated-autoload-file buffer-file-name)) | (autoload-generate-file-autoloads file (current-buffer)))) `---- And because we feed it a relative file name it's bound to a relative file name. Michael [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
Hi Nick,
On Tue, 28 Jun 2011 08:56:59 +0200
Michael Markert <markert.michael@googlemail.com> wrote:
> Hi Nick,
>
> thanks for looking into it.
>
> But the patch doesn't work. I think that stems from the fact, that the
> first thing `generate-file-autoloads' does is to bind it new:
I can confirm, I still get the error:
Cannot open load file: lisp/org
--
Suvayu
Open source is the future. It sets us free.
[-- Attachment #1: Type: text/plain, Size: 3182 bytes --] On 28 Jun 2011, Michael Markert wrote: > [1 <text/plain; US-ASCII (7bit)>] > On 28 Jun 2011, Nick Dokos wrote: >> <snip> >> >> Suvayu and I worked on this in an email exchange: it turns out that >> Michael was right in that (recent) emacs 24 is indeed the culprit. In >> particular, the variable generated-autoload-file is now initialized >> to nil: >> >> ,---- >> | (defvar generated-autoload-file nil >> | "File into which to write autoload definitions. >> | A Lisp file can set this in its local variables section to make >> | its autoloads go somewhere else. >> | >> | If this is a relative file name, the directory is determined as >> | follows: >> | - If a Lisp file defined `generated-autoload-file' as a >> | file-local variable, use its containing directory. >> | - Otherwise use the \"lisp\" subdirectory of `source-directory'. >> | >> | The autoload file is assumed to contain a trailer starting with a >> | FormFeed character.") >> `---- >> >> whereas before (e.g. in the version of emacs 24 that I'm running: GNU >> Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of >> 2011-04-13) it was initialized to "loaddefs.el": >> >> >> ,---- | (defvar generated-autoload-file "loaddefs.el" | "*File >> \\[update-file-autoloads] puts autoloads into. | A `.el' file can >> set this in its local variables section to make its | autoloads go >> somewhere else. The autoload file is assumed to contain a | trailer >> starting with a FormFeed character.") `---- >> >> The particular value is not that important: the fact that it was >> a relative file name is, as indicated by the comment above. >> >> I think the following patch fixes it and does not break any earlier >> versions of org. Suvayu, Michael (and anybody else who cares to try >> it): would you mind checking and reporting back? With this patch for the makefile I can get it running: -- <snap> --- diff --git a/Makefile b/Makefile index 239ab2e..2d1d324 100644 --- a/Makefile +++ b/Makefile @@ -230,12 +230,11 @@ autoloads: lisp/org-install.el lisp/org-install.el: $(LISPFILES0) Makefile $(BATCH) --eval "(require 'autoload)" \ - --eval '(find-file "org-install.el")' \ + --eval '(find-file "lisp/org-install.el")' \ --eval '(erase-buffer)' \ - --eval '(mapc (lambda (x) (generate-file-autoloads (symbol-name x))) (quote ($(LISPFILES0))))' \ + --eval '(mapc (lambda (x) (generate-file-autoloads (symbol-name x))) (quote ($(LISPF))))' \ --eval '(insert "\n(provide (quote org-install))\n")' \ --eval '(save-buffer)' - mv org-install.el lisp doc/org: doc/org.texi (cd doc && $(MAKEINFO) --no-split org.texi -o org) -- <snap> --- I have some problems with writing org-install directly but otherwise autoload.el generates lisp/ autoloads (with LISPFILES0) or fails to find (with LISPF). But because org-install is automatically generated I don't consider them as such grave in the case it kills the old file and leaves garbage (maybe use a backup file?). I tried several things that all failed: 1. Let-bind `generated-autoload-load-name' per run 2. add `generated-autoload-file' to the elisp files 3. 1. with LISPFILES0 4. ... I'll spare you the rest. :( Michael [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
Suvayu Ali <fatkasuvayu+linux@gmail.com> wrote:
> Hi Nick,
>
> On Tue, 28 Jun 2011 08:56:59 +0200
> Michael Markert <markert.michael@googlemail.com> wrote:
>
> > Hi Nick,
> >
> > thanks for looking into it.
> >
> > But the patch doesn't work. I think that stems from the fact, that the
> > first thing `generate-file-autoloads' does is to bind it new:
>
> I can confirm, I still get the error:
>
> Cannot open load file: lisp/org
>
OK, thanks to both you and Michael for checking: back to the drawing
board. Things would be easier if I could reproduce it: I'll install
emacs latest and try again.
Nick
Nick Dokos <nicholas.dokos@hp.com> wrote:
> Suvayu Ali <fatkasuvayu+linux@gmail.com> wrote:
>
> > Hi Nick,
> >
> > On Tue, 28 Jun 2011 08:56:59 +0200
> > Michael Markert <markert.michael@googlemail.com> wrote:
> >
> > > Hi Nick,
> > >
> > > thanks for looking into it.
> > >
> > > But the patch doesn't work. I think that stems from the fact, that the
> > > first thing `generate-file-autoloads' does is to bind it new:
> >
> > I can confirm, I still get the error:
> >
> > Cannot open load file: lisp/org
> >
>
> OK, thanks to both you and Michael for checking: back to the drawing
> board. Things would be easier if I could reproduce it: I'll install
> emacs latest and try again.
>
I cannot reproduce it even with latest org, latest emacs: org-install.el
makes properly with autoloads that look like this:
,----
| (autoload 'org-mode "org" "\
| Outline-based notes management and organizer, alias
| \"Carsten's outline-mode for keeping track of everything.\"
`----
No lisp/org anywhere in sight (except in comments).
I also tried with Michael's patch and it still works for me, so if
it fixes things for him and Suvayu, it should probably be applied
(but I wish I understood what goes wrong and how the patch fixes it).
Nick
[-- Attachment #1: Type: text/plain, Size: 1094 bytes --] On 28 Jun 2011, Nick Dokos wrote: > <snip> > > I cannot reproduce it even with latest org, latest emacs: > org-install.el makes properly with autoloads that look like this: > > ,---- > | (autoload 'org-mode "org" "\ > | Outline-based notes management and organizer, alias > | \"Carsten's outline-mode for keeping track of everything.\" > `---- > > No lisp/org anywhere in sight (except in comments). That sounds great. I'm running on Julien's emacs-snapshot so I'm not using an latest version. > I also tried with Michael's patch and it still works for me, so if > it fixes things for him and Suvayu, it should probably be applied I didn't test for compability and if the problem is only temporarily it should not be applied. > (but I wish I understood what goes wrong and how the patch fixes it). I try to summarize (sorry for being incomprehensible in the other mail -- it's to hot here): Problem: autoload.el generates file names with lisp/ prefix. Solution: - We generate the autoloads file in the org directory. - To get valid file names we use the non-prefixed file names. Michael [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
Michael Markert <markert.michael@googlemail.com> wrote: > On 28 Jun 2011, Nick Dokos wrote: > > <snip> > > > > I cannot reproduce it even with latest org, latest emacs: > > org-install.el makes properly with autoloads that look like this: > > > > ,---- > > | (autoload 'org-mode "org" "\ > > | Outline-based notes management and organizer, alias > > | \"Carsten's outline-mode for keeping track of everything.\" > > `---- > > > > No lisp/org anywhere in sight (except in comments). > > That sounds great. I'm running on Julien's emacs-snapshot so I'm not > using an latest version. > > > I also tried with Michael's patch and it still works for me, so if > > it fixes things for him and Suvayu, it should probably be applied > > I didn't test for compability and if the problem is only temporarily it > should not be applied. > > > (but I wish I understood what goes wrong and how the patch fixes it). > > I try to summarize (sorry for being incomprehensible in the other mail > -- it's to hot here): > > Problem: autoload.el generates file names with lisp/ prefix. For you and Suvayu, but not for me. It's the discrepancy that bothers me. > Solution: > - We generate the autoloads file in the org directory. > - To get valid file names we use the non-prefixed file names. I would like to understand the root cause. Nick
[-- Attachment #1: Type: text/plain, Size: 2158 bytes --] On 28 Jun 2011, Nick Dokos wrote: > Michael Markert <markert.michael@googlemail.com> wrote: >> <snip> >> Problem: autoload.el generates file names with lisp/ prefix. > > For you and Suvayu, but not for me. It's the discrepancy > that bothers me. I dug into emacs because I thought "Sure, there must be some change in the meantime", well now I'm bothered, too. The bzr autoloads.el is identical to mine. But this code makes me curious: #+begin_src emacs-lisp (defun autoload-file-load-name (file) "Compute the name that will be used to load FILE." ;; OUTFILE should be the name of the global loaddefs.el file, which ;; is expected to be at the root directory of the files we're ;; scanning for autoloads and will be in the `load-path'. (let* ((outfile (default-value 'generated-autoload-file)) (name (file-relative-name file (file-name-directory outfile))) (names '()) (dir (file-name-directory outfile))) ;; If `name' has directory components, only keep the ;; last few that are really needed. (while name (setq name (directory-file-name name)) (push (file-name-nondirectory name) names) (setq name (file-name-directory name))) (while (not name) (cond ((null (cdr names)) (setq name (car names))) ((file-exists-p (expand-file-name "subdirs.el" dir)) ;; FIXME: here we only check the existence of subdirs.el, ;; without checking its content. This makes it generate wrong load ;; names for cases like lisp/term which is not added to load-path. (setq dir (expand-file-name (pop names) dir))) (t (setq name (mapconcat 'identity names "/"))))) (if (string-match "\\.elc?\\(\\.\\|\\'\\)" name) (substring name 0 (match-beginning 0)) name))) #+end_src emacs-lisp if I read it correctly we decompose our path-name (say lisp/org.el), by rebasing it on outfile (org-install.el, which gives lisp/org.el) and split in dirs, which gives '("lisp" "org.el"), then we are in the else branch, build "lisp/org.el" and then in the last if we chop of the ".el". I can't see how you get there correct path names :( Michael [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
Hello Nick and Michael, Sorry for the delayed response. I had an important appointment. On Tue, 28 Jun 2011 14:39:13 +0200 Michael Markert <markert.michael@googlemail.com> wrote: > > With this patch for the makefile I can get it running: > > -- <snap> --- > > diff --git a/Makefile b/Makefile > index 239ab2e..2d1d324 100644 > --- a/Makefile > +++ b/Makefile > @@ -230,12 +230,11 @@ autoloads: lisp/org-install.el > > lisp/org-install.el: $(LISPFILES0) Makefile > $(BATCH) --eval "(require 'autoload)" \ > - --eval '(find-file "org-install.el")' \ > + --eval '(find-file "lisp/org-install.el")' \ > --eval '(erase-buffer)' \ > - --eval '(mapc (lambda (x) (generate-file-autoloads > (symbol-name x))) (quote ($(LISPFILES0))))' \ > + --eval '(mapc (lambda (x) (generate-file-autoloads > (symbol-name x))) (quote ($(LISPF))))' \ --eval '(insert "\n(provide > (quote org-install))\n")' \ --eval '(save-buffer)' > - mv org-install.el lisp > > doc/org: doc/org.texi > (cd doc && $(MAKEINFO) --no-split org.texi -o org) > > -- <snap> --- This patch to the Makefile generates the autoloads without the lisp/ prefix for me and works without errors. However as Nick says, maybe its worthwhile to understand why this was happening in the first place. My lisp knowledge is very little, but please let me know if I can help track this down. > > Michael Thanks a lot. :) -- Suvayu Open source is the future. It sets us free.
Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:
[...]
> prefix for me and works without errors. However as Nick says, maybe its
> worthwhile to understand why this was happening in the first place. My
> lisp knowledge is very little, but please let me know if I can help
> track this down.
I'm jumping late into this thread so apologies first but I just wanted
to add one data point: I had this problem as well (and did mention it in
passing in some message a few weeks ago) but it disappeared. I track
Julien's Emacs 24 builds and it would *appear* that the change in
behaviour appeared and then disappeared. At least, my org-install.el
file suddenly had "lisp/org" and then just as suddenly did not!
--
Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D)
Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
> Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:
>
> [...]
>
> > prefix for me and works without errors. However as Nick says, maybe its
> > worthwhile to understand why this was happening in the first place. My
> > lisp knowledge is very little, but please let me know if I can help
> > track this down.
>
> I'm jumping late into this thread so apologies first but I just wanted
> to add one data point: I had this problem as well (and did mention it in
> passing in some message a few weeks ago) but it disappeared. I track
> Julien's Emacs 24 builds and it would *appear* that the change in
> behaviour appeared and then disappeared. At least, my org-install.el
> file suddenly had "lisp/org" and then just as suddenly did not!
>
Good info - thanks!
BTW, where can one get at Julien's emacs 24 builds?
Nick
[-- Attachment #1: Type: text/plain, Size: 1185 bytes --] On 29 Jun 2011, Eric S. Fraga wrote: > Suvayu Ali <fatkasuvayu+linux@gmail.com> writes: > > [...] > >> prefix for me and works without errors. However as Nick says, maybe >> its worthwhile to understand why this was happening in the first >> place. My lisp knowledge is very little, but please let me know if I >> can help track this down. > > I'm jumping late into this thread so apologies first but I just wanted > to add one data point: I had this problem as well (and did mention it > in passing in some message a few weeks ago) but it disappeared. I > track Julien's Emacs 24 builds and it would *appear* that the change > in behaviour appeared and then disappeared. At least, my > org-install.el file suddenly had "lisp/org" and then just as suddenly > did not! Uhh this is getting more weird with every new message. From when is your package? And what is the current state of this problem? With the package from yesterday I still see the problem. Like I said in another message in this thread: From looking at the source I see no way, that autoloads could generate the path we need. @Suvayu Do you use Julien's emacs-snapshot, too? Michael [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 948 bytes --] On 29 Jun 2011, Nick Dokos wrote: > Eric S Fraga <e.fraga@ucl.ac.uk> wrote: > >> Suvayu Ali <fatkasuvayu+linux@gmail.com> writes: >> >> [...] >> >>> prefix for me and works without errors. However as Nick says, maybe >>> its worthwhile to understand why this was happening in the first >>> place. My lisp knowledge is very little, but please let me know if I >>> can help track this down. >> >> I'm jumping late into this thread so apologies first but I just >> wanted to add one data point: I had this problem as well (and did >> mention it in passing in some message a few weeks ago) but it >> disappeared. I track Julien's Emacs 24 builds and it would *appear* >> that the change in behaviour appeared and then disappeared. At >> least, my org-install.el file suddenly had "lisp/org" and then just >> as suddenly did not! >> > > Good info - thanks! > > BTW, where can one get at Julien's emacs 24 builds? http://emacs.naquadah.org/ Michael [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
Hi, On Wed, Jun 29, 2011 at 11:24 AM, Michael Markert <markert.michael@googlemail.com> wrote: > @Suvayu Do you use Julien's emacs-snapshot, too? > No I usually follow the git mirror on repo.or.cz[1] unless there is some bugfix that I want, in that case I use the bzr repo here[2]. > Michael Footnotes: [1] http://repo.or.cz/w/emacs.git [2] http://bzr.savannah.gnu.org/lh/emacs/trunk/changes -- Suvayu Open source is the future. It sets us free.
Michael Markert <markert.michael@googlemail.com> writes:
> On 29 Jun 2011, Eric S. Fraga wrote:
>
>> Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:
>>
>> [...]
>>
>>> prefix for me and works without errors. However as Nick says, maybe
>>> its worthwhile to understand why this was happening in the first
>>> place. My lisp knowledge is very little, but please let me know if I
>>> can help track this down.
>>
>> I'm jumping late into this thread so apologies first but I just wanted
>> to add one data point: I had this problem as well (and did mention it
>> in passing in some message a few weeks ago) but it disappeared. I
>> track Julien's Emacs 24 builds and it would *appear* that the change
>> in behaviour appeared and then disappeared. At least, my
>> org-install.el file suddenly had "lisp/org" and then just as suddenly
>> did not!
>
> Uhh this is getting more weird with every new message.
>
> From when is your package? And what is the current state of this
> problem? With the package from yesterday I still see the problem.
>
> Like I said in another message in this thread: From looking at the
> source I see no way, that autoloads could generate the path we need.
>
> @Suvayu Do you use Julien's emacs-snapshot, too?
>
> Michael
Actually, it's getting even more confusing. My summary above is wrong.
Sorry! However, I have three systems:
|--------+------------------------+--------------------+-------------|
| system | emacs-snapshot version | org-install format | org version |
|--------+------------------------+--------------------+-------------|
| 1. | 20110620-1 | "org" | 2b7dbee |
| 2. | 20110620-1 | "lisp/org" | 2b7dbee |
| 3. | 20110628-1 | "lisp/org" | 560804b |
|--------+------------------------+--------------------+-------------|
These are all Debian testing/unstable systems with slightly different
mixes of packages and two (1,2) with one commit newer than the other
(3).
Two different versions of Emacs but the different method of specifying
the autoload not matching the version of Emacs. There's something else
going on! I'm happy to give versions of other packages if required, of
course!
Very very strange!
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.5 (release_7.5.511.g2b7d)
Nick Dokos <nicholas.dokos@hp.com> writes: [...] > BTW, where can one get at Julien's emacs 24 builds? I get them with the following line in my /etc/apt/sources.list: deb http://emacs.naquadah.org/ unstable/ deb-src http://emacs.naquadah.org/ unstable/ Latest version is from yesterday. Julien tends to do a weekly snapshot. There are some strange window/frame problems with the latest versions, especially to do with popups, but not deal breaking (IMO). -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.511.g2b7d)
Eric S Fraga <e.fraga@ucl.ac.uk> wrote: > Nick Dokos <nicholas.dokos@hp.com> writes: > > [...] > > > BTW, where can one get at Julien's emacs 24 builds? > > I get them with the following line in my /etc/apt/sources.list: > > deb http://emacs.naquadah.org/ unstable/ > deb-src http://emacs.naquadah.org/ unstable/ > Thanks! (and to Michael as well for the reference). Like Suvauy, I use the git mirror on repo.or.cz. I'm allergic to bzr so I try not to go too close to savanah. > Latest version is from yesterday. Julien tends to do a weekly > snapshot. There are some strange window/frame problems with the latest > versions, especially to do with popups, but not deal breaking (IMO). > Yes, I slammed into those head-first yesterday: I got a frame for each message viewed (I use mh-e) and for each debug trace. I ran away as fast as possible. Nick
On Wed, Jun 29, 2011 at 1:02 PM, Nick Dokos <nicholas.dokos@hp.com> wrote:
>> Latest version is from yesterday. Julien tends to do a weekly
>> snapshot. There are some strange window/frame problems with the latest
>> versions, especially to do with popups, but not deal breaking (IMO).
>>
>
> Yes, I slammed into those head-first yesterday: I got a frame for each
> message viewed (I use mh-e) and for each debug trace. I ran away as fast
> as possible.
>
Those were annoying me a lot[1]! However it has been fixed in the latest
Emacs 24. I had to use bzr for the bugfix since the git mirror is behind
by several days (not sure why that is though, until March it used to be
only a few days behind).
Footnotes:
[1] The pop-ups became intolerable when exporting files with lots of
babel blocks. The problem was switch-buffer-to-other-window was behaving
as switch-buffer-to-other-frame.
--
Suvayu
Open source is the future. It sets us free.
On Tue, Jun 28, 2011 at 3:09 PM, Suvayu Ali <fatkasuvayu+linux@gmail.com> wrote:
>> diff --git a/Makefile b/Makefile
>> index 239ab2e..2d1d324 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -230,12 +230,11 @@ autoloads: lisp/org-install.el
>>
>> lisp/org-install.el: $(LISPFILES0) Makefile
>> $(BATCH) --eval "(require 'autoload)" \
>> - --eval '(find-file "org-install.el")' \
>> + --eval '(find-file "lisp/org-install.el")' \
>> --eval '(erase-buffer)' \
>> - --eval '(mapc (lambda (x) (generate-file-autoloads
>> (symbol-name x))) (quote ($(LISPFILES0))))' \
>> + --eval '(mapc (lambda (x) (generate-file-autoloads
>> (symbol-name x))) (quote ($(LISPF))))' \ --eval '(insert "\n(provide
>> (quote org-install))\n")' \ --eval '(save-buffer)'
>> - mv org-install.el lisp
>>
>> doc/org: doc/org.texi
>> (cd doc && $(MAKEINFO) --no-split org.texi -o org)
>
> This patch to the Makefile generates the autoloads without the lisp/
> prefix for me and works without errors. However as Nick says, maybe its
> worthwhile to understand why this was happening in the first place. My
> lisp knowledge is very little, but please let me know if I can help
> track this down.
Is there any more progress on finding and fixing this problem with org
and emacs24? I just built the development version of Aquamacs (GNU
Emacs 24.0.50.3). The problem with the way org autoloads lisp files is
present. Should this patch be applied to org sources?
On Thu, Jul 14, 2011 at 7:33 PM, Skip Collins <skip.collins@gmail.com> wrote:
>> This patch to the Makefile generates the autoloads without the lisp/
>> prefix for me and works without errors. However as Nick says, maybe its
>> worthwhile to understand why this was happening in the first place. My
>> lisp knowledge is very little, but please let me know if I can help
>> track this down.
>
> Is there any more progress on finding and fixing this problem with org
> and emacs24? I just built the development version of Aquamacs (GNU
> Emacs 24.0.50.3). The problem with the way org autoloads lisp files is
> present. Should this patch be applied to org sources?
I have been using this patch since my last post, I haven't had this
problem again. But of course that doesn't say whether that means the
problem isn't present without the patch. :)
--
Suvayu
Open source is the future. It sets us free.
Skip Collins <skip.collins@gmail.com> writes: > Is there any more progress on finding and fixing this problem with org > and emacs24? I just built the development version of Aquamacs (GNU > Emacs 24.0.50.3). The problem with the way org autoloads lisp files is > present. Should this patch be applied to org sources? I've cloned emacs.git and compiled Emacs24 yesterday just to find out. I've not drilled down to the bottom of this yet, but it is a deliberate change in autoload.el and I'm not sure if the change in behaviour that org-mode affects was intended or not. If anybody frequents the Emacs developer list, you might ask Chong Yidong (I've already sent him an email with that question, but the devlist might be quicker). Anyway, I intend to fix this during the restructuring of the Makefile by building those targets in a sub-make that runs in ./lisp (unless I run into a problem with that). Meanwhile the patch that has been posted fixes the issue and does not break on older Emacsen, so this should probably be applied by Bastien. 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
Achim Gratz <Stromeko@nexgo.de> writes: > Skip Collins <skip.collins@gmail.com> writes: >> Is there any more progress on finding and fixing this problem with org >> and emacs24? I just built the development version of Aquamacs (GNU >> Emacs 24.0.50.3). The problem with the way org autoloads lisp files is >> present. Should this patch be applied to org sources? > > I've cloned emacs.git and compiled Emacs24 yesterday just to find out. > I've not drilled down to the bottom of this yet, but it is a deliberate > change in autoload.el and I'm not sure if the change in behaviour that > org-mode affects was intended or not. If anybody frequents the Emacs > developer list, you might ask Chong Yidong (I've already sent him an > email with that question, but the devlist might be quicker). May be these changes deserve a NEWS entry - C-h n The change has caused lots of confusion at least in this list. > Anyway, I intend to fix this during the restructuring of the Makefile by > building those targets in a sub-make that runs in ./lisp (unless I run > into a problem with that). Meanwhile the patch that has been posted > fixes the issue and does not break on older Emacsen, so this should > probably be applied by Bastien. > > > Regards, > Achim. --
Achim Gratz <Stromeko@nexgo.de> writes:
> Meanwhile the patch that has been posted fixes the issue and does not
> break on older Emacsen, so this should probably be applied by Bastien.
I somehow lost track of this patch (my .overview in Gnus got corrupted)
and I cannot access Gmane as the search.gmane.org seems to be down.
Can someone send me this patch again so that I apply it?
Thanks in advance,
--
Bastien
Bastien <bzg@altern.org> writes:
> Can someone send me this patch again so that I apply it?
Forget it -- I just found and applied the patch.
Thanks,
--
Bastien