Re: [O] bug in new exporter
Hello,
Nick Dokos ndo...@gmail.com writes:
Please find an org file and the corresponding tex file attached. The
directory structure is as follows:
~/src/org--images--foo.png
|
|--latex--example.{org,tex}
|
|--example.t2d/pdf/build
Just executing
texi2dvi -p -b -c -V example.tex
from the command line produces the error:
,
| /usr/bin/texi2dvi: cd /home/nick/src/org/latex/example.t2d/pdf/build
| ...
| LaTeX Warning: File `../images/foo.png' not found on input line 37.
|
|
| /home/nick/src/org/latex/./example.tex:37: Package pdftex.def Error: File
| `../images/foo.png' not found.n
|
| See the pdftex.def package documentation for explanation.
| Type H return for immediate help.
| ...
|
| l.37 ...ludegraphics[scale=1.5]{../images/foo.png}
| ...
`
Note the top line in the excerpt above. Taking out the -c gets rid of
the error (at the price of leaving all the toc/aux/log/etc files around
of course). --tidy exhibits the same symptom.
I removed -c argument from texi2dvi command. Thank you for the
detailed report.
Regards,
--
Nicolas Goaziou
Re: [O] bug in new exporter
Hello, Nick Dokos ndo...@gmail.com writes: Nicolas Goaziou n.goaz...@gmail.com writes: With #+ATTR_LATEX: :options scale=1.5:width :placement [htb!] it fails here (attr (org-export-read-attribute :attr_latex parent)) which evalues to something like Result: (:options scale=1.5 :placement [htb!] :width ) when it doesn't crash. This bug should be fixed in maint. Thanks to both of you for identifying it. And also in master, correct? I can never remember who goes first. Correct. Basically, if current version is a.b.c, a change in maint will appear in a.b.c+1 whereas a change in master will appear in a.b+1. Just a heads-up: As part of testing this, I stumbled on an unrelated current-working-directory problem, where on exporting to pdf, the pdflatex of the produced tex file fails to find an image file specified with a relative pathname (it works fine with an absolute path name). The tex file looks OK and I can process it from the command line. I'll try to pin this down more precisely, Problem probably comes from `org-latex-compile'. but do I understand correctly that the processing of the tex file should take place with the current working directory set to the directory of the org file? Yes. Regards, -- Nicolas Goaziou
Re: [O] bug in new exporter
Nick Dokos ndo...@gmail.com writes: Nick Dokos ndo...@gmail.com writes: Just a heads-up: As part of testing this, I stumbled on an unrelated current-working-directory problem, where on exporting to pdf, the pdflatex of the produced tex file fails to find an image file specified with a relative pathname (it works fine with an absolute path name). The tex file looks OK and I can process it from the command line. I'll try to pin this down more precisely, but do I understand correctly that the processing of the tex file should take place with the current working directory set to the directory of the org file? The problem was that I had customized my org-latex-pdf-process to the texi2dvi recommended value: texi2dvi -p -b -c -V %f The -c (equivalently: --clean or --build=clean) breaks relative paths because texi2dvi executes in a different directory. The *Org PDF LaTeX Output* buffer shows /usr/bin/texi2dvi: cd /home/nick/src/org/latex/foo.t2d/pdf/build whereas the org file was in /home/nick/src/org/latex. If you use texi2dvi, beware of -c (and also --tidy I presume). So nothing to do with org, but maybe the customization option should not include the -c. I also use texi2dvi, but I don't have any compilation problem with images, even with a relative path. Would you mind providing an ECM for that? Regards, -- Nicolas Goaziou
Re: [O] bug in new exporter
Nicolas Goaziou n.goaz...@gmail.com writes:
Nick Dokos ndo...@gmail.com writes:
Nick Dokos ndo...@gmail.com writes:
Just a heads-up: As part of testing this, I stumbled on an unrelated
current-working-directory problem, where on exporting to pdf, the
pdflatex of the produced tex file fails to find an image file specified
with a relative pathname (it works fine with an absolute path name). The
tex file looks OK and I can process it from the command line. I'll try
to pin this down more precisely, but do I understand correctly that the
processing of the tex file should take place with the current working
directory set to the directory of the org file?
The problem was that I had customized my org-latex-pdf-process to the
texi2dvi recommended value:
texi2dvi -p -b -c -V %f
The -c (equivalently: --clean or --build=clean) breaks relative paths
because texi2dvi executes in a different directory. The *Org PDF LaTeX
Output* buffer shows
/usr/bin/texi2dvi: cd /home/nick/src/org/latex/foo.t2d/pdf/build
whereas the org file was in /home/nick/src/org/latex.
If you use texi2dvi, beware of -c (and also --tidy I presume).
So nothing to do with org, but maybe the customization option should not
include the -c.
I also use texi2dvi, but I don't have any compilation problem with
images, even with a relative path.
Would you mind providing an ECM for that?
Please find an org file and the corresponding tex file attached. The
directory structure is as follows:
~/src/org--images--foo.png
|
|--latex--example.{org,tex}
|
|--example.t2d/pdf/build
Just executing
--8---cut here---start-8---
texi2dvi -p -b -c -V example.tex
--8---cut here---end---8---
from the command line produces the error:
,
| /usr/bin/texi2dvi: cd /home/nick/src/org/latex/example.t2d/pdf/build
| ...
| LaTeX Warning: File `../images/foo.png' not found on input line 37.
|
|
| /home/nick/src/org/latex/./example.tex:37: Package pdftex.def Error: File
| `../images/foo.png' not found.
|
| See the pdftex.def package documentation for explanation.
| Type H return for immediate help.
| ...
|
| l.37 ...ludegraphics[scale=1.5]{../images/foo.png}
| ...
`
Note the top line in the excerpt above. Taking out the -c gets rid of
the error (at the price of leaving all the toc/aux/log/etc files around
of course). --tidy exhibits the same symptom.
Org-mode version 8.0.3 (release_8.0.3-197-g221768 @
/home/nick/elisp/org-mode/lisp/)
#+OPTIONS: timestamp:nil
* foo
#+caption: foo
#+attr_latex: :placement [htb!] :options scale=1.5 :width
[[file:../images/foo.png]]
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{fixltx2e}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{float}
\usepackage{wrapfig}
\usepackage{soul}
\usepackage{textcomp}
\usepackage{marvosym}
\usepackage[nointegrals]{wasysym}
\usepackage{latexsym}
\usepackage{amssymb}
\usepackage{amstext}
\usepackage{hyperref}
\tolerance=1000
\usepackage{minted}
\author{Nick Dokos}
\date{\today}
\title{example}
\hypersetup{
pdfkeywords={},
pdfsubject={},
pdfcreator={Emacs 24.3.50.1 (Org mode 8.0.3)}}
\begin{document}
\maketitle
\tableofcontents
\section{foo}
\label{sec-1}
\begin{figure}[htb!]
\centering
\includegraphics[scale=1.5]{../images/foo.png}
\caption{foo}
\end{figure}
% Emacs 24.3.50.1 (Org mode 8.0.3)
\end{document}
--
Nick
Re: [O] bug in new exporter
Hello, Rasmus ras...@gmx.us writes: Nick Dokos ndo...@gmail.com writes: if I rearrange the line to #+ATTR_LATEX: :width :placement [htb!] :options scale=1.5 I get the Wrong argument type error in the current version as well. I can reproduce this here. I guess :width has to be after the :options ?!? I don't quite understand the rules I guess. Neither do I in this case. I'm guessing it has do with the escaping of 'cause it also fails if you :placement behind width. With #+ATTR_LATEX: :options scale=1.5:width :placement [htb!] it fails here (attr (org-export-read-attribute :attr_latex parent)) which evalues to something like Result: (:options scale=1.5 :placement [htb!] :width ) when it doesn't crash. This bug should be fixed in maint. Thanks to both of you for identifying it. Regards, -- Nicolas Goaziou
Re: [O] bug in new exporter
Nicolas Goaziou n.goaz...@gmail.com writes: With #+ATTR_LATEX: :options scale=1.5:width :placement [htb!] it fails here (attr (org-export-read-attribute :attr_latex parent)) which evalues to something like Result: (:options scale=1.5 :placement [htb!] :width ) when it doesn't crash. This bug should be fixed in maint. Thanks to both of you for identifying it. And also in master, correct? I can never remember who goes first. In any case, I updated from master and checked: it works with the :width option anywhere in the sequence of options, so it does seem to be fixed. In all cases, there is no width specification, just the scale, on the \includegraphics - and no error. Just a heads-up: As part of testing this, I stumbled on an unrelated current-working-directory problem, where on exporting to pdf, the pdflatex of the produced tex file fails to find an image file specified with a relative pathname (it works fine with an absolute path name). The tex file looks OK and I can process it from the command line. I'll try to pin this down more precisely, but do I understand correctly that the processing of the tex file should take place with the current working directory set to the directory of the org file? Thanks! -- Nick
Re: [O] bug in new exporter
Nick Dokos ndo...@gmail.com writes: Just a heads-up: As part of testing this, I stumbled on an unrelated current-working-directory problem, where on exporting to pdf, the pdflatex of the produced tex file fails to find an image file specified with a relative pathname (it works fine with an absolute path name). The tex file looks OK and I can process it from the command line. I'll try to pin this down more precisely, but do I understand correctly that the processing of the tex file should take place with the current working directory set to the directory of the org file? The problem was that I had customized my org-latex-pdf-process to the texi2dvi recommended value: texi2dvi -p -b -c -V %f The -c (equivalently: --clean or --build=clean) breaks relative paths because texi2dvi executes in a different directory. The *Org PDF LaTeX Output* buffer shows /usr/bin/texi2dvi: cd /home/nick/src/org/latex/foo.t2d/pdf/build whereas the org file was in /home/nick/src/org/latex. If you use texi2dvi, beware of -c (and also --tidy I presume). So nothing to do with org, but maybe the customization option should not include the -c. -- Nick
Re: [O] bug in new exporter
Hi Marvin, Marvin Doyley m.doy...@rochester.edu writes: Hi there, When I include the following in my org file #+attr_latex: scale=1.5, placement =[htb!] [[file:img/figure2.eps]] The syntax changes. Something like this might give you what you want. #+ATTR_LATEX: :placement [htb!] :options scale=1.5 #+CAPTION: a float needs a caption [[file:fig.pdf]] do check out: http://orgmode.org/org.html#LaTeX-specific-attributes From the source code, ox-latex.el, you should be able to get it to accept placement without square brackets. It should also be possible to set something like htb! as the default value of floats, if you so desire. Check the variable org-latex-default-figure-position. –Rasmus -- In theory, practice and theory are the same. In practice they are not
Re: [O] bug in new exporter
Hi Rasmus,
It is still not behaving properly
#+ATTR_LATEX: :options scale=2
[[file:fig.pdf]]
yields
\begin{figure}[htb]
\centering
\includegraphics[scale=2,width=.9\linewidth]{fig.pdf}
\end{figure}
which is still not quite right, including option, this still doesn't remove the
extra width =0.9\linewidth :(
cheers
M
Re: [O] bug in new exporter
Rasmus ras...@gmx.us writes:
Hi Marvin,
Marvin Doyley m.doy...@rochester.edu writes:
Hi there,
When I include the following in my org file
#+attr_latex: scale=1.5, placement =[htb!]
[[file:img/figure2.eps]]
The syntax changes. Something like this might give you what you want.
#+ATTR_LATEX: :placement [htb!] :options scale=1.5
#+CAPTION: a float needs a caption
[[file:fig.pdf]]
One thing that I couldn't figure out is how to get rid of the width
specification altogether. I can change the default
[...,width=0.9\textwidth] with something like
:width 10cm
but if I scale the image (presumably by trial and error until
it looks good to my eye), then I want to turn off the width
option altogether (afaict, latex treats [scale=1.5,width=10cm]
as [width=10cm] - scale is not considered at all, hence my desire
to turn off width.)
I tried
:width nil
and
:width
In these cases, I get the default. The code looks like this
--8---cut here---start-8---
(width (cond ((plist-get attr :width))
((plist-get attr :height) )
((eq float 'wrap) 0.48\\textwidth)
(t org-latex-image-default-width)))
--8---cut here---end---8---
and in these cases the plist-get returns nil, so the t clause
triggers.
I also tried
:width
which fails with a
Wrong type argument: stringp, nil
in this call (and I haven't chased it further):
--8---cut here---start-8---
(attr (org-export-read-attribute :attr_latex parent))
--8---cut here---end---8---
Is it possible to eliminate ``width'' from the options?
do check out:
http://orgmode.org/org.html#LaTeX-specific-attributes
From the source code, ox-latex.el, you should be able to get it to
accept placement without square brackets.
I don't understand: what do you mean? AFAICT, you *have* to say
:placement [htb!]
*including* the square brackets, because the first clause of the cond
triggers and that does not include the square brackets:
--8---cut here---start-8---
(cond (place (format %s place))
((eq float 'wrap) {l}{0.5\\textwidth})
((eq float 'figure)
(format [%s] org-latex-default-figure-position))
(t
--8---cut here---end---8---
It should also be possible
to set something like htb! as the default value of floats, if you so
desire. Check the variable org-latex-default-figure-position.
OTOH, here you don't want to include the square brackets because the
format *does* add them. That seems to be a slight inconsistency.
Org-mode version 8.0.3 (release_8.0.3-173-gd200d0 @
/home/nick/elisp/org-mode/lisp/)
--
Nick
Re: [O] bug in new exporter
When I include the following in my org file
#+attr_latex: scale=1.5, placement =[htb!]
[[file:img/figure2.eps]]
The syntax changes. Something like this might give you what you want.
#+ATTR_LATEX: :placement [htb!] :options scale=1.5
#+CAPTION: a float needs a caption
[[file:fig.pdf]]
One thing that I couldn't figure out is how to get rid of the width
specification altogether.
It's a feature. We had a lengthy discussion about it a while ago
(myself, Nicholas and Aaron, I believe)
You can turn it permanently off by issuing
(setq org-latex-image-default-width nil)
I tested the code in my own Emacs and not emacs -q. To get no width
I do
#+NAME: name
#+ATTR_LATEX: :placement [htb!] :options scale=1.5 :width
#+CAPTION: a float needs a caption
[[file:signature.pdf]]
becomes:
\begin{figure}[htb!]
\centering
\includegraphics[scale=1.5]{signature.pdf}
\caption{\label{name}a float needs a caption}
\end{figure}
Org-mode version 8.0.3 (release_8.0.3-183-gca9937 @
/usr/share/emacs/site-lisp/org/).
I also tried
:width
which fails with a
This should work, though, also given the earlier discussion. At least
it does for me using the version above and emacs -q.
From the source code, ox-latex.el, you should be able to get it to
accept placement without square brackets.
I don't understand: what do you mean? AFAICT, you *have* to say
:placement [htb!]
*including* the square brackets, because the first clause of the cond
triggers and that does not include the square brackets:
OTOH, here you don't want to include the square brackets because the
format *does* add them. That seems to be a slight inconsistency.
Right; thanks I missed that. Thanks! This is inconsistent. It also
seems wrapfig needs {} tho I've never used it.
Perhaps it could be made more consistent? At least the variable and
the local arguments should be similar. . .
–Rasmus
--
Need more coffee. . .
Re: [O] bug in new exporter
Rasmus ras...@gmx.us writes: One thing that I couldn't figure out is how to get rid of the width specification altogether. It's a feature. We had a lengthy discussion about it a while ago (myself, Nicholas and Aaron, I believe) Count me confused again: what's the feature? I'll go looking for the discussion I guess. You can turn it permanently off by issuing (setq org-latex-image-default-width nil) I tested the code in my own Emacs and not emacs -q. To get no width I do #+NAME: name #+ATTR_LATEX: :placement [htb!] :options scale=1.5 :width #+CAPTION: a float needs a caption [[file:signature.pdf]] OK, I just did an update, did emacs -q with a minimal .emacs and the ATTR_LATEX line above works. Presumably it would also work with my previous org-version, but I was trying things in a different order: if I rearrange the line to #+ATTR_LATEX: :width :placement [htb!] :options scale=1.5 I get the Wrong argument type error in the current version as well. So I guess :width has to be after the :options ?!? I don't quite understand the rules I guess. Org-mode version 8.0.3 (release_8.0.3-193-g334581 @ /home/nick/elisp/org-mode/lisp/) I also tried :width which fails with a This should work, though, also given the earlier discussion. At least it does for me using the version above and emacs -q. Very helpful: thanks for the elucidation! -- Nick
Re: [O] bug in new exporter
Nick Dokos ndo...@gmail.com writes: One thing that I couldn't figure out is how to get rid of the width specification altogether. It's a feature. We had a lengthy discussion about it a while ago (myself, Nicholas and Aaron, I believe) Count me confused again: what's the feature? I'll go looking for the discussion I guess. including .9\textwidth when you least expect it is a feature. See this thread http://comments.gmane.org/gmane.emacs.orgmode/69963 if I rearrange the line to #+ATTR_LATEX: :width :placement [htb!] :options scale=1.5 I get the Wrong argument type error in the current version as well. I can reproduce this here. I guess :width has to be after the :options ?!? I don't quite understand the rules I guess. Neither do I in this case. I'm guessing it has do with the escaping of 'cause it also fails if you :placement behind width. With #+ATTR_LATEX: :options scale=1.5:width :placement [htb!] it fails here (attr (org-export-read-attribute :attr_latex parent)) which evalues to something like Result: (:options scale=1.5 :placement [htb!] :width ) when it doesn't crash. Perhaps, I'll have time to look at it later, but probably Nicolas is the right guy for the job. Very helpful: thanks for the elucidation! Thanks you to you too! –Rasmus -- Enough with the bla bla!
Re: [O] Bug in new exporter with babel blocks
Hello, Aaron Ecay aarone...@gmail.com writes: 2013ko urtarrilak 23an, Nicolas Goaziou-ek idatzi zuen: You needn't. org-exp-blocks functionalities are supported by the new exporter out of the box. Can you say more about this? I looked for but did not find a replacement to the org-export-blocks variable (an alist associating block types with functions to export them). I found it very easy to hook into the new exporter, but perhaps I missed something? No, you didn't miss anything. I was thinking about `org-special-blocks.el'. The exporter doesn't implement org-exp-blocks functionalities. Though, IIRC, org-exp-blocks was mostly deprecated when Babel was introduced. That's why old ditaa and dot exp-blocks were moved to src block languages. For parsing, yes. But for export I want a way to say “I don’t care what Org thinks the export of this block is. Give me the raw contents, and I will tell you what the export should be.” This is how the ditaa special-block code used to work; I see that it has now morphed into a babel language, which makes some kind of sense. I’m not sure it does in general. My use case is glossed examples for linguistics: my special block contains three lines, which are a sentence in a foreign language and a translation. By inserting markup in a way which is easy to automate, you can get LaTeX to align the words of one language with the words of the other. I don’t want any org processing of the text of the examples: it might contain backslashes, stars, etc., all of which should be passed verbatim to LaTeX. This does not feel like source code, it cannot be evaluated or tangled, I would not want these blocks to be included in org-babel-next-src-block, etc. It is data. Source code is for the processing function. Anyway, just store your text in example blocks, and create a src block in any language to do the processing. Then you can call the processing function on all of your example blocks. I suggest to keep the example blocks in a non-exportable section. You can also remove all named example blocks before export, via a hook. Your call. #+begin_src org * Data :noexport: #+name: words #+BEGIN_EXAMPLE a b c #+END_EXAMPLE #+name: #+BEGIN_SRC emacs-lisp :var x=words (upcase x) #+END_SRC * Contents #+call: words(:var x=words) #+end_src Regards, -- Nicolas Goaziou
Re: [O] Bug in new exporter with babel blocks
Nicolas, Thank you for your explanations, which were very helpful. 2013ko urtarrilak 23an, Nicolas Goaziou-ek idatzi zuen: You needn't. org-exp-blocks functionalities are supported by the new exporter out of the box. Can you say more about this? I looked for but did not find a replacement to the org-export-blocks variable (an alist associating block types with functions to export them). I found it very easy to hook into the new exporter, but perhaps I missed something? Special blocks are de facto, recursive, much like drawers. Their contents have to be parsed. For parsing, yes. But for export I want a way to say “I don’t care what Org thinks the export of this block is. Give me the raw contents, and I will tell you what the export should be.” This is how the ditaa special-block code used to work; I see that it has now morphed into a babel language, which makes some kind of sense. I’m not sure it does in general. My use case is glossed examples for linguistics: my special block contains three lines, which are a sentence in a foreign language and a translation. By inserting markup in a way which is easy to automate, you can get LaTeX to align the words of one language with the words of the other. I don’t want any org processing of the text of the examples: it might contain backslashes, stars, etc., all of which should be passed verbatim to LaTeX. This does not feel like source code, it cannot be evaluated or tangled, I would not want these blocks to be included in org-babel-next-src-block, etc. I’d also be happy to discover another, better way of getting the raw text content of the special-block that doesn’t succumb to this problem. If you must, you can try: (org-element-interpret-data (org-element-contents special-block)) from `org-e-latex-special-block'. I would up patching org-elements to add a :contents property to special-block elements, which is populated when parsing the original buffer (and thus dodges the different-buffer-for-export problem). I can then retrieve this in my export backend function. It is a very simple patch: ---cut-here--- diff --git i/lisp/org-element.el w/lisp/org-element.el index 3dc1e72..b67e5e6 100644 --- i/lisp/org-element.el +++ w/lisp/org-element.el @@ -1389,6 +1389,9 @@ Assume point is at the beginning of the block. :hiddenp hidden :contents-begin contents-begin :contents-end contents-end +:contents (and contents-begin contents-end + (buffer-substring-no-properties +contents-begin contents-end)) :post-blank (count-lines pos-before-blank end) :post-affiliated post-affiliated) (cdr affiliated) ---cut-here--- Is including support for special blocks that should be exported “raw” a compelling reason to install such a patch? I think the only downside would be increased memory usage/decreased speed for parsed objects (since they are now storing an extra string), but I think that would be very small (though I haven’t benchmarked anything). Thanks, -- Aaron Ecay
Re: [O] Bug in new exporter with babel blocks
Hello, Aaron Ecay aarone...@gmail.com writes: I’m dealing with a puzzling bug in the new exporter. As background, I’ve written a custom function to process special-blocks, to replicate in the new exporter the functionality of the org-exp-blocks package (http://orgmode.org/worg/org-contrib/org-exp-blocks.html). You needn't. org-exp-blocks functionalities are supported by the new exporter out of the box. Because I need the un-processed text inside the special-block (not parsed into an org-elements structure nor escaped for LaTeX special characters), Special blocks are de facto, recursive, much like drawers. Their contents have to be parsed. I’m not sure if this is a long-standing problem or not; this is the first time I’ve combined babel with my custom special-blocks code. I’m also at a loss of how to debug the internals of org-elements and org-export, two complex bits of machinery. I guess the value of the :contents-begin and -end properties needs to be fixed in any case. During export, the buffer being parsed isn't the original buffer, because of babel block, include keywords and macros expansion. You may want to have a look at `org-export-as' source code. Hence, :contents-begin and :contents-end properties do not refer to real buffer positions in the buffer from which `org-e-latex-special-block' is called. I’d also be happy to discover another, better way of getting the raw text content of the special-block that doesn’t succumb to this problem. If you must, you can try: (org-element-interpret-data (org-element-contents special-block)) from `org-e-latex-special-block'. Regards, -- Nicolas Goaziou
Re: [O] Bug (?) in new exporter (export subtree)
Rick Frankel r...@rickster.com writes: So, it seems that as long as there is a body (or blank) line after the parent heading and you position the cursor on that line, it works (point at X): #+begin_src org * Title X ** heading 1 text ** heading 2 ... #+end_src But if there is no blank line after the title, there is no way to get the expected results with the point either on the title line or the first asterix on heading 1: #+begin_src org * Title ** heading 1 text ** heading 2 ... #+end_src Indeed, you have to be within the subtree you want to export in order to effectively export it. In your example there's no such place, so there's no way to tell which subtree you want to be exported. This is a reasonable behaviour in my opinion. Regards, -- Nicolas Goaziou
Re: [O] Bug (?) in new exporter (export subtree)
On Wed, Jan 16, 2013 at 07:36:10PM +0100, Nicolas Goaziou wrote: Rick Frankel r...@rickster.com writes: In the new exporter, when the option to export only the subtree is specified, the first heading in the subtree is used as the title of the document. This seems wrong, as it becomes the title, the first element in the table of contents and the first (not necessarily the top level) section in the document. It doesn't, AFAIU. Could you explain how you do export (in particular, where is the point when you call the export subtree process) and what do you expect on a simple example ? For me: #+begin_src org #+TITLE: title #+OPTIONS: toc:t * Level 1 Body 1 X ** Level 2 Body 2 *** Level 3 Body 3 #+end_src with point at X will have Level 1 as its title, but Level 1 will appear neither in the table of contents nor as the first section of the produced document. So, it seems that as long as there is a body (or blank) line after the parent heading and you position the cursor on that line, it works (point at X): #+begin_src org * Title X ** heading 1 text ** heading 2 ... #+end_src But if there is no blank line after the title, there is no way to get the expected results with the point either on the title line or the first asterix on heading 1: #+begin_src org * Title ** heading 1 text ** heading 2 ... #+end_src rick
Re: [O] Bug (?) in new exporter (export subtree)
Hello, Rick Frankel r...@rickster.com writes: In the new exporter, when the option to export only the subtree is specified, the first heading in the subtree is used as the title of the document. This seems wrong, as it becomes the title, the first element in the table of contents and the first (not necessarily the top level) section in the document. It doesn't, AFAIU. Could you explain how you do export (in particular, where is the point when you call the export subtree process) and what do you expect on a simple example ? For me: #+begin_src org #+TITLE: title #+OPTIONS: toc:t * Level 1 Body 1 X ** Level 2 Body 2 *** Level 3 Body 3 #+end_src with point at X will have Level 1 as its title, but Level 1 will appear neither in the table of contents nor as the first section of the produced document. Regards, -- Nicolas Goaziou
Re: [O] Bug in new exporter: source block messes up list hierarchy
Please ignore this, the problem does not occur using the latest git source. -- Best, Hsiu-Khuern.
Re: [O] Bug in new exporter?
Thorsten Jolitz writes: when I try to use the new exporter outside of an Org buffer, e.g. from a function or with M-:, it seems that there is a problem with the current buffer that is used for exporting - it is not the buffer of the Org file given as argument. You should read the docstring again: the file name you give to that function is the name of the file that will be exported _into_ from the current buffer. So the current buffer should contain the org document to be exported. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Bug in new exporter?
Achim Gratz strom...@nexgo.de writes: Thorsten Jolitz writes: when I try to use the new exporter outside of an Org buffer, e.g. from a function or with M-:, it seems that there is a problem with the current buffer that is used for exporting - it is not the buffer of the Org file given as argument. You should read the docstring again: the file name you give to that function is the name of the file that will be exported _into_ from the current buffer. So the current buffer should contain the org document to be exported. Right, that got me confused. Sorry for the noise, and thanks for the tip. -- cheers, Thorsten
