Hello, I would like to try using Eric Schulte's starter kit, mainly to have my configuration file in org-mode, using an org-mode installation from source. An issue on github (https://github.com/eschulte/emacs24-starter-kit/pull/29) suggests using a command line argument to do so, but this is not convenient (especially since I'm using emacs on OS X). Is there a way to pick up a source install directly from the configuration files (for instance from init.el)? Thanks, Alan
Alan Schmitt <alan.schmitt@polytechnique.org> writes: > Hello, > > I would like to try using Eric Schulte's starter kit, mainly to have my > configuration file in org-mode, using an org-mode installation from > source. An issue on github > (https://github.com/eschulte/emacs24-starter-kit/pull/29) suggests using > a command line argument to do so, but this is not convenient (especially > since I'm using emacs on OS X). Is there a way to pick up a source > install directly from the configuration files (for instance from > init.el)? > > Thanks, > > Alan > Adding a line to init.el will allow you to specify the Org-mode instill to use. Something like the following should work. (add-hook 'after-init-hook `(lambda () ;; remember this directory (setq starter-kit-dir ,(file-name-directory (or load-file-name (buffer-file-name)))) ;; load up the starter kit (add-to-list 'load-path "~/path/to/org-mode/lisp/") (require 'org) (org-babel-load-file (expand-file-name "starter-kit.org" starter-kit-dir)))) -- Eric Schulte http://cs.unm.edu/~eschulte
Eric Schulte writes:
> Adding a line to init.el will allow you to specify the Org-mode instill
> to use. Something like the following should work.
>
> (add-hook 'after-init-hook
> `(lambda ()
> ;; remember this directory
> (setq starter-kit-dir
> ,(file-name-directory (or load-file-name (buffer-file-name))))
> ;; load up the starter kit
> (add-to-list 'load-path "~/path/to/org-mode/lisp/")
> (require 'org)
> (org-babel-load-file (expand-file-name "starter-kit.org" starter-kit-dir))))
Thanks a lot, it works great!
Alan
Hi Eric,
I have a follow-up question about this setup. It seems that I no longer
can use asynchronous export with it, I get this in the *Org Export Process*
buffer:
,----
| Cannot open load file: ox
`----
Can it be related to switching to the starter kit?
Thanks a lot,
Alan
Alan Schmitt writes:
> Eric Schulte writes:
>
>> Adding a line to init.el will allow you to specify the Org-mode instill
>> to use. Something like the following should work.
>>
>> (add-hook 'after-init-hook
>> `(lambda ()
>> ;; remember this directory
>> (setq starter-kit-dir
>> ,(file-name-directory (or load-file-name (buffer-file-name))))
>> ;; load up the starter kit
>> (add-to-list 'load-path "~/path/to/org-mode/lisp/")
>> (require 'org)
>> (org-babel-load-file (expand-file-name "starter-kit.org" starter-kit-dir))))
>
> Thanks a lot, it works great!
>
> Alan
Alan Schmitt <alan.schmitt@polytechnique.org> writes: > Hi Eric, > > I have a follow-up question about this setup. It seems that I no longer > can use asynchronous export with it, I get this in the *Org Export Process* > buffer: > > ,---- > | Cannot open load file: ox > `---- > > Can it be related to switching to the starter kit? > I can think of some possibilities, 1. Your load-path either isn't pointing to the newest Org-mode, or you are somehow also loading an older version of Org-mode. Although I believe I just helped you setup your load path, so lets assume this isn't the case. 2. Do you explicitly require whichever ox-* new exporter you want to use? 3. Maybe you should run make in the Org-mode directory, to ensure all autoload files etc... are in place. I'm sure there is a way around having to do this every time, but it may help in this instance. Sorry I can't be of more help. If the solution you find appears to be a general one, please let me know if it should be folded into the starter kit. Thanks, > > Thanks a lot, > > Alan > > Alan Schmitt writes: > >> Eric Schulte writes: >> >>> Adding a line to init.el will allow you to specify the Org-mode instill >>> to use. Something like the following should work. >>> >>> (add-hook 'after-init-hook >>> `(lambda () >>> ;; remember this directory >>> (setq starter-kit-dir >>> ,(file-name-directory (or load-file-name (buffer-file-name)))) >>> ;; load up the starter kit >>> (add-to-list 'load-path "~/path/to/org-mode/lisp/") >>> (require 'org) >>> (org-babel-load-file (expand-file-name "starter-kit.org" starter-kit-dir)))) >> >> Thanks a lot, it works great! >> >> Alan > -- Eric Schulte http://cs.unm.edu/~eschulte
Hi Eric,
Eric Schulte writes:
> I can think of some possibilities,
>
> 1. Your load-path either isn't pointing to the newest Org-mode, or you
> are somehow also loading an older version of Org-mode. Although I
> believe I just helped you setup your load path, so lets assume this
> isn't the case.
>
> 2. Do you explicitly require whichever ox-* new exporter you want to
> use?
>
> 3. Maybe you should run make in the Org-mode directory, to ensure all
> autoload files etc... are in place. I'm sure there is a way around
> having to do this every time, but it may help in this instance.
>
> Sorry I can't be of more help. If the solution you find appears to be a
> general one, please let me know if it should be folded into the starter
> kit.
I haven't been able to find why this happens, but I have an idea for a
workaround: I'll put my export settings in another file (for instance
"export.org"). Then I'll have a special init file ("export-init.el")
that sets up the org path and loads that file.
I have two questions about how to make it work nice in the starter kit
context.
In export-init.el, should I do a (load-file "export.el") or is it better
to do a (org-babel-load-file "export.org")?
In my main configuration file, should I do a #+include "export.org", or
is it better to do a "org-babel-load-file"?
Thanks,
Alan
Alan Schmitt <alan.schmitt@polytechnique.org> writes: > Hi Eric, > > Eric Schulte writes: > >> I can think of some possibilities, >> >> 1. Your load-path either isn't pointing to the newest Org-mode, or you >> are somehow also loading an older version of Org-mode. Although I >> believe I just helped you setup your load path, so lets assume this >> isn't the case. >> >> 2. Do you explicitly require whichever ox-* new exporter you want to >> use? >> >> 3. Maybe you should run make in the Org-mode directory, to ensure all >> autoload files etc... are in place. I'm sure there is a way around >> having to do this every time, but it may help in this instance. >> >> Sorry I can't be of more help. If the solution you find appears to be a >> general one, please let me know if it should be folded into the starter >> kit. > > I haven't been able to find why this happens, but I have an idea for a > workaround: I'll put my export settings in another file (for instance > "export.org"). Then I'll have a special init file ("export-init.el") > that sets up the org path and loads that file. > > I have two questions about how to make it work nice in the starter kit > context. > > In export-init.el, should I do a (load-file "export.el") or is it better > to do a (org-babel-load-file "export.org")? > > In my main configuration file, should I do a #+include "export.org", or > is it better to do a "org-babel-load-file"? > > Thanks, > > Alan I don't understand why you can't put this code into your normal configuration file? If the error is thrown *before* your main configuration file is loaded, then my guess is that something is wrong with your Org-mode install. I'd read the worg pages on setting up a local Org-mode install to make sure everything there checks out. Hope this helps, -- Eric Schulte http://cs.unm.edu/~eschulte
Eric Schulte writes: > I don't understand why you can't put this code into your normal > configuration file? Because it may load too many things. I thought I could killed two birds with one stone: get a faster async export, and git it working. > If the error is thrown *before* your main configuration file is > loaded, then my guess is that something is wrong with your Org-mode > install. I'd read the worg pages on setting up a local Org-mode > install to make sure everything there checks out. Well, my startup file is fairly simple: #+BEGIN_SRC emacs-lisp ;;; init.el --- Where all the magic begins ;; ;; Part of the Emacs Starter Kit ;; ;; This is the first thing to get loaded. ;; ;; load the starter kit from the `after-init-hook' so all packages are loaded (add-hook 'after-init-hook `(lambda () ;; remember this directory (setq starter-kit-dir ,(file-name-directory (or load-file-name (buffer-file-name)))) ;; load up the starter kit (add-to-list 'load-path "/Users/schmitta/.emacs.d/org/emacs/site-lisp/org") (require 'org) (org-babel-load-file (expand-file-name "starter-kit.org" starter-kit-dir)))) ;;; init.el ends here #+END_SRC I've turned on the debugger, and there is something that I find a bit strange. Here are the last few lines. ,---- | load("/var/folders/68/fvntfrw92y50gkk_67rkhsfw0000gn/T/org-export-process77683E90" nil t) | command-line-1(("-l" "/Users/schmitta/.emacs.d/init.el" "-l" "/var/folders/68/fvntfrw92y50gkk_67rkhsfw0000gn/T/org-export-process77683E90")) | command-line() | normal-top-level() `---- Why is it loading the second file first? Shouldn't it load init.el first? Is it because of the "after-init-hook"? I also saved the temporary file and added a (print load-path) at the beginning and it has not added the org path at the beginning, so for some reason this code is not executed. Thanks, Alan
> > I've turned on the debugger, and there is something that I find a bit > strange. Here are the last few lines. > > ,---- > | load("/var/folders/68/fvntfrw92y50gkk_67rkhsfw0000gn/T/org-export-process77683E90" nil t) > | command-line-1(("-l" "/Users/schmitta/.emacs.d/init.el" "-l" "/var/folders/68/fvntfrw92y50gkk_67rkhsfw0000gn/T/org-export-process77683E90")) > | command-line() > | normal-top-level() > `---- > > Why is it loading the second file first? Shouldn't it load init.el > first? Is it because of the "after-init-hook"? > Yes, the starter kit waits to load on the after-init-hook so that the Emacs package system will be fully loaded. That is why the other file you load on the command line is loaded first. -- Eric Schulte http://cs.unm.edu/~eschulte
Eric Schulte writes:
>>
>> I've turned on the debugger, and there is something that I find a bit
>> strange. Here are the last few lines.
>>
>> ,----
>> | load("/var/folders/68/fvntfrw92y50gkk_67rkhsfw0000gn/T/org-export-process77683E90" nil t)
>> | command-line-1(("-l" "/Users/schmitta/.emacs.d/init.el" "-l" "/var/folders/68/fvntfrw92y50gkk_67rkhsfw0000gn/T/org-export-process77683E90"))
>> | command-line()
>> | normal-top-level()
>> `----
>>
>> Why is it loading the second file first? Shouldn't it load init.el
>> first? Is it because of the "after-init-hook"?
>
> Yes, the starter kit waits to load on the after-init-hook so that the
> Emacs package system will be fully loaded. That is why the other file
> you load on the command line is loaded first.
Then asynchronous export can't work, as it needs ox in that file. I've
changed my init.el to loading org before the after-init-hook, and I go
further but then I have an error about the "koma-letter" being
unknown. It seems that to go this way I would need to load all of my
export settings before the after-init-hook.
So going the route of having a special init file for that seems even
more relevant now. So I'll ask again: if I want to put some
configuration in another .org file, it is better to #+include it in my
main org configuration file, or to org-babel-load-file it?
Thanks again for your help,
Alan
PS: I really don't understand how configuration options that are loaded
in the after-init-hook can be used during asynchronous export. Is it
working for you (with a more usual org install)?
Alan Schmitt <alan.schmitt@polytechnique.org> writes: > Eric Schulte writes: > >>> >>> I've turned on the debugger, and there is something that I find a bit >>> strange. Here are the last few lines. >>> >>> ,---- >>> | load("/var/folders/68/fvntfrw92y50gkk_67rkhsfw0000gn/T/org-export-process77683E90" nil t) >>> | command-line-1(("-l" "/Users/schmitta/.emacs.d/init.el" "-l" "/var/folders/68/fvntfrw92y50gkk_67rkhsfw0000gn/T/org-export-process77683E90")) >>> | command-line() >>> | normal-top-level() >>> `---- >>> >>> Why is it loading the second file first? Shouldn't it load init.el >>> first? Is it because of the "after-init-hook"? >> >> Yes, the starter kit waits to load on the after-init-hook so that the >> Emacs package system will be fully loaded. That is why the other file >> you load on the command line is loaded first. > > Then asynchronous export can't work, as it needs ox in that file. I've > changed my init.el to loading org before the after-init-hook, and I go > further but then I have an error about the "koma-letter" being > unknown. It seems that to go this way I would need to load all of my > export settings before the after-init-hook. > > So going the route of having a special init file for that seems even > more relevant now. Yes, I'd agree. > So I'll ask again: if I want to put some configuration in another .org > file, it is better to #+include it in my main org configuration file, > or to org-babel-load-file it? > I don't know. > > Thanks again for your help, > > Alan > > PS: I really don't understand how configuration options that are loaded > in the after-init-hook can be used during asynchronous export. Is it > working for you (with a more usual org install)? I haven't used asynchronous export. When I do run exports from the command line, I run Emacs with --batch, and I don't load any of my personal configuration. That way the export can easily be distributed as it doesn't rely on my personal config. -- Eric Schulte http://cs.unm.edu/~eschulte
Hi Eric, Eric Schulte <schulte.eric@gmail.com> writes: > Alan Schmitt <alan.schmitt@polytechnique.org> writes: > >> Eric Schulte writes: >> >>>> >>>> I've turned on the debugger, and there is something that I find a bit >>>> strange. Here are the last few lines. >>>> >>>> ,---- >>>> | load("/var/folders/68/fvntfrw92y50gkk_67rkhsfw0000gn/T/org-export-process77683E90" >>>> | nil t) >>>> | command-line-1(("-l" "/Users/schmitta/.emacs.d/init.el" "-l" >>>> | "/var/folders/68/fvntfrw92y50gkk_67rkhsfw0000gn/T/org-export-process77683E90")) >>>> | command-line() >>>> | normal-top-level() >>>> `---- >>>> >>>> Why is it loading the second file first? Shouldn't it load init.el >>>> first? Is it because of the "after-init-hook"? >>> >>> Yes, the starter kit waits to load on the after-init-hook so that the >>> Emacs package system will be fully loaded. That is why the other file >>> you load on the command line is loaded first. >> >> Then asynchronous export can't work, as it needs ox in that file. I've >> changed my init.el to loading org before the after-init-hook, and I go >> further but then I have an error about the "koma-letter" being >> unknown. It seems that to go this way I would need to load all of my >> export settings before the after-init-hook. >> >> So going the route of having a special init file for that seems even >> more relevant now. > > Yes, I'd agree. > >> So I'll ask again: if I want to put some configuration in another .org >> file, it is better to #+include it in my main org configuration file, >> or to org-babel-load-file it? >> > > I don't know. > >> >> Thanks again for your help, >> >> Alan >> >> PS: I really don't understand how configuration options that are loaded >> in the after-init-hook can be used during asynchronous export. Is it >> working for you (with a more usual org install)? > > I haven't used asynchronous export. > > When I do run exports from the command line, I run Emacs with --batch, > and I don't load any of my personal configuration. That way the export > can easily be distributed as it doesn't rely on my personal config. This is what asynchronous export does, IIUC. Here is the relevant part of a setup I'm using: (setq org-export-in-background t) (setq org-export-async-debug t) (setq org-export-async-init-file (expand-file-name "init.el")) I tangle the initialization file (init.el) from my document. Everything is contained in the one Org file. Asynchronous export works really well for me. hth, Tom -- Thomas S. Dye http://www.tsdye.com
Alan Schmitt writes:
> Eric Schulte writes:
>
>> --8< snip
>>
>> Yes, the starter kit waits to load on the after-init-hook so that the
>> Emacs package system will be fully loaded. That is why the other file
>> you load on the command line is loaded first.
>
> Then asynchronous export can't work, as it needs ox in that file. I've
> changed my init.el to loading org before the after-init-hook, and I go
> further but then I have an error about the "koma-letter" being
> unknown. It seems that to go this way I would need to load all of my
> export settings before the after-init-hook.
I had problems with mixed up org-versions [1]. The starter-kit uses
org-babel to create the lisp files Emacs needs.
To solve this, I added org-mode-from-git's load-path to init.el, before
require org. After that things worked for me. The down-side is that
your init.el is no longer the same as the starter-kit's, which makes
upgrading a bit harder.
Alex
[1] I use prelude, but use org-babel for my private settings, like the
starter-kit does
Alexander Poslavsky <alexander.poslavsky@gmail.com> writes: > Alan Schmitt writes: > >> Eric Schulte writes: >> >>> --8< snip >>> >>> Yes, the starter kit waits to load on the after-init-hook so that the >>> Emacs package system will be fully loaded. That is why the other file >>> you load on the command line is loaded first. >> >> Then asynchronous export can't work, as it needs ox in that file. I've >> changed my init.el to loading org before the after-init-hook, and I go >> further but then I have an error about the "koma-letter" being >> unknown. It seems that to go this way I would need to load all of my >> export settings before the after-init-hook. > > I had problems with mixed up org-versions [1]. The starter-kit uses > org-babel to create the lisp files Emacs needs. > > To solve this, I added org-mode-from-git's load-path to init.el, before > require org. After that things worked for me. The down-side is that > your init.el is no longer the same as the starter-kit's, which makes > upgrading a bit harder. > > Alex > It sounds like this is general a problem. I've just added a portable way to load Org-mode from the init.el. It will now be possible to load a local Emacs from source by setting the ORG_HOME environment variable. If this variable is defined then Org-mode will be loaded from that directory. Note, this addition to the load path now happens *before* the after-init-hook, so it may help with Alan's original problem as well. See [1] for more information on this change. Hope this helps, Footnotes: [1] https://github.com/eschulte/emacs24-starter-kit/commit/99107e9ee84c2935a614d7ac809aa27bce63c037 -- Eric Schulte http://cs.unm.edu/~eschulte
Thomas S. Dye writes:
> I tangle the initialization file (init.el) from my document. Everything
> is contained in the one Org file.
>
> Asynchronous export works really well for me.
As I don't install org from elpa, I removed the after-init-hook part (so
I load the starter kit immediately), and everything now works.
Alan
Alan Schmitt <alan.schmitt@polytechnique.org> writes: > Thomas S. Dye writes: > >> I tangle the initialization file (init.el) from my document. Everything >> is contained in the one Org file. >> >> Asynchronous export works really well for me. > > As I don't install org from elpa, I removed the after-init-hook part (so > I load the starter kit immediately), and everything now works. > > Alan With my latest push to the starter kit you can now simply set the ORG_HOME environment variable instead of modifying that file locally. But it's largely a matter of taste at that point as both options are functionally identical. Cheers, -- Eric Schulte http://cs.unm.edu/~eschulte
Eric Schulte writes:
>> As I don't install org from elpa, I removed the after-init-hook part (so
>> I load the starter kit immediately), and everything now works.
>
> With my latest push to the starter kit you can now simply set the
> ORG_HOME environment variable instead of modifying that file locally.
> But it's largely a matter of taste at that point as both options are
> functionally identical.
Thanks a lot, but I would still need to load the relevant exporters (by
putting them in some configuration file, or evaluated in the exported
file itself). I find it simpler to have my whole configuration loaded
before the export happens.
Alan