I'm writing documentation and one of my documents has started getting really bulky. I decided to break it up into sections and include them all in a main section, but I realized that it's not possible for me to correctly export an html file when I do that.
Example:
I have a main org file:
#+TITLE: SO Example
#+LaTeX_CLASS: memoir
#+OPTIONS: ^:nil LaTeX:nil TeX:nil
* 1st Level
This is the first level.
#+INCLUDE: "nested_includes.org"
nested_includes.org looks like:
** 2nd Level
This is the second level
#+INCLUDE: "single_include.org"
single_include.org looks like:
*** 3rd Level
This is the third level
I build my HTML file using the following command:
C:\...\emacs\bin\emacs.exe parent.org --batch -q --no-site-file --load C:\...\site-lisp\org-html-so.el -f org-export-as-html --kill
This is what my org-html-so.el looks like:
(setq org-export-author-info nil)
(setq org-export-creator-info nil)
(setq org-export-time-stamp-file nil)
(setq org-export-with-timestamps nil)
When I build, I end up getting something like this:
Meanwhile, I'm expecting something like this:
Is this a known issue/limitation with emacs org mode?
Is there a way for me to increase include depth?
Thank you!
I suspect from the function you are using for export that you have an older version of org-mode. In version 8 of org-mode the export functionality was rewritten. I've had a quick look at how I can get this working with the version of org I have installed with my emacs. So for me:
M-x org-version
gives:
Org-mode version 8.2.10 (release_8.2.10 # c:/dev/emacs/share/emacs/24.5/lisp/org/)
Which is shipped with my version of emacs 24.5. Given the same files you created. I changed org-html-so.el to read:
(require 'org)
(require 'ox)
(require 'ox-html)
(setq org-export-author-info nil)
(setq org-export-creator-info nil)
(setq org-export-time-stamp-file nil)
(setq org-export-with-timestamps nil)
Then the emacs invocation was:
emacs.exe parent.org --batch -q --no-site-file --load org-html-so.el -f org-html-export-to-html --kill
Include Depth
This version of include does not seem to limit depth, it does though remember files previously included regions to ensure includes are not recursive.
Upgrading
If you have an earlier version of emacs: you can either upgrade your version of emacs, or you can install a newer version of org, into your existing installation.
To install the newer version through the package manager or install it locally from github. See the page in installation in the Org Manual.
It's worth upgrading, in the least because the later versions are more actively you can take advantage of the latest features. For example you might like the support for html themes org-html-themes.
Related
With emacs24 I'm using org-mode 8.2.8 installed from the tar.gz file available on orgmode.org.
I'm trying to get the infopath loaded so that C-h i m Org Mode RET will give me the org manual.
The org faq mentions two methods - both of which make reference to /path/to/org-mode/info but there isn't any info directory in the 8.2.8 org-mode root directory, only a doc directory.
Compiling org-mode 8.2.8 with the make command from the org-mode 8.2.8 root directory builds the file /usr/share/org which seemingly contains the manual for org 8.2.8 but I'm not able to load that with neither methods mentioned in the FAQ.
Note: I've previously asked this question. In that case I was using the version of org-mode that shipped with emacs24 and apt-get install emacs24-common-non-dfsg got me the man pages. This is a different case in which I'm using another version of org-mode than the default.
The doc directory contains org.texi. Add that to Info-directory-list.
(add-to-list 'Info-directory-list "/path/to/org-mode/doc")
If info hasn't been loaded yet, use
(eval-after-load "info"
'(progn
(info-initialize)
(add-to-list 'Info-directory-list "/path/to/org-mode/doc")))
or
(add-to-list
'Info-default-directory-list "/path/to/org-mode/doc")
I'm using the following "generic" solution to add a couple of Info paths:
(with-eval-after-load "info"
(setq Info-directory-list
`(,(expand-file-name
(concat (file-name-directory (locate-library "org")) "../doc/"))
"c:/cygwin/usr/share/info/"
,#Info-directory-list)))
(For Emacs 24.4, because of the with-eval-after-load)
I installed emacs 24.3.2 from git.
In this version there is org 7.9 released.
Next I installed last org-mode from git and compiled it (make autoload).
Now I need to launch org-reload to have the latest version (8) else I have the builtin version (7.9).
So I had in init.el:
(call-interactively 'org-reload)
returns:
Cannot open load file: ob.el
So I guess I have to call it after org is loaded (add-hook 'after-init-hook).
But the same error appears.
So I don't know how to have the last org-mode installed on my current emacs24.3.2 which already have a builtin org-mode.
Try to eval this:
(add-to-list 'load-path "~/path/to/git/org-mode")
(org-reload)
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Emacs 24 Package System Initialization Problems
I am using Emacs 24. I have the ELPA and Marmalade repos added. Using 'package' I installed 'auto-complete'. I have the following lines added to my init.el:
(require 'auto-complete-config)
(ac-config-default)
When I start Emacs, I get the error
File error: Cannot open load file, auto-complete-config
But then I use
M-x load-file
and load the same ~/.emacs.d/init.el file, it then works fine with the prompt saying
Loading /home/user/.emacs.d/init.el (source)...done
How is the usual loading different from the 'M-x load-file' command? In the start of the init.el file I do the following, is this somehow effecting the package from loading.
(add-to-list 'load-path "~/.emacs.d")
(load "custom_code")
As mentioned in the comment below: The answer by phils to the duplicate question is probably more helpful than this one
This almost certainly means that your init.el file is getting run before the code that sorts out the packages for package.el. The latter code adds the directory with the auto-complete library to your load path.
I'm still using ELPA, rather than package.el. With elpa, there's a snippet that looks like this that gets installed at the bottom of your .emacs.
;;; This was installed by package-install.el.
;;; This provides support for the package system and
;;; interfacing with ELPA, the package archive.
;;; Move this code earlier if you want to reference
;;; packages in your .emacs.
(when
(load
(expand-file-name "~/.emacs.d/elpa/package.el"))
(package-initialize))
As the comment suggests, you probably want to put your equivalent package.el initialization code before the stuff that loads init.el.
Finally: I notice you mention adding .emacs.d to your load-path. The Emacs load path is not recursive, so that probably won't do what you need (assuming that your libraries live in subdirectories). Years ago, I wrote this snippet to load up various libraries of elisp code that I'd written. You might find it useful. (Obviously, it'll only work on unixy systems with a shell and a find command. It's reasonably slow, but this seems to be shell-command-to-string, which takes several milliseconds even running "echo hello" or the like)
(defun find-elisp-dirs (dir)
"Find all directories below DIR containing elisp sources, ignoring those"
(split-string
(shell-command-to-string
(format "find %s -iname '*.el' -printf '%%h\\n' | sort -u"
(expand-file-name dir t)))))
I'm trying to get JSHint to work with Flymake.
jshint is indeed installed in /opt/bin and works. /opt/bin is in Emacs' exec-path.
I've followed the directions on the EmacsWiki and have this in my init.el:
(defun flymake-jshint-init ()
(let* ((temp-file (flymake-init-create-temp-buffer-copy
'flymake-create-temp-inplace))
(local-file (file-relative-name
temp-file
(file-name-directory buffer-file-name))))
(list "jshint" (list local-file))))
(setq flymake-err-line-patterns
(cons '("^ [[:digit:]]+ \\([[:digit:]]+\\),\\([[:digit:]]+\\): \\(.+\\)$"
nil 1 2 3)
flymake-err-line-patterns))
(add-to-list 'flymake-allowed-file-name-masks
'("\\.js\\'" flymake-jshint-init))
When I open JavaScript files, my modeline appears as:
[(Javascript Flymake* AC)]
This is odd because the * usually doesn't appear when I'm using Flymake with C++ or Python. According to the Flymake docs, Flymake* means "Flymake is currently running." However, Flymake isn't showing any errors.
I've checked the *Messages* buffer but it only lists a few lines of Fontifying foo.js... (regexps...................). No errors.
Other suggestions?
Try using M-: to execute (setq flymake-log-level 3), which will cause flymake to print debug info into *Messages*.
Here's how I use flymake with jslint, which works nicely for me -- that code might give you a clue about what's going wrong for you.
You might also consider js2-mode, which provides some language-aware lint-like warnings without resorting to running an external process.
I found a project called jshint-mode and tried that. It created a buffer called *jshint-mode* which revealed the error: JSHint couldn't find the formidable module.
I ran M-x setenv in Emacs to set NODE_PATH so that jshint could find the formidable library. I also set NODE_PATH in /etc/profile.
jshint-mode did not work for me (I use Linux Mint 14 'Nadia') -- I was getting errors with "flymake's configuration" when it runs curl to talk to the Node.js instance running the jshint script. This was perplexing, and I'm not familiar with ELisp to go around messing with the .el files.
I solved this by instead going straight to the Emacs flymake project fork on github which now has support for jshint built-in (it needs to be installed as npm -g install jshint which in turn requires you to install npm and node.js if you haven't already). This made things work.
One more caveat: on my Linux box, node was an executable already existing in /usr/sbin and I had to make a symbolic link named node in /usr/local/bin to override the former. This was necessary as the Node.js binary for Linux Mint (possibly Ubuntu as well, I haven't checked) is named nodejs instead and will cause many scripts written assuming a binary name of node to fail. You can test this by typing node: if it is the pre-existing binary it generally returns to the prompt silently, but if it is Node.js it prompts you with a > (you can Ctrl-D to quit out of there)
I'm very new to emacs and I'm using version 23.2 on Windows. I'm trying to get CEDET working, but when I require it in .emacs it fails to find the file:
File error: Cannot open load file
I was able to get cedet working by loading it manually with:
(load "C:/emacs/lisp/cedet/cedet.el")
But I still can't require other files from cedet like semantic-gcc or semantic-ia.
Here's my .emacs file:
(load "C:/emacs/lisp/cedet/cedet.el")
(global-ede-mode t)
(semantic-mode 1)
;(semantic-load-enable-excessive-code-helpers)
(require 'semantic-ia)
(require 'semantic-gcc)
It's like emacs isn't looking for these files in its own path, and I did try
(add-to-list 'load-path "C:/emacs/lisp/cedet")
With a lot of other variations but none worked.
Firstly, you need to find the reason that cedet won't load with a simple (require 'cedet).
Is Emacs installed at c:\emacs? (ie the emacs.exe you are running is c:\emacs\bin\emacs.exe)
Is something setting EMACSLOADPATH externally from Emacs (your environment, or in the registry under HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER /Software/GNU/Emacs?
Is there another installation of an older version of CEDET on your load path?
Has c:\emacs\lisp\subdirs.el been edited to remove the cedet subdirectory?
Once you've solved that, note that the paths were changed when CEDET was merged into Emacs to accommodate old systems that have limitations on file name lengths. But at the same time, the autoloads were improved, so you shouldn't need to explicitly require those files any more. If you still do, the following should work:
(require 'semantic/ia)
(require 'semantic/bovine/gcc)