[O] bug#11491: 24.0.96 instead of 23.0.96
The version string has an typo in the original report. I guess it is better to send it again with the correct version in the subject. Should/Can I close this bug-report? I will try. Albert.
Re: [O] [PATCH] Document ID special property.
Adam Spiers orgm...@adamspiers.org writes: * doc/org.texi: add ID to the list of special properties. * doc/org.texi: Fix typo in description of the 'Hooks' section * lisp/org-html.el: add hyperlink to http://orgmode.org/ from export footer Applied, thanks. I also added the link to Emacs website, to be fair. Best, -- Bastien
Re: [O] Zero Warnings against Emacs-24
Hi Martyn, Martyn Jago martyn.j...@btinternet.com writes: Thanks Bastien, Achim, and Maintainers ~ I for one think such attention to detail is a real sign of quality. Thanks to Achim on this one, and to John Wiegley on getting rid of other warnings in org-remember.el. And thanks to you for triggering the first call attempts in fixing things in this area! But let's be aware that we didn't really _fixed_ the issues raised by the warnings, we only fooled the byte-compiler on those that cannot be really fixed. Also with zero test failures on my system - this must be a good sign for Emacs-24 up-coming release. Let's hope so! -- Bastien
Re: [O] Tables in Plain Lists
Achim Gratz strom...@nexgo.de writes: Until some patches that Bastien is reviewing have been committed, it is important that the autoloads are done last or that org is installed to some other place than the Git worktree. I just applied Achim's patches about this issue. -- Bastien
[O] M-x org-version RET now produces some sensible in all possible install/use-cases
Hi all, an old haitian saying goes like this: Ak pasyans ou vle lombik fourmi. which translates: With patience, you see the ombilic of an ant. One of my favorite saying when I spent some time working in Port-au-Prince, where you get nothing with a lot of patience. Thanks to patient and hard work of Achim, M-x org-version RET should now return something sensible in each use-case. Please pull and report any oddities in this area. Best, -- Bastien
Re: [O] org-export-preprocess-hook and the new exporter (was Re: Using Org for a dissertation)
Hi Eric, Eric S Fraga e.fr...@ucl.ac.uk writes: I was intrigued by the comment above regarding the ignoreheading tag. Sounded just like what I needed. However, it doesn't do anything with org /out-of-the-box/. A little searching led to Suvayu's posting in stackoverflow [1] and that does the job nicely, but only for the standard (read: old) export engine. stackoverflow.com is really great, and many questions are posted and answered there. When it makes sense, we should try to backport useful information from there to Worg (org-faq.org and org-hacks.org are the two possible targets in general), so that we keep things centralized a bit. At least I try to keep this in mind when I reply to stuff on SO. Thanks! -- Bastien
[O] bug#11491: 24.0.96 instead of 23.0.96
Fixed in latest Org (from git.) Quotes are now mandatory and filenames can contain spaces. Thanks for suggesting this. -- Bastien
[O] Code blocks in lists?
Hello, As demonstrated by the following ECM, it seems that I can't put code blocks inside lists: --8---cut here---start-8--- * Installation 1. Download and install color-theme. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-6.6.0) (require 'color-theme) #+end_src 2. Download and install color-theme-leuven. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-leuven) (require 'color-theme-leuven) #+end_src 3. Restart Emacs. --8---cut here---end---8--- exports to the following HTML page: --8---cut here---start-8--- * Installation 1. Download and install color-theme. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-6.6.0) (require 'color-theme) #+end_src 1. Download and install color-theme-leuven. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-leuven) (require 'color-theme-leuven) #+end_src 1. Restart Emacs. --8---cut here---end---8--- I guess this is the same root cause as the problem I tried to described at http://lists.gnu.org/archive/html/emacs-orgmode/2012-02/msg00247.html. Here, the fact that it is an enumerated list makes the problem stand out. Any advice? Best regards, Seb -- Sebastien Vauban
Re: [O] org-export-preprocess-hook and the new exporter (was Re: Using Org for a dissertation)
Hello, Eric S Fraga e.fr...@ucl.ac.uk writes: This is probably more for Nicolas... and apologies for hijacking the thread slightly! I was intrigued by the comment above regarding the ignoreheading tag. Sounded just like what I needed. However, it doesn't do anything with org /out-of-the-box/. A little searching led to Suvayu's posting in stackoverflow [1] and that does the job nicely, but only for the standard (read: old) export engine. The question is: is there an equivalent hook for the new exporter? For heavy structure modifications (like headlines removal), there is `org-export-before-parsing-hook' and the dynamically bound variable `org-export-current-backend'. Another way to solve the problem could be to implement your own headline parser: #+BEGIN_SRC emacs-lisp (defun my-e-latex-headline (headline contents info) (if (member ignoreheading (org-element-property :tags headline)) contents (org-e-latex-headline headline contents info))) #+END_SRC Then you can either install it in the current `e-latex' back-end: #+BEGIN_SRC emacs-lisp (add-to-list 'org-e-latex-translate-table '(headline . my-e-latex-headline)) #+END_SRC Or you can define your own back-end for this purpose: #+BEGIN_SRC emacs-lisp (org-export-define-derived-backend dissertation e-latex :translate-alist ((template . my-e-latex-headline))) (defun org-dissertation-export-to-pdf (optional subtreep visible-only body-only ext-plist pub-dir) (interactive) (org-e-latex-compile (let ((outfile (org-export-output-file-name .tex subtreep pub-dir))) (org-export-to-file 'dissertation outfile subtreep visible-only body-only ext-plist #+END_SRC You need a recent Org version to do this, though. Regards, -- Nicolas Goaziou
[O] [PATCH] XEmacs compatibility (was: Zero Warnings against Emacs-24)
Martyn Jago writes: It is extremely good to see Org-mode builds against Emacs-24 with zero warnings. I just see that this broke XEmacs... but there is already a compatibility macro defined, so simply use it. From 64b63af7bd7dbd974bef2e70c6ea0fc5b9b3d982 Mon Sep 17 00:00:00 2001 From: Achim Gratz strom...@stromeko.de Date: Fri, 18 May 2012 13:16:11 +0200 Subject: [PATCH] use org-no-warnings macro for XEmacs compatibility * lisp/org-agenda.el: Replace with-no-warnings with org-no-warnings (defined in org-macs.el). * lisp/org-bbdb.el: Replace with-no-warnings with org-no-warnings (defined in org-macs.el). * lisp/org-clock.el: Replace with-no-warnings with org-no-warnings (defined in org-macs.el). * lisp/org.el: Replace with-no-warnings with org-no-warnings (defined in org-macs.el). --- lisp/org-agenda.el |4 ++-- lisp/org-bbdb.el |2 +- lisp/org-clock.el |4 ++-- lisp/org.el|8 4 files changed, 9 insertions(+), 9 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 07e6a4f..cfd3e25 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -91,8 +91,8 @@ (defvar org-habit-show-habits-only-for-today) (defvar org-agenda-buffer-name) (defvar org-agenda-overriding-header) (defvar org-agenda-title-append nil) -(with-no-warnings (defvar entry)) ;; unprefixed, from calendar.el -(with-no-warnings (defvar date)) ;; unprefixed, from calendar.el +(org-no-warnings (defvar entry)) ;; unprefixed, from calendar.el +(org-no-warnings (defvar date)) ;; unprefixed, from calendar.el (defvar org-agenda-undo-list) (defvar org-agenda-pending-undo-list) (defvar original-date) ; dynamically scoped, calendar.el does scope this diff --git a/lisp/org-bbdb.el b/lisp/org-bbdb.el index 18f1dc9..51b0083 100644 --- a/lisp/org-bbdb.el +++ b/lisp/org-bbdb.el @@ -122,7 +122,7 @@ (declare-function calendar-leap-year-p calendar (year)) (declare-function diary-ordinal-suffix diary-lib (n)) -(with-no-warnings (defvar date)) ;; unprefixed, from calendar.el +(org-no-warnings (defvar date)) ;; unprefixed, from calendar.el ;; Customization diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 0e08eb9..70c015b 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -1379,7 +1379,7 @@ (defun org-clock-out (optional fail-quietly at-time) (if fail-quietly (throw 'exit t) (error No active clock))) (let (ts te s h m remove) (save-excursion ; Do not replace this with `with-current-buffer'. - (with-no-warnings (set-buffer (org-clocking-buffer))) + (org-no-warnings (set-buffer (org-clocking-buffer))) (save-restriction (widen) (goto-char org-clock-marker) @@ -1523,7 +1523,7 @@ (defun org-clock-cancel () (force-mode-line-update) (error No active clock)) (save-excursion ; Do not replace this with `with-current-buffer'. -(with-no-warnings (set-buffer (org-clocking-buffer))) +(org-no-warnings (set-buffer (org-clocking-buffer))) (goto-char org-clock-marker) (delete-region (1- (point-at-bol)) (point-at-eol)) ;; Just in case, remove any empty LOGBOOK left over diff --git a/lisp/org.el b/lisp/org.el index 835e422..11cf70d 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -214,7 +214,7 @@ (defcustom org-clone-delete-id nil (defun org-git-version () N/A !!check installation!!) (and (load (concat (org-find-library-dir org) ../UTILITIES/org-fixup.el) 'noerror 'nomessage 'nosuffix) - (with-no-warnings (org-fixup + (org-no-warnings (org-fixup ;;;###autoload (defun org-version (optional here) Show the org-mode version in the echo area. @@ -4901,9 +4901,9 @@ (defvar org-finish-function nil ;; FIXME: Occasionally check by commenting these, to make sure ;;no other functions uses these, forgetting to let-bind them. -(with-no-warnings (defvar entry)) ;; unprefixed, from calendar.el +(org-no-warnings (defvar entry)) ;; unprefixed, from calendar.el (defvar org-last-state) -(with-no-warnings (defvar date)) ;; unprefixed, from calendar.el +(org-no-warnings (defvar date)) ;; unprefixed, from calendar.el ;; Defined somewhere in this file, but used before definition. (defvar org-entities) ;; defined in org-entities.el @@ -15577,7 +15577,7 @@ (defun org-order-calendar-date-args (arg1 arg2 arg3) (list arg2 arg1 arg3)) ((eq calendar-date-style 'iso) (list arg2 arg3 arg1))) -(with-no-warnings ;; european-calendar-style is obsolete as of version 23.1 +(org-no-warnings ;; european-calendar-style is obsolete as of version 23.1 (if (org-bound-and-true-p european-calendar-style) (list arg2 arg1 arg3) (list arg1 arg2 arg3) -- 1.7.9.2 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: [O] emacs org mode publish to latex failed with strings like __aaa_cc__
Hi Nick: I had added the option to my org file. What I want to ensure is that this is maybe a bug of emacs org mode. I know _a string_ will try to convert to underline string in latex, by emacs variable org-export-latex-emphasis-alist. Maybe this is why it is translated into wrong latex codes. Xu Jingtao jingta...@gmail.com wrote: Hi all: If I write some string like __aaa_cc__ in org file,then publish it to pdf using latex, it will failed and the output is wrong. even I can use ~__aaa_cc__~, it's not a good way do it. Can you fix it or I am wrong? By default, underscores indicate subscripts (a tradition that comes from LaTeX syntax - similarly, carets indicate superscripts). If you don't want that, you can add #+OPTIONS: ^:nil at the top of the file: this option disables superscripts and subscripts. See (info (org) Export options) Nick ___ With Best Regards. jingtao.
Re: [O] emacs org mode publish to latex failed with strings like __aaa_cc__
Xu Jingtao jingta...@gmail.com wrote: Hi Nick: I had added the option to my org file. What I want to ensure is that this is maybe a bug of emacs org mode. I know _a string_ will try to convert to underline string in latex, by emacs variable org-export-latex-emphasis-alist. Maybe this is why it is translated into wrong latex codes. Ah, OK - the problem is that no matter how the option is set, the output still leads to latex errors and no PDF is produced (at least with the old exporter - I haven't tried with ngz's new one, but that woule be a good experiment to try). Now that I've tried it, I think you are right: it is a bug in the old exporter, in that it should produce legal latex either way. Nick Xu Jingtao jingta...@gmail.com wrote: Hi all: If I write some string like __aaa_cc__ in org file,then publish it to pdf using latex, it will failed and the output is wrong. even I can use ~__aaa_cc__~, it's not a good way do it. Can you fix it or I am wrong? By default, underscores indicate subscripts (a tradition that comes from LaTeX syntax - similarly, carets indicate superscripts). If you don't want that, you can add #+OPTIONS: ^:nil at the top of the file: this option disables superscripts and subscripts. See (info (org) Export options) Nick ___ With Best Regards. jingtao.
Re: [O] emacs org mode publish to latex failed with strings like __aaa_cc__
Hello, Xu Jingtao jingta...@gmail.com writes: What I want to ensure is that this is maybe a bug of emacs org mode. I know _a string_ will try to convert to underline string in latex, by emacs variable org-export-latex-emphasis-alist. Maybe this is why it is translated into wrong latex codes. Why is it wrong LaTeX code? You're asking Org to put an underline there, and there you have. Nevertheless, I think it would be useful to have an entity for underscore character. Something like: (us \\_ nil _ _ _ _) Regards, -- Nicolas Goaziou
Re: [O] emacs org mode publish to latex failed with strings like __aaa_cc__
Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, Xu Jingtao jingta...@gmail.com writes: What I want to ensure is that this is maybe a bug of emacs org mode. I know _a string_ will try to convert to underline string in latex, by emacs variable org-export-latex-emphasis-alist. Maybe this is why it is translated into wrong latex codes. Why is it wrong LaTeX code? You're asking Org to put an underline there, and there you have. The old exporter latex output doesn't compile. I tried the new exporter does it correctly, with either setting of the option. Nick Nevertheless, I think it would be useful to have an entity for underscore character. Something like: (us \\_ nil _ _ _ _)
Re: [O] emacs org mode publish to latex failed with strings like __aaa_cc__
Hello,
Nick Dokos nicholas.do...@hp.com writes:
The old exporter latex output doesn't compile.
Ah ok, I only tried with the experimental one.
I tried the new exporter does it correctly, with either setting of the
option.
The new one exports __aaa_b__ as \underline{\underline{aaa$_b$}}.
I think the OP wants a verbatim \_\_aaa\_b\_\_ instead.
Hence my underscore suggestion, which would also solve the UNDER_LINE
problem without resorting to (unsupported) tricks like UNDER\_LINE.
Regards,
--
Nicolas Goaziou
Re: [O] emacs org mode publish to latex failed with strings like __aaa_cc__
Nicolas Goaziou n.goaz...@gmail.com wrote:
Hello,
Nick Dokos nicholas.do...@hp.com writes:
The old exporter latex output doesn't compile.
Ah ok, I only tried with the experimental one.
I tried the new exporter does it correctly, with either setting of the
option.
The new one exports __aaa_b__ as \underline{\underline{aaa$_b$}}.
I think the OP wants a verbatim \_\_aaa\_b\_\_ instead.
That can be done with ~__aaa_b__~ though.
Nick
Hence my underscore suggestion, which would also solve the UNDER_LINE
problem without resorting to (unsupported) tricks like UNDER\_LINE.
Regards,
--
Nicolas Goaziou
Re: [O] emacs org mode publish to latex failed with strings like __aaa_cc__
Nick Dokos nicholas.do...@hp.com writes:
The new one exports __aaa_b__ as \underline{\underline{aaa$_b$}}.
I think the OP wants a verbatim \_\_aaa\_b\_\_ instead.
That can be done with ~__aaa_b__~ though.
Yes, but I assume that aaa could also contain other Org syntax, like an
entity.
So __a\alpha{}a_b__ is still a problem.
Re: [O] how to install org from git repo / org-version problem
Hi Achim, * Achim Gratz strom...@nexgo.de [17. May. 2012]: Gregor Zattler writes: Thanks for your suggestion, I did cd to working copy did make update autoloads was astonished that this pulls from the repo, saw the compiling and the generation of the manual, started Emacs -Q -l ~/.emacs but the result of org-version is the same, e.g. no version string shown. O.K. I do make update autoloads and therefore I do this test with Org-mode version 7.8.10 (release_7.8.10-564-g893a09 @ /home/grfz/src/org-mode/lisp/) (e.g. with your patch ensure that M-x org-version always delivers something useful applied) Well, try something different then. First off, check you have these two files in the lisp directory: org-install.el org-version.el ~/src/org-mode[GIT]$ find |egrep org-(install|version).el ./lisp/org-version.el~ ./lisp/org-version.el ./lisp/org-install.el~ ./lisp/org-install.el The files are there. This is what 'make autoloads' should produce. Check that you do _not_ have org-install.el or org.el (or any .el file, really) in the directory that you start Emacs from. Then do: cd /tmp 0 grfz@boo:/tmp$ find |egrep \.el$ 1 grfz@boo:/tmp$ no *.el files in /tmp emacs -q -no-site-file -Q -L ~/src/org-mode/lisp -l org-install.el 0 grfz@boo:/tmp$ Emacs -q -no-site-file -Q -L ~/src/org-mode/lisp -l org-install.el table-indentation-test.org Do M-x locate-library org M-x locate-library org-install M-x locate-library org-version M-x org-version in that Emacs and tell me what you get in *Messages*. Library is file ~/src/org-mode/lisp/org.elc Library is file ~/src/org-mode/lisp/org-install.el Library is file ~/src/org-mode/lisp/org-version.el And with respect to the original problem: The table is not indented. My guess is that this will resolve itself once you find out why the above isn't working as it should. Your guess is correct. Thank you very much. Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.-
Re: [O] How to get to work non-interactive publishing?
Mikhail Titov m...@gmx.us writes: Hello! I can publish project if I don’t use –-batch . So the following works just fine: emacs -nw --eval '(org-publish-project myproj)' However nothing happens if I try emacs --batch --eval '(org-publish-project myproj)' Does anybody have an idea how to pin point the problem? It just returns almost instantaneously with no output to stderr. I do use ESS, and I have lots of R code some of which is intentionally non-cached. I’m running GNU Emacs 24.1.50.2 (revno: 108254) with default orgmode if it makes any difference. Thank you, Mikhail Hi Mikhail, Using batch mode shouldn't be causing any problems with the export process, is it possible that something in your personal config is not compatible with batch-mode? I have a number of projects in which I export using a batch Emacs process (generally from a make file). My Makefile rules tend to look like the following. EMACS=emacs BATCH_EMACS=$(EMACS) --batch -Q -l init.el document.org ... document.tex: document.org init.el $(BATCH_EMACS) -f org-export-as-latex where init.el contains all of the init necessary for the particular project. For a complete working example see the replication materials at http://www.jstatsoft.org/v46/i03. Best, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Code blocks in lists?
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hello, As demonstrated by the following ECM, it seems that I can't put code blocks inside lists: --8---cut here---start-8--- * Installation 1. Download and install color-theme. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-6.6.0) (require 'color-theme) #+end_src 2. Download and install color-theme-leuven. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-leuven) (require 'color-theme-leuven) #+end_src 3. Restart Emacs. --8---cut here---end---8--- exports to the following HTML page: --8---cut here---start-8--- * Installation 1. Download and install color-theme. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-6.6.0) (require 'color-theme) #+end_src 1. Download and install color-theme-leuven. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-leuven) (require 'color-theme-leuven) #+end_src 1. Restart Emacs. --8---cut here---end---8--- I guess this is the same root cause as the problem I tried to described at http://lists.gnu.org/archive/html/emacs-orgmode/2012-02/msg00247.html. Here, the fact that it is an enumerated list makes the problem stand out. Any advice? Hi Seb, Your example works as expected on my system (both with my config loaded and without my personal config loaded). Could you try to reproduce the problem using Emacs -Q to see if the issue lies somewhere in your configuration? Thanks, Best regards, Seb -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Code blocks in lists?
Hi Nicolas, Nicolas Goaziou wrote: Sebastien Vauban writes: As demonstrated by the following ECM, it seems that I can't put code blocks inside lists. I guess this is the same root cause as the problem I tried to described at http://lists.gnu.org/archive/html/emacs-orgmode/2012-02/msg00247.html. Here, the fact that it is an enumerated list makes the problem stand out. I still cannot reproduce it. What happens if you eval: (let ((org-current-export-file (current-buffer))) (org-export-blocks-preprocess)) in your buffer? * Before command --8---cut here---start-8--- 1. Download and install color-theme. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-6.6.0) (require 'color-theme) #+end_src 2. Download and install color-theme-leuven. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-leuven) (require 'color-theme-leuven) #+end_src 3. Restart Emacs. --8---cut here---end---8--- * Command to execute --8---cut here---start-8--- (let ((org-current-export-file (current-buffer))) (org-export-blocks-preprocess)) --8---cut here---end---8--- * After command --8---cut here---start-8--- 1. Download and install color-theme. #+BEGIN_SRC emacs-lisp (add-to-list 'load-path /path/to/color-theme-6.6.0) (require 'color-theme) #+END_SRC 2. Download and install color-theme-leuven. #+BEGIN_SRC emacs-lisp (add-to-list 'load-path /path/to/color-theme-leuven) (require 'color-theme-leuven) #+END_SRC 3. Restart Emacs. --8---cut here---end---8--- * Summary of the changes The code blocks meta data: - is indented in column 0 - becomes uppercased - gets a trailing space added * Note If I go at the end of (or just below) the text 3. Restart Emacs, and press C-RET, I get: --8---cut here---start-8--- 3. Restart Emacs. 4. --8---cut here---end---8--- in the Before command section, while I get: --8---cut here---start-8--- 1. Restart Emacs. 2. --8---cut here---end---8--- in the After command section. Hence, they do not share the same view on identifying the current list. Best regards, Seb -- Sebastien Vauban
Re: [O] Code blocks in lists?
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Nicolas, Nicolas Goaziou wrote: Sebastien Vauban writes: As demonstrated by the following ECM, it seems that I can't put code blocks inside lists. I guess this is the same root cause as the problem I tried to described at http://lists.gnu.org/archive/html/emacs-orgmode/2012-02/msg00247.html. Here, the fact that it is an enumerated list makes the problem stand out. I still cannot reproduce it. What happens if you eval: (let ((org-current-export-file (current-buffer))) (org-export-blocks-preprocess)) in your buffer? * Before command --8---cut here---start-8--- 1. Download and install color-theme. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-6.6.0) (require 'color-theme) #+end_src 2. Download and install color-theme-leuven. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-leuven) (require 'color-theme-leuven) #+end_src 3. Restart Emacs. --8---cut here---end---8--- * Command to execute --8---cut here---start-8--- (let ((org-current-export-file (current-buffer))) (org-export-blocks-preprocess)) --8---cut here---end---8--- * After command --8---cut here---start-8--- 1. Download and install color-theme. #+BEGIN_SRC emacs-lisp (add-to-list 'load-path /path/to/color-theme-6.6.0) (require 'color-theme) #+END_SRC 2. Download and install color-theme-leuven. #+BEGIN_SRC emacs-lisp (add-to-list 'load-path /path/to/color-theme-leuven) (require 'color-theme-leuven) #+END_SRC 3. Restart Emacs. --8---cut here---end---8--- * Summary of the changes The code blocks meta data: - is indented in column 0 - becomes uppercased - gets a trailing space added * Note If I go at the end of (or just below) the text 3. Restart Emacs, and press C-RET, I get: --8---cut here---start-8--- 3. Restart Emacs. 4. --8---cut here---end---8--- in the Before command section, while I get: --8---cut here---start-8--- 1. Restart Emacs. 2. --8---cut here---end---8--- in the After command section. Hence, they do not share the same view on identifying the current list. Best regards, Seb Hi Seb, Sorry I missed the bit about `org-src-preserve-indentation', indeed there was a bug in the block indentation during export. I've just pushed up a fix, please let me know if you continue to have problems. Thanks, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] how to install org from git repo / org-version problem
Gregor Zattler writes: [...] Now it looks like it should. Your guess is correct. Thank you very much. You're welcome. With the patches now in place, an explicit make autoloads has become unneccesary and simply make update should keep you current. If you don't want tthe PDF documentation made during the update, uncomment the line with ORG_MAKE_DOC in local.mk. 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: [O] Headline terminator with indentation on
Thanks for the clarification. I'm happy just knowing that it isn't supported... On Tuesday, May 15, 2012 at 6:55 PM, Nick Dokos wrote: Avery Chan avery+orgm...@ootbdev.com (mailto:avery+orgm...@ootbdev.com) wrote: I have visual-line-mode and indentation turned on. I am having difficulty (i.e. I am unable to) moving text that I don't want associated with a headline to be demoted (i.e. flush left) after the headline is created. It seems that org mode considers everything under a headline to be a subsection of that headline. So for example I have: -- EXAMPLE - * Great escape * Anyways * Help Blah blah blah Blah blah blah -- EXAMPLE - Which, when folded, is rendered as -- EXAMPLE - * Great escape * Anyways * Help... -- EXAMPLE - I would like it to look like this: -- EXAMPLE - * Great escape * Anyways * Help... Blah blah blah -- EXAMPLE - Meaning that the text at the bottom is not considered a part of the *Help heading. I have read the documentation on headings but haven't found anything helpful. Is there a variable to set to determine a headline terminator? Short answer: you can't do that. There's been extensive discussion on the mailing list about this but I can't remember the topic and my quick search was unsuccessful: maybe one of the participants can provide pointers to the discussions? Nick
Re: [O] **: Re: Code blocks in lists?
Hi Nicolas, Nicolas Goaziou wrote: Sebastien Vauban writes: As demonstrated by the following ECM, it seems that I can't put code blocks inside lists. I guess this is the same root cause as the problem I tried to described at http://lists.gnu.org/archive/html/emacs-orgmode/2012-02/msg00247.html. Here, the fact that it is an enumerated list makes the problem stand out. I still cannot reproduce it. What happens if you eval: (let ((org-current-export-file (current-buffer))) (org-export-blocks-preprocess)) in your buffer? * Before command --8---cut here---start-8--- 1. Download and install color-theme. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-6.6.0) (require 'color-theme) #+end_src 2. Download and install color-theme-leuven. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-leuven) (require 'color-theme-leuven) #+end_src 3. Restart Emacs. --8---cut here---end---8--- * Command to execute --8---cut here---start-8--- (let ((org-current-export-file (current-buffer))) (org-export-blocks-preprocess)) --8---cut here---end---8--- * After command --8---cut here---start-8--- 1. Download and install color-theme. #+BEGIN_SRC emacs-lisp (add-to-list 'load-path /path/to/color-theme-6.6.0) (require 'color-theme) #+END_SRC 2. Download and install color-theme-leuven. #+BEGIN_SRC emacs-lisp (add-to-list 'load-path /path/to/color-theme-leuven) (require 'color-theme-leuven) #+END_SRC 3. Restart Emacs. --8---cut here---end---8--- * Summary of the changes The code blocks meta data: - is indented in column 0 - becomes uppercased - gets a trailing space added * Note If I go at the end of (or just below) the text 3. Restart Emacs, and press C-RET, I get: --8---cut here---start-8--- 3. Restart Emacs. 4. --8---cut here---end---8--- in the Before command section, while I get: --8---cut here---start-8--- 1. Restart Emacs. 2. --8---cut here---end---8--- in the After command section. Hence, they do not share the same view on identifying the current list. Best regards, Seb -- Sebastien Vauban
Re: [O] Code blocks in lists?
Hello, Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: Hello, As demonstrated by the following ECM, it seems that I can't put code blocks inside lists: * Installation 1. Download and install color-theme. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-6.6.0) (require 'color-theme) #+end_src 2. Download and install color-theme-leuven. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-leuven) (require 'color-theme-leuven) #+end_src 3. Restart Emacs. I guess this is the same root cause as the problem I tried to described at http://lists.gnu.org/archive/html/emacs-orgmode/2012-02/msg00247.html. Here, the fact that it is an enumerated list makes the problem stand out. I still cannot reproduce it. Any advice? What happens if you eval: (let ((org-current-export-file (current-buffer))) (org-export-blocks-preprocess)) in your buffer? Regards, -- Nicolas Goaziou
Re: [O] **: Re: Code blocks in lists?
Hi Nicolas, Nicolas Goaziou wrote: Sebastien Vauban writes: As demonstrated by the following ECM, it seems that I can't put code blocks inside lists. I guess this is the same root cause as the problem I tried to described at http://lists.gnu.org/archive/html/emacs-orgmode/2012-02/msg00247.html. Here, the fact that it is an enumerated list makes the problem stand out. I still cannot reproduce it. What happens if you eval: (let ((org-current-export-file (current-buffer))) (org-export-blocks-preprocess)) in your buffer? * Before command --8---cut here---start-8--- 1. Download and install color-theme. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-6.6.0) (require 'color-theme) #+end_src 2. Download and install color-theme-leuven. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-leuven) (require 'color-theme-leuven) #+end_src 3. Restart Emacs. --8---cut here---end---8--- * Command to execute --8---cut here---start-8--- (let ((org-current-export-file (current-buffer))) (org-export-blocks-preprocess)) --8---cut here---end---8--- * After command --8---cut here---start-8--- 1. Download and install color-theme. #+BEGIN_SRC emacs-lisp (add-to-list 'load-path /path/to/color-theme-6.6.0) (require 'color-theme) #+END_SRC 2. Download and install color-theme-leuven. #+BEGIN_SRC emacs-lisp (add-to-list 'load-path /path/to/color-theme-leuven) (require 'color-theme-leuven) #+END_SRC 3. Restart Emacs. --8---cut here---end---8--- * Summary of the changes The code blocks meta data: - is indented in column 0 - becomes uppercased - gets a trailing space added * Note If I go at the end of (or just below) the text 3. Restart Emacs, and press C-RET, I get: --8---cut here---start-8--- 3. Restart Emacs. 4. --8---cut here---end---8--- in the Before command section, while I get: --8---cut here---start-8--- 1. Restart Emacs. 2. --8---cut here---end---8--- in the After command section. Hence, they do not share the same view on identifying the current list. Best regards, Seb -- Sebastien Vauban
Re: [O] Code blocks in lists?
Hello, wxhgmqzgw...@spammotel.com writes: * Before command 1. Download and install color-theme. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-6.6.0) (require 'color-theme) #+end_src 2. Download and install color-theme-leuven. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-leuven) (require 'color-theme-leuven) #+end_src 3. Restart Emacs. * Command to execute (let ((org-current-export-file (current-buffer))) (org-export-blocks-preprocess)) * After command 1. Download and install color-theme. #+BEGIN_SRC emacs-lisp (add-to-list 'load-path /path/to/color-theme-6.6.0) (require 'color-theme) #+END_SRC 2. Download and install color-theme-leuven. #+BEGIN_SRC emacs-lisp (add-to-list 'load-path /path/to/color-theme-leuven) (require 'color-theme-leuven) #+END_SRC 3. Restart Emacs. * Summary of the changes The code blocks meta data: - is indented in column 0 `org-export-blocks-preprocess' shouldn't do that. I assume you want to preserve indentation in your blocks, but block boundaries shouldn't be moved in any case. Eric Schulte may have an opinion about this. I CC him. There's nothing to do as far as lists are concerned, unfortunately. Regards, -- Nicolas Goaziou
[O] Unable to 'make oldorg'
I'm trying to build using the oldorg target. (I'm use el-get and the recipe relies on oldorg.) On my OS X machine this is failing because I don't have Tex (see output below). This was not a requirement before. I believe the problem is a recent change to targets.mk that made doc a prerequisite to compile. I'm not familiar enough with this build to understand the reason for this change or propose an alternative that would keep oldorg working as before. output: make -C doc info make[1]: Nothing to be done for `info'. make -C doc html make[1]: Nothing to be done for `html'. make -C doc pdf texi2pdf --batch --clean org.texi You don't have a working TeX binary (tex) installed anywhere in your PATH, and texi2dvi cannot proceed without one. If you want to use this script, you'll need to install TeX (if you don't have it) or change your PATH or TEX environment variable (if you do). See the --help output for more details. For information about obtaining TeX, please see http://www.tug.org. If you happen to be using Debian, you can get it with this command: apt-get install tetex-bin make[1]: *** [org.pdf] Error 1 make: *** [pdf] Error 2 Thanks, -- Greg
Re: [O] Unable to 'make oldorg'
Greg Lucas g...@glucas.net wrote: I'm trying to build using the oldorg target. (I'm use el-get and the recipe relies on oldorg.) On my OS X machine this is failing because I don't have Tex (see output below). This was not a requirement before. I believe the problem is a recent change to targets.mk that made doc a prerequisite to compile. I'm not familiar enough with this build to understand the reason for this change or propose an alternative that would keep oldorg working as before. Try editing local.mk and uncomment the line # ORG_MAKE_DOC = info # html pdf Nick output: make -C doc info make[1]: Nothing to be done for `info'. make -C doc html make[1]: Nothing to be done for `html'. make -C doc pdf texi2pdf --batch --clean org.texi You don't have a working TeX binary (tex) installed anywhere in your PATH, and texi2dvi cannot proceed without one. If you want to use this script, you'll need to install TeX (if you don't have it) or change your PATH or TEX environment variable (if you do). See the --help output for more details. For information about obtaining TeX, please see http://www.tug.org. If you happen to be using Debian, you can get it with this command: apt-get install tetex-bin make[1]: *** [org.pdf] Error 1 make: *** [pdf] Error 2
Re: [O] Unable to 'make oldorg'
Greg Lucas writes: I believe the problem is a recent change to targets.mk that made doc a prerequisite to compile. I'm not familiar enough with this build to understand the reason for this change or propose an alternative that would keep oldorg working as before. I've already sent a patch to Bastien earlier today to remove this dependency as this change wasn't doing what intended anyway. That said, you can tell what documentation to make by setting the variable ORG_MAKE_DOC, preferrably in local.mk. If local.mk isn't existing, the first run of make will create a template that has an example of this to just make the info documentation. 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
[O] Unicode characters export from babel code blocks ?
Hi, In some literate program, I'd like to generate a data file. I do
it with a shell here-document (is there a better way just to inline
some text to tangle in a file?). It works when tangling but not when
exporting to the pdf. Because there is a catch : I wanted to use
unicode \25A0 ■ and \25A1 □ instead of '#' and ' '. With
#+LATEX_HEADER: \usepackage{xltxtra}
#+LATEX_HEADER: \setmainfont{DejaVu Serif}
I can get the squares in the rgular text,
however, the exported code remains blank where the squares should be
☹.
Any help greatly appreciated !
Best Regards (and thx for the great ord-mode !)
Bernard
PS: excerpt from my babel code below
…
Using =\25A0= aka «black square» (■) and =\25A1= aka «white square» (□) to
represent the wall and empty spaces of the maze.
#+begin_src sh :file maze.txt :exports code :tangle yes
cat - END
□
□■■□□□■■□
□
□□□■□■□□□
□□□■□■□□□
□□□■■■□□□
□
□■■□□□■■□
□
END
#+end_src
…
the pdf does not containanything
[O] README.org on github
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi THis is a slightly off topic question, but it concerns org. I would like to use a README.org file on github, and also include code blocks in the README.org - is this possible? What do I have to do to achieve this? The help on https://github.com/github/markup sounds kryptic to me. Thanks, Rainer - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+2mLwACgkQoYgNqgF2egpyzgCfeZB62VI7bNZNp7Hf7HGVa3iw SlsAnj+2AbzFYDHRdZo3sfNlvd+YPQnf =Y+IX -END PGP SIGNATURE-
Re: [O] Code blocks in lists?
Hi Nicolas and Eric, Eric Schulte wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Nicolas Goaziou wrote: Sebastien Vauban writes: As demonstrated by the following ECM, it seems that I can't put code blocks inside lists. I guess this is the same root cause as the problem I tried to described at http://lists.gnu.org/archive/html/emacs-orgmode/2012-02/msg00247.html. Here, the fact that it is an enumerated list makes the problem stand out. I still cannot reproduce it. What happens if you eval: (let ((org-current-export-file (current-buffer))) (org-export-blocks-preprocess)) in your buffer? * Before command --8---cut here---start-8--- 1. Download and install color-theme. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-6.6.0) (require 'color-theme) #+end_src 2. Download and install color-theme-leuven. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-leuven) (require 'color-theme-leuven) #+end_src 3. Restart Emacs. --8---cut here---end---8--- Sorry I missed the bit about `org-src-preserve-indentation', indeed there was a bug in the block indentation during export. I've just pushed up a fix, please let me know if you continue to have problems. With your fix, the above gets correctly exported. Thanks a lot to Nicolas for finding out the problem, and to you for the fix. However, if I change my list to something like this: 1. Download and install color-theme. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-6.6.0) (require 'color-theme) #+end_src 1. Download and install color-theme-leuven. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-leuven) (require 'color-theme-leuven) #+end_src 1. Restart Emacs. #+begin_src emacs-lisp (restart) #+end_src The export (see HTML), while being semantically correct in the sense that code blocks do belong to the items, seems wrong wrt the indentation, something like this: 1. Download and install color-theme. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-6.6.0) (require 'color-theme) #+end_src 1. Download and install color-theme-leuven. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-leuven) (require 'color-theme-leuven) #+end_src 1. Restart Emacs. #+begin_src emacs-lisp (restart) #+end_src A bit like if the indentation was doubled each time. What do you think of that? Should I not use `org-src-preserve-indentation', maybe?[1] Best regards, Seb [1] BTW, GitHub seems to use that setting, as they show the same problem as I had initially, when exporting README.org to HTML. -- Sebastien Vauban
Re: [O] Code blocks in lists?
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Nicolas and Eric, Eric Schulte wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Nicolas Goaziou wrote: Sebastien Vauban writes: As demonstrated by the following ECM, it seems that I can't put code blocks inside lists. I guess this is the same root cause as the problem I tried to described at http://lists.gnu.org/archive/html/emacs-orgmode/2012-02/msg00247.html. Here, the fact that it is an enumerated list makes the problem stand out. I still cannot reproduce it. What happens if you eval: (let ((org-current-export-file (current-buffer))) (org-export-blocks-preprocess)) in your buffer? * Before command --8---cut here---start-8--- 1. Download and install color-theme. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-6.6.0) (require 'color-theme) #+end_src 2. Download and install color-theme-leuven. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-leuven) (require 'color-theme-leuven) #+end_src 3. Restart Emacs. --8---cut here---end---8--- Sorry I missed the bit about `org-src-preserve-indentation', indeed there was a bug in the block indentation during export. I've just pushed up a fix, please let me know if you continue to have problems. With your fix, the above gets correctly exported. Thanks a lot to Nicolas for finding out the problem, and to you for the fix. However, if I change my list to something like this: 1. Download and install color-theme. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-6.6.0) (require 'color-theme) #+end_src 1. Download and install color-theme-leuven. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-leuven) (require 'color-theme-leuven) #+end_src 1. Restart Emacs. #+begin_src emacs-lisp (restart) #+end_src The export (see HTML), while being semantically correct in the sense that code blocks do belong to the items, seems wrong wrt the indentation, something like this: 1. Download and install color-theme. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-6.6.0) (require 'color-theme) #+end_src 1. Download and install color-theme-leuven. #+begin_src emacs-lisp (add-to-list 'load-path /path/to/color-theme-leuven) (require 'color-theme-leuven) #+end_src 1. Restart Emacs. #+begin_src emacs-lisp (restart) #+end_src A bit like if the indentation was doubled each time. What do you think of that? Hi Seb, This indentation is an HTML/CSS issue, as far as I can tell Org-mode is generating the correct HTML. Should I not use `org-src-preserve-indentation', maybe?[1] The `org-src-preserve-indentation' variable only effects the indentation of code *inside* of code blocks, it shouldn't have any effect on this issue. Best regards, Seb [1] BTW, GitHub seems to use that setting, as they show the same problem as I had initially, when exporting README.org to HTML. Github uses a ruby library named org-ruby to export, it is an entirely separate export implementation. Best, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] M-x org-version RET now produces some sensible in all possible install/use-cases
Bastien b...@gnu.org writes: Hi all, an old haitian saying goes like this: Ak pasyans ou vle lombik fourmi. which translates: With patience, you see the ombilic of an ant. One of my favorite saying when I spent some time working in Port-au-Prince, where you get nothing with a lot of patience. Thanks to patient and hard work of Achim, M-x org-version RET should now return something sensible in each use-case. Please pull and report any oddities in this area. Best, Aloha Bastien, This seems odd to me, but sensible: Org-mode version N/A (N/A !!check installation!! @ /Users/dk/.emacs.d/src/org/lisp/) I used to get a version number. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] M-x org-version RET now produces some sensible in all possible install/use-cases
Thomas S. Dye writes: This seems odd to me, but sensible: Org-mode version N/A (N/A !!check installation!! @ /Users/dk/.emacs.d/src/org/lisp/) This means there is an org-install.el in that directory, but it doesn't seem to be one that matches to your org version and both org-version.el and UTILITIES/org-fixup.el seem to be missing. If you want to run org uncompiled, the load-path needs to pick up the Git work tree before anything else and it is recommended to do an 'make autoloads' so that you do not accidentally load a stale org-install.el (or a compiled org file) from the org version that comes with Emacs or that you may have formerly installed in some other place. Please report what you get from: M-x locate-library org M-x locate-library org-install M-x locate-library org-version and check that your load-path is what you expect it to be. 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: [O] M-x org-version RET now produces some sensible in all possible install/use-cases
Bastien writes: Thanks to patient and hard work of Achim, M-x org-version RET should now return something sensible in each use-case. There are basically two use-cases, not-installed and installed. Not-installed comes in three flavors, although the first one has some hard to avoid pitfalls and should be considered dangerous. If the autoload files are not or not fully generated, then determining the version is done at runtime like in former org versions and relies on the existence of $(lispdir)/../UTILITIES/org-fixup.el — if that can't be found either, a default N/A version string will be output (which should only be possible if somehow the lisp directory from org has been copied by hand someplace else). 1) Org uninstalled (and possibly uncompiled) from Git or tarball. 1a) No org-version.el or org-install.el exists in worktree. Partially supported configuration, org version is determined from git if possible via UTILITIES/org-fixup.el. However, Emacs versions delivered with orgmode will provide autoloads that may or may not work with that version of org (mixed installation). If such a situation is encountered, warn the user. It can work if the autoloads from the installation match the ones that would be generated for the worktree, which generally is only the case if there is a relatively recent installation in site-lisp. 1b) Autoload file org-install.el exists in worktree, but not org-version.el. Fully supported configuration, org version is determined from git if possible via UTILITIES/org-fixup.el. 1c) Both org-version.el or org-install.el exist in worktree. Recommended configuration for 1), org version is taken from org-version.el (git never gets invoked). 2) Org installed. Both org-version.el and org-install.el must exist in install directory. Only supported configuration for 2), org version is taken from org-version.el (git never gets invoked since UTILITIES/org-fixup.el is not available). Any unsupported configuration should still yield a version string, but it will contain N/A to alert the user about a botched org installation. If N/A or a wrong version number is shown from 'M-x org-version' or the path shown after the Git version is not what it should be or you see a mixed installation! there, then please check with 'M-x locate-library' where org, org-install and org-version are found (or that they are _not_ found at all, depending on which use case above you are targeting). If they are found, they must all be found in the same directory. If you have leftover files from an older installation, re-configure load-path so that Emacs doesn't find them, remove them altogether if they are expendable or do a 'make cleanall' if they are in the org directory. From there, pick your use-case and try to stick to it (or at least do another 'make cleanall' before you switch). 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
[O] Can't make org-install.el
Hello,
I don't know why, but with the most recent Org-mode version, I can't make
org-install.org:
--8---cut here---start-8---
make -C doc install
make[1]: Entering directory
`/cygdrive/c/home/sva/Downloads/emacs/site-lisp/org-mode/doc'
if [ ! -d /usr/share/info ]; then mkdir -p /usr/share/info; else true; fi ;
install -p org /usr/share/info
install-info --infodir=/usr/share/info org
make[1]: Leaving directory
`/cygdrive/c/home/sva/Downloads/emacs/site-lisp/org-mode/doc'
make -C etc install
make[1]: Entering directory
`/cygdrive/c/home/sva/Downloads/emacs/site-lisp/org-mode/etc'
for dir in styles schema ; do \
if [ ! -d /usr/share/emacs/etc/org/${dir} ] ; then \
mkdir -p /usr/share/emacs/etc/org/${dir} ; \
fi ; \
install -p ${dir}/* /usr/share/emacs/etc/org/${dir} ; \
done ;
make[1]: Leaving directory
`/cygdrive/c/home/sva/Downloads/emacs/site-lisp/org-mode/etc'
make -C lisp install
make[1]: Entering directory
`/cygdrive/c/home/sva/Downloads/emacs/site-lisp/org-mode/lisp'
rm -f org-version.el org-install.el org-version.elc org-install.elc
org-version: 7.8.10 (release_7.8.10-568-gc84cda)
Loading c:/home/sva/Downloads/emacs/site-lisp/org-mode/lisp/org-compat.el
(source)...
Loading c:/home/sva/Downloads/emacs/site-lisp/org-mode/UTILITIES/org-fixup.el
(source)...
Loading vc-svn...
Loading vc-git...
Saving file
c:/home/sva/Downloads/emacs/site-lisp/org-mode/lisp/org-version.el...
Wrote c:/home/sva/Downloads/emacs/site-lisp/org-mode/lisp/org-version.el
org-install: 7.8.10 (release_7.8.10-568-gc84cda)
Loading c:/home/sva/Downloads/emacs/site-lisp/org-mode/lisp/org-compat.el
(source)...
Loading c:/home/sva/Downloads/emacs/site-lisp/org-mode/UTILITIES/org-fixup.el
(source)...
Buffer is read-only: #buffer org-install.el
Makefile:30: recipe for target `org-install.el' failed
make[1]: *** [org-install.el] Error 127
make[1]: Leaving directory
`/cygdrive/c/home/sva/Downloads/emacs/site-lisp/org-mode/lisp'
targets.mk:84: recipe for target `install-lisp' failed
make: *** [install-lisp] Error 2
--8---cut here---end---8---
To overcome problems, I tried to copy org-install.el from the latest Emacs 24
alpha version, but the newly function `org-find-library-dir' is unknown.
Loading, by hand, `org-compat.el' does solve this latest problem, and allow me
to still be able to use Org.
However, the first problem (make install) is the one I still need to resolve.
Any idea?
Best regards,
Seb
[1] DEFINITION NOT FOUND: 1
--
Sebastien Vauban
Re: [O] Problem exporting to PDF (and viewing)
2) If not, where is the code that interprets %s? I can try stepping through it and see what I can find. It happens in org.el:org-open-file, specifically this piece of the code (I think): , | (while (string-match %s cmd) | (setq cmd (replace-match |(save-match-data | (shell-quote-argument | (convert-standard-filename file))) |t t cmd))) ` I did some tracing through, and have found where things go wrong. At the start of the code listed above, cmd = c:/progra~1/sumatrapdf/sumatrapdf.exe %s file = c:/dropbox/org/personal.pdf (convert-standard-filename file) returns C:/dropbox/org/personal.pdf So far so good... However, (shell-quote-argument (convert-standard-filename file)) returns c\\:dropbox/org/personal.pdf That's where the problem occurs. After this block of code is completed, cmd takes the value c:/progra~1/sumatrapdf/sumatrapdf.exe c\\:dropbox/org/personal.pdf This command causes sumatrapdf to squawk with an error. It's the \\: that causes the problem. If, after this block of code executes, I manually switch the \\: back to :/, so cmd goes back to c:/progra~1/sumatrapdf/sumatrapdf.exe c:/dropbox/org/personal.pdf and then press c to continue, the PDF file pops up just fine. Could we just drop the call to shell-quote-argument? It seems like everything would work fine without this call.
Re: [O] Problem exporting to PDF (and viewing)
Richard Stanton stan...@haas.berkeley.edu wrote: 2) If not, where is the code that interprets %s? I can try stepping through it and see what I can find. It happens in org.el:org-open-file, specifically this piece of the code (I think): , | (while (string-match %s cmd) | (setq cmd (replace-match | (save-match-data |(shell-quote-argument | (convert-standard-filename file))) | t t cmd))) ` I did some tracing through, and have found where things go wrong. At the start of the code listed above, cmd = c:/progra~1/sumatrapdf/sumatrapdf.exe %s file = c:/dropbox/org/personal.pdf (convert-standard-filename file) returns C:/dropbox/org/personal.pdf So far so good... However, (shell-quote-argument (convert-standard-filename file)) returns c\\:dropbox/org/personal.pdf Does it really drop the slash in front of dropbox? When I do that on my system, the : is quoted, but the slash is left alone: (setq s C:/dropbox/org/personal.pdf) C:/dropbox/org/personal.pdf (shell-quote-argument s) C\\:/dropbox/org/personal.pdf system-type gnu/linux If it does indeed drop the slash, can you try just putting it back and leaving the backslashes alone? Nick That's where the problem occurs. After this block of code is completed, cmd takes the value c:/progra~1/sumatrapdf/sumatrapdf.exe c\\:dropbox/org/personal.pdf This command causes sumatrapdf to squawk with an error. It's the \\: that causes the problem. If, after this block of code executes, I manually switch the \\: back to :/, so cmd goes back to c:/progra~1/sumatrapdf/sumatrapdf.exe c:/dropbox/org/personal.pdf and then press c to continue, the PDF file pops up just fine. Could we just drop the call to shell-quote-argument? It seems like everything would work fine without this call.
Re: [O] Problem exporting to PDF (and viewing)
-Original Message- From: nicholas.do...@hp.com [mailto:nicholas.do...@hp.com] Sent: Friday, May 18, 2012 2:11 PM To: Richard Stanton Cc: emacs-orgmode@gnu.org; Jonathan Leech-Pepin Subject: Re: [O] Problem exporting to PDF (and viewing) Richard Stanton stan...@haas.berkeley.edu wrote: 2) If not, where is the code that interprets %s? I can try stepping through it and see what I can find. It happens in org.el:org-open-file, specifically this piece of the code (I think): , | (while (string-match %s cmd) | (setq cmd (replace-match |(save-match-data | (shell-quote-argument | (convert-standard-filename file))) |t t cmd))) ` I did some tracing through, and have found where things go wrong. At the start of the code listed above, cmd = c:/progra~1/sumatrapdf/sumatrapdf.exe %s file = c:/dropbox/org/personal.pdf (convert-standard-filename file) returns C:/dropbox/org/personal.pdf So far so good... However, (shell-quote-argument (convert-standard-filename file)) returns c\\:dropbox/org/personal.pdf Does it really drop the slash in front of dropbox? When I do that on my system, the : is quoted, but the slash is left alone: (setq s C:/dropbox/org/personal.pdf) C:/dropbox/org/personal.pdf (shell-quote-argument s) C\\:/dropbox/org/personal.pdf system-type gnu/linux If it does indeed drop the slash, can you try just putting it back and leaving the backslashes alone? Oops. I must have deleted it somehow while transcribing. No, the slash is left alone: c\\:/Dropbox/org/personal.pdf
Re: [O] Problem exporting to PDF (and viewing)
Richard Stanton stan...@haas.berkeley.edu wrote: 2) If not, where is the code that interprets %s? I can try stepping through it and see what I can find. It happens in org.el:org-open-file, specifically this piece of the code (I think): , | (while (string-match %s cmd) | (setq cmd (replace-match | (save-match-data |(shell-quote-argument | (convert-standard-filename file))) | t t cmd))) ` I did some tracing through, and have found where things go wrong. At the start of the code listed above, cmd = c:/progra~1/sumatrapdf/sumatrapdf.exe %s file = c:/dropbox/org/personal.pdf (convert-standard-filename file) returns C:/dropbox/org/personal.pdf So far so good... However, (shell-quote-argument (convert-standard-filename file)) returns c\\:dropbox/org/personal.pdf That's where the problem occurs. After this block of code is completed, cmd takes the value c:/progra~1/sumatrapdf/sumatrapdf.exe c\\:dropbox/org/personal.pdf This command causes sumatrapdf to squawk with an error. It's the \\: that causes the problem. If, after this block of code executes, I manually switch the \\: back to :/, so cmd goes back to c:/progra~1/sumatrapdf/sumatrapdf.exe c:/dropbox/org/personal.pdf and then press c to continue, the PDF file pops up just fine. Could we just drop the call to shell-quote-argument? It seems like everything would work fine without this call. Can you trace the execution of shell-quote-argument? In particular, what is the value of system-type and what result do you get when you evaluate the form (w32-shell-dos-semantics) ? It seems that it falls through to the default case and I'm not sure it should. Nick
Re: [O] Problem exporting to PDF (and viewing)
From: nicholas.do...@hp.com [mailto:nicholas.do...@hp.com] Sent: Friday, May 18, 2012 3:20 PM To: Richard Stanton Cc: emacs-orgmode@gnu.org; Jonathan Leech-Pepin Subject: Re: [O] Problem exporting to PDF (and viewing) Richard Stanton stan...@haas.berkeley.edu wrote: 2) If not, where is the code that interprets %s? I can try stepping through it and see what I can find. It happens in org.el:org-open-file, specifically this piece of the code (I think): , | (while (string-match %s cmd) | (setq cmd (replace-match |(save-match-data | (shell-quote-argument | (convert-standard-filename file))) |t t cmd))) ` I did some tracing through, and have found where things go wrong. At the start of the code listed above, cmd = c:/progra~1/sumatrapdf/sumatrapdf.exe %s file = c:/dropbox/org/personal.pdf (convert-standard-filename file) returns C:/dropbox/org/personal.pdf So far so good... However, (shell-quote-argument (convert-standard-filename file)) returns c\\:dropbox/org/personal.pdf That's where the problem occurs. After this block of code is completed, cmd takes the value c:/progra~1/sumatrapdf/sumatrapdf.exe c\\:dropbox/org/personal.pdf This command causes sumatrapdf to squawk with an error. It's the \\: that causes the problem. If, after this block of code executes, I manually switch the \\: back to :/, so cmd goes back to c:/progra~1/sumatrapdf/sumatrapdf.exe c:/dropbox/org/personal.pdf and then press c to continue, the PDF file pops up just fine. Could we just drop the call to shell-quote-argument? It seems like everything would work fine without this call. Can you trace the execution of shell-quote-argument? In particular, what is the value of system-type and what result do you get when you evaluate the form (w32-shell-dos-semantics) ? It seems that it falls through to the default case and I'm not sure it should. Tracing through (shell-quote-argument c:/dropbox/org/personal.pdf), system-type is windows-nt (w32-shell-dos-semantics) returns nil This result occurs because I'm using (Cygwin) bash as my shell inside Emacs, not the Windows default, cmdproxy.exe. It's therefore true that my shell does *not* expect DOS file names (and gets very upset when you pass it a backslash...), but escaping the : seems to cause problems because now : is taken to be part of the file name, I think, rather than part of c:, the name of the (Windows) disk.
Re: [O] M-x org-version RET now produces some sensible in all possible install/use-cases
Aloha Achim, Achim Gratz strom...@nexgo.de writes: Thomas S. Dye writes: This seems odd to me, but sensible: Org-mode version N/A (N/A !!check installation!! @ /Users/dk/.emacs.d/src/org/lisp/) This means there is an org-install.el in that directory, but it doesn't seem to be one that matches to your org version and both org-version.el and UTILITIES/org-fixup.el seem to be missing. If you want to run org uncompiled, the load-path needs to pick up the Git work tree before anything else and it is recommended to do an 'make autoloads' so that you do not accidentally load a stale org-install.el (or a compiled org file) from the org version that comes with Emacs or that you may have formerly installed in some other place. Please report what you get from: M-x locate-library org M-x locate-library org-install M-x locate-library org-version and check that your load-path is what you expect it to be. Regards, Achim. Thanks for your response. M-x locate-library finds all three libraries in ~/.emacs.d/src/org/lisp/ This is the Git work tree. This path is at the beginning of load-path, before paths to the org version that comes with Emacs. I did 'make autoloads' and now org-version gives something familiar: Org-mode version 7.8.10 (release_7.8.10-568-gc84cda @ /Users/dk/.emacs.d/src/org/lisp/) Thanks again for your help. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
