Hi Nicolas,
· Nicolas Goaziou wrote:
> Hello,
>
> Thomas Holst writes:
>
>> While testing the new exporter we encountered problems with entities. We
>> tried to make ligations work. In LaTeX you write '\/' for a ligation
>> e.g. 'f\/ifteen'. To achieve that we set `org-entities-user':
>>
>> #+BE
Hello,
Thomas Holst writes:
> While testing the new exporter we encountered problems with entities. We
> tried to make ligations work. In LaTeX you write '\/' for a ligation
> e.g. 'f\/ifteen'. To achieve that we set `org-entities-user':
>
> #+BEGIN_SRC emacs-lisp
> (setq org-entities-user
>
Hello,
Rick Frankel writes:
> BUT, if the source block is not named then a duplicate results will be
> created above the current results block w/ the attribute header when
> the source block is re-evaluated.
That's correct.
For convenience, Babel might copy src-block attributes to the generate
On Tue, Aug 21, 2012 at 01:34:16AM -0400, Nick Dokos wrote:
> Rick Frankel wrote:
>
> > On Tue, Aug 21, 2012 at 12:54:25AM +0200, Nicolas Goaziou wrote:
> > > Hello,
> > >
> > > Use something like the following.
> > >
> > > * Test width attribute
> > > #+NAME: graph
> > > #+begin_src dot :file
Nick Dokos writes:
> FWIW, I cannot reproduce this.
Me neither, dunno what I did. Sorry for the noise,
--
Bastien
Bastien wrote:
> Hi Nicolas,
>
> Nicolas Goaziou writes:
>
> > Use something like the following.
>
> There is still a bug here.
>
> I've encountered it many times.
>
> > * Test width attribute
> > #+NAME: graph
> > #+begin_src dot :file t.png
> > digraph g { a -> b }
> > #+end_src
> >
>
Hello,
Bastien writes:
> There is still a bug here.
>
> I've encountered it many times.
>
>> * Test width attribute
>> #+NAME: graph
>> #+begin_src dot :file t.png
>> digraph g { a -> b }
>> #+end_src
>>
>> #+ATTR_LATEX: width=3in
>> #+RESULTS: graph
>> [[file:t.png]]
>
> When reevaluating th
Rick Frankel writes:
> That doesn't make sense. In the current exporter, all attributes
> (html, latex, etc) applied to the export are placed directly before
> the source block.
This should change. Attributes are attributes to something (big up
Husserl), so attributes to images should be placed
Hi Nicolas,
Nicolas Goaziou writes:
> Use something like the following.
There is still a bug here.
I've encountered it many times.
> * Test width attribute
> #+NAME: graph
> #+begin_src dot :file t.png
> digraph g { a -> b }
> #+end_src
>
> #+ATTR_LATEX: width=3in
> #+RESULTS: graph
> [[fi
Rick Frankel wrote:
> On Tue, Aug 21, 2012 at 12:54:25AM +0200, Nicolas Goaziou wrote:
> > Hello,
> >
> > Rick Frankel writes:
> >
> > > Has the syntax for latex attributes changed in the new exporter, or is
> > > is the following a bug?
> >
> > Neither. Though, at some point, I'd like to cha
On Tue, Aug 21, 2012 at 12:54:25AM +0200, Nicolas Goaziou wrote:
> Hello,
>
> Rick Frankel writes:
>
> > Has the syntax for latex attributes changed in the new exporter, or is
> > is the following a bug?
>
> Neither. Though, at some point, I'd like to change syntax for LaTeX
> attributes for a
Hello,
Rick Frankel writes:
> Has the syntax for latex attributes changed in the new exporter, or is
> is the following a bug?
Neither. Though, at some point, I'd like to change syntax for LaTeX
attributes for a plist-based one.
> Given this source file:
>
> * Test width attribute
> #+ATTR_LAT
Nicolas Goaziou writes:
> Hello,
>
> Andreas Leha writes:
>
>> I started to get the error
>> : org-open-file: Symbol's function definition is void:
>> org-e-latex-export-to-pdf
>>
>> when trying to export to pdf in the new exporter. Any thought what
>> might be causing this?
>
> Do you (requir
Hello,
Andreas Leha writes:
> I started to get the error
> : org-open-file: Symbol's function definition is void:
> org-e-latex-export-to-pdf
>
> when trying to export to pdf in the new exporter. Any thought what
> might be causing this?
Do you (require 'org-e-latex) first?
Regards,
--
Ni
Hi Niclolas,
thanks for your answer and explaination.
· Nicolas Goaziou wrote:
> Hello,
>
> "Holst Thomas (DGS-EC/ESE4)" writes:
>
>> Perhaps there is a misunderstanding.
>
> There was. Now I get it.
>
>> So it isn't about blocks. It is about LaTeX-fragments in org files.
>
> Actually, it isn
[re-sent due to no-show on the list... sorry if you get it twice]
Nicolas Goaziou writes:
> Nevermind: I fixed them. I think all tests should pass now, in both
> emacs 24 and emacs 23.
Yes!
> If you confirm this, I will move org-element.el into core.
Go ahead... and let us all celebrate that mo
Nicolas Goaziou writes:
>> compile::
>> $(CP) contrib/lisp/org-{export,element,e-*}.el lisp/
>
> Noted. Thank you.
That should be "all compile::", really.
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Wavetables for the Terratec KOMPLEXER:
http://Synth.Str
Hello,
Jonathan Leech-Pepin writes:
> Given the org file
>
> #+begin_src org
> ,* List Test
> ,** Plain List
> ,- A
> ,- [[http://www.google.com][google]]
> ,- [[http://www.google.com]]
> ,** Ordered List
> ,1. A
> ,2. [[http://www.google.com][google]]
> ,3. [[http://www.google
Hello,
"Holst Thomas (DGS-EC/ESE4)" writes:
> Perhaps there is a misunderstanding.
There was. Now I get it.
> So it isn't about blocks. It is about LaTeX-fragments in org files.
Actually, it isn't about LaTeX-fragments but entities. Your first line
contains a LaTeX-fragment: it appears (cor
Hello Nicolas,
thanks for your answer.
Perhaps there is a misunderstanding. In my original post
#+BEGIN_SRC org / #+END_SRC means context of an org file *not* inside a block.
#+BEGIN_SRC LaTeX / #+END_SRC is the content of the tex-file generated by the
exporters.
So it isn't about blocks. It
Hello,
Thomas Holst writes:
> So here is the next one:
> #+BEGIN_SRC org
> 160\(^\circ\}\nbsp{}C
> -11^{\circ}\nbsp{}C
> #+END_SRC
>
> With the old exporter this becomes:
> #+BEGIN_SRC latex
> 160\(^\circ\)~C
> -11$^{\circ}$~C
> #+END_SRC
> in LaTeX. Which looks well in pdf.
>
> With the
Da: Thomas Holst
Inviato: Mercoledì 18 Luglio 2012 12:13
> So here is the next one:
> #+BEGIN_SRC org
160\(^\circ\}\nbsp{}C
-11^{\circ}\nbsp{}C
> # +END_SRC
> With the new exporter it becomes:
> #+BEGIN_SRC latex
160\(^\circ\)~C
-11$^{\mathrm{\^{}}}$~C
> #+END_SRC
> in LaTeX. Where the
Hi Nicolas,
· Nicolas Goaziou wrote:
> Hello,
>
> Thomas Holst writes:
>
>> Labels and captions are not exported to LaTeX.
>>
>> ECM:
>> #+BEGIN_SRC org
>> * Captions for Tables
>> #+CAPTION: A Caption for Testing
>> #+LABEL: tbl:Label
>> #+ATTR_LaTeX: placement=[H]
>>
>> | one
Nicolas Goaziou writes:
> Achim Gratz writes:
>
>> I used whatever I had pulled yesterday... again, that failure happens
>> only with Emacs 23, which may well be a bug in that version or the
>> particular build. It actually got worse in that I can't seem to find an
>> eval limit that works toda
Hello,
Thomas Holst writes:
> Labels and captions are not exported to LaTeX.
>
> ECM:
> #+BEGIN_SRC org
> * Captions for Tables
> #+CAPTION: A Caption for Testing
> #+LABEL: tbl:Label
> #+ATTR_LaTeX: placement=[H]
>
> | one | two | three |
> |-+-+---|
> |
Hello,
Achim Gratz writes:
> I used whatever I had pulled yesterday... again, that failure happens
> only with Emacs 23, which may well be a bug in that version or the
> particular build. It actually got worse in that I can't seem to find an
> eval limit that works today, so the corruption that
Nicolas Goaziou writes:
>> 2 unexpected results:
>>FAILED test-org-element/parent-property
>>FAILED test-org-element/set-element
>
> I cannot get those. Have you tried with a recent Org (i.e. post
> 95cd07d058da79cb1767946dba6e4b9128a3a702)?
I used whatever I had pulled yesterday... agai
Nicolas Goaziou writes:
> Hello,
>
> Myles English writes:
>
>> A date entered with with C-c . exports without angle brackets in the old
>> exporter but with angle brackets in the new exporter. I would have
>> thought that without is preferable.
>
> Agreed. Brackets are only Org syntax.
>
> I
Hello,
Myles English writes:
> A date entered with with C-c . exports without angle brackets in the old
> exporter but with angle brackets in the new exporter. I would have
> thought that without is preferable.
Agreed. Brackets are only Org syntax.
I have pushed a change about timestamp objec
Hello,
Thomas Holst writes:
> right now I am testing the new exporter. It works very well except on
> backslashes. Here is a minimal example which shows the problem:
Indeed. It chokes on line break. It should be fixed now.
Thank you for testing the new exporter and reporting this bug.
Regard
Hello,
Achim Gratz writes:
> Actually, it wasn't. These two lines would be the only additions you
> need AFAICS and you could even make them on the command line:
>
> BTEST_EXTRA = org-export BTEST_OB_LANGUAGES =
Good to know, thank you.
> I still don't get that error and all tests are pass, w
Nicolas Goaziou writes:
> I hard-link org-element.el and org-export.el in lisp/ and I use the
Ditto, to be exact:
rm -f lisp/org-{export,element,e-*}.{el,elc}
ln contrib/lisp/org-{export,element,e-*}.el lisp/
> following local change to default.mk (I know I should be modifying
> local.mk instead
Hello,
Achim Gratz writes:
> Nicolas Goaziou writes:
>> Unfortunately, there's now an
>>
>> "(invalid function org-export-with-current-buffer-copy)"
>>
>> error when using make test
>
> Not for me... how do you have the build and the test configured?
I hard-link org-element.el and org-expor
Nicolas Goaziou writes:
> Unfortunately, there's now an
>
> "(invalid function org-export-with-current-buffer-copy)"
>
> error when using make test
Not for me... how do you have the build and the test configured?
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Bl
Nicolas Goaziou writes:
> Unfortunately, there's now an
>
> "(invalid function org-export-with-current-buffer-copy)"
>
> error when using make test
Mhh.. just tried now and I don't have this error.
A leftover from the previously loaded definition maybe?
--
Bastien
Hello,
Achim Gratz writes:
> I just see that you fixed this. Congratulations and thank you!
Unfortunately, there's now an
"(invalid function org-export-with-current-buffer-copy)"
error when using make test
Regards,
--
Nicolas Goaziou
Nicolas Goaziou writes:
> This is related to modifications by side-effect of list elements, but
> I don't know why it only happens when the file is byte-compiled and why
> it only focus table cells.
I just see that you fixed this. Congratulations and thank you!
Regards,
Achim.
--
+<[Q+ Matrix-
Jambunathan K writes:
> Nicolas Goaziou writes:
>
>> Hello,
>>
>> Achim Gratz writes:
>>
>>> Yes, that has been my impression as well. Again, I can make them go
>>> away by removing one of the byte-compiled files, so I rather suspect
>>> another case of a macro expansion that's not quite what
Nicolas Goaziou writes:
> Hello,
>
> Achim Gratz writes:
>
>> Yes, that has been my impression as well. Again, I can make them go
>> away by removing one of the byte-compiled files, so I rather suspect
>> another case of a macro expansion that's not quite what was intented.
>> Only this time I
Nicolas Goaziou writes:
> It looks like table-cells have a wrong `:parent' property when
> org-element.el is byte-compiled. In `org-element-table-cell-parser',
> replacing backquote with `list' solves the problem.
>
> This is related to modifications by side-effect of list elements, but
> I don't
Hello,
Achim Gratz writes:
> Yes, that has been my impression as well. Again, I can make them go
> away by removing one of the byte-compiled files, so I rather suspect
> another case of a macro expansion that's not quite what was intented.
> Only this time I really don't see from the backtrace
Nicolas Goaziou writes:
> In fact, I do get the errors from a "make test" but I don't know how to
> reproduce them from emacs.
For starters you could try to run Emacs like "make test" does, but
remove "-batch". This error somehow seems to involve that the test
always returns "'left 'left 'right"
Hello,
Achim Gratz writes:
> Current testing results with the exporter files uncompiled:
>
> 2 unexpected results:
>FAILED test-org-export/read-attribute
>FAILED test-org-export/unravel-code
>
> ...and compiled:
>
> 6 unexpected results:
>FAILED test-org-export/read-attribute
>
Current testing results with the exporter files uncompiled:
2 unexpected results:
FAILED test-org-export/read-attribute
FAILED test-org-export/unravel-code
...and compiled:
6 unexpected results:
FAILED test-org-export/read-attribute
FAILED test-org-export/table-cell-alignment
Nicolas Goaziou writes:
> Hello,
>
> cbe...@tajo.ucsd.edu writes:
>
>> BTW, "#+name: aname" and "#+NAME: aname" are handled differently in e-latex.
>> The
>> former gets placed in the latex output as "\#+name: aname". Bug?
>
> There is a known bug about affiliated keywords not being removed duri
Hello,
cbe...@tajo.ucsd.edu writes:
> BTW, "#+name: aname" and "#+NAME: aname" are handled differently in e-latex.
> The
> former gets placed in the latex output as "\#+name: aname". Bug?
There is a known bug about affiliated keywords not being removed during
export, but I don't know if you're
Nicolas Goaziou writes:
> Hello,
>
> Charles Berry writes:
>
>> I am trying to put together a derived backend that makes use of Src Block
>> :parameters attribute.
>>
[deleted]
>>
>> AFAICS :parameters is nowhere to be found when using
>> org-export-to-buffer.
>
> This is because src blocks are
Hello,
Charles Berry writes:
> I am trying to put together a derived backend that makes use of Src Block
> :parameters attribute.
>
> I can see that the header in a begin_src block is picked up by
>
> org-element-src-block-parser, as it should be when I try it interactively
>
> But not when I
Nicolas Goaziou writes:
> Not exactly. With this version, symbols generated with gensym are never
> used, and the macro isn't hygienic anymore.
Yeah, I missed out on some commas along the way and it probably needs
double quoting (which I was trying to avoid). The first version interns
the gensyme
Hello,
Achim Gratz writes:
> After some consideration, I think this is what the macro should look
> like:
>
> (defmacro org-export-with-current-buffer-copy (&rest body)
> "Apply BODY in a copy of the current buffer.
>
> The copy preserves local variables and visibility of the original
> buffer
Nicolas Goaziou writes:
> I will look more carefully at the `org-export-with-current-buffer-copy'
> macro, but, since I cannot reproduce the compilation error it may be
> hard to find the mistake.
After some consideration, I think this is what the macro should look
like:
--8<---cut he
Nicolas Goaziou writes:
> Ok, I misunderstood your answer: I thought you had solved the problem.
I thought that too at first, but it didn't survive closer scrutiny...
>> I'm not sure what you intended the macroexpansion to be at the place
>> of use, hence my suggestion to check these macros again
Hello,
Achim Gratz writes:
> The patch fixes things in that it will now consistently compile, but
> it doesn't work correctly anymore, compiled or otherwise.
Ok, I misunderstood your answer: I thought you had solved the problem.
> I'm not sure what you intended the macroexpansion to be at the
Nicolas Goaziou writes:
> I think you can go ahead and commit it: your description of the problem
> will be more accurate than mine.
>
> Thank you for this investigation and, obviously, for the fix.
You give me too much credit here... the patch fixes things in that it
will now consistently compile
Hello,
Achim Gratz writes:
> This code snippet has at last after revealed where the problem is: the
> function call to (current-buffer) gets unquoted, when it clearly needs
> to be in the expansion. The literal expansion of the buffer content
> into the compiled bytecode is similarly explained
Achim Gratz writes:
> Nicolas Goaziou writes:
>> That may not solve the problem, but could at least simplify it.
>
> The problem can be demonstrated with just this code snippet in place of
> org-export.el:
[...]
> So it might be a bit easier to solve now (I hope).
This code snippet has at last aft
Nicolas Goaziou writes:
> That may not solve the problem, but could at least simplify it.
The problem can be demonstrated with just this code snippet in place of
org-export.el:
--8<---cut here---start->8---
(eval-when-compile (require 'cl))
(require 'org-macs)
Nicolas Goaziou writes:
> Speaking about that, as you suggested already, we should move,
> temporarily, the dispatcher into another file (i.e. org-e-extra.el)
> which would require everything (org-element, org-export, org-e-publish,
> org-e-latex,...) and have _every_ back-end require org-export an
Hello,
Achim Gratz writes:
> Achim Gratz writes:
>> This causes the (current-buffer) to expand literally into the byte-code
>> (look at the byte-code!) instead of being compiled as a function, which
>> obviously isn't going to work. This does not happen if I either remove
>> the cond form or if
Achim Gratz writes:
> This causes the (current-buffer) to expand literally into the byte-code
> (look at the byte-code!) instead of being compiled as a function, which
> obviously isn't going to work. This does not happen if I either remove
> the cond form or if I wrap the BODY in save-restriction
Achim Gratz writes:
> As long as I don't compile org-export.el, all tests are now passing.
> Thank you.
I've had a look at the byte-compiled code and traced at least one of
those errors to the following construct in org-export.el(org-export-as):
#BEGIN_SRC emacs_lisp
…
(save-excursion
(save
Hi Nicolas,
> Hello,
>
> Andreas Leha writes:
>
>> is the new exporter lacking the possibility to set the title of the
>> exported document, when the title is set in the properties?
>>
>> Example:
>> ,
>> | #+title: test
>> |
>> | * testexport
>> | :PROPERTIES:
>> | :EXPORT_TITLE: Pumuck
Hello,
Andreas Leha writes:
> is the new exporter lacking the possibility to set the title of the
> exported document, when the title is set in the properties?
>
> Example:
> ,
> | #+title: test
> |
> | * testexport
> | :PROPERTIES:
> | :EXPORT_TITLE: Pumuckl
> | :END:
> | Some text.
Hello,
Thorsten Jolitz writes:
> when trying to enhance the HTML back-end of the new exporter with
> interactive HTML elements, one possibility (probably the easiest and
> best) is to write variants for the export functions for some Org
> elements that insert different HTML in the output string
Nicolas Goaziou writes:
> Achim Gratz writes:
>
>> It apparently croaks on the runtime use of cl macros and/or functions,
>> but just exactly how is a mystery to me.
>
> org-element uses `every' twice. Since this function doesn't belong to cl
> but cl-extra, could it be the source of the problem?
Achim Gratz writes:
> It apparently croaks on the runtime use of cl macros and/or functions,
> but just exactly how is a mystery to me.
org-element uses `every' twice. Since this function doesn't belong to cl
but cl-extra, could it be the source of the problem?
If so, it may be worth a try to r
Nicolas Goaziou writes:
> What happens if you revert commit:
>
> 4b0121fc2a18e00ce2c80e145563e41accfc4ddb
I've played with that before. As I already said, the requires and maybe
even the circular dependencies are not the problem. It apparently
croaks on the runtime use of cl macros and/or func
Hello,
Achim Gratz writes:
> If I pre-load either org-element or org-export (or both) and they have
> been byte-compiled things get worse to the point where Emacs simply
> craps out. I don't know why this is happening, but it's very obvious
> that these files can't be used byte-compiled. Whate
Nicolas Goaziou writes:
> I do not notice anything like this. There are many compilation errors
> on some files, but they are the same before and after removing an
> org-e-*.el file.
I get them very consistently, in both Emacs 23.3 and 24.1, with and
without my patches.
org-mode> rm lisp/org-{ex
Hello,
Bernt Hansen writes:
> Are there analogous variables to
>
> (setq org-export-author-info nil)
> (setq org-export-creator-info nil)
> (setq org-export-time-stamp-file nil)
>
> in the new exporter to control export of the author, creator, and
> timestamp by default?
>
> I haven't been able
Achim Gratz writes:
> Nicolas Goaziou writes:
>> declarations (instead of requires) are here to avoid circular
>> dependencies. Why do you want to revert that in the first place?
>
> ...because so many of them were missing that it seemed easier to simply
> pull in the definitions by requirement.
Nicolas Goaziou writes:
>> One of test fails (but independently of compiling or not compiling the
>> rest of the new exporter). The failing test is
>> test-org-element/src-block-interpreter, it appears that the test
>> expects the block to be indented by two spaces, but it starts at the
>> beginni
Nicolas Goaziou writes:
> declarations (instead of requires) are here to avoid circular
> dependencies. Why do you want to revert that in the first place?
...because so many of them were missing that it seemed easier to simply
pull in the definitions by requirement.
>> The way org-export is struc
Hello,
Achim Gratz writes:
>here's my first stab on fixing some of that:
>
> From d7ef1bfbaef873521731697d86112029f02cdc8b Mon Sep 17 00:00:00 2001
> From: Achim Gratz
> Date: Sat, 2 Jun 2012 18:38:24 +0200
> Subject: [PATCH 5/5] Make byte-compiler more happy
>
> * contrib/lisp/org-e-ascii.el:
Achim Gratz writes:
> The way org-export is structured unfortunately produces circular
> dependencies due to the dispatcher and that prevents it from being
> compiled properly.
It appears the reason for this is rather the use of cl macros in the
dispatcher code. Depending on where you require org
Hi Achim
On Sun, Jun 3, 2012 at 3:13 PM, Achim Gratz wrote:
> Please do a 'git fetch --tags origin' — you seem to have pulled the
> non-annotated release tag for 7.8.11 before Bastien corrected it.
Oh yes, thanks for reminding me on that. I fetched tags after the
annonuncement on 2012-04-11 to d
Achim Gratz writes:
> * contrib/lisp/org-e-html.el: Remove declarations and replace with
> require.
Thanks for this. I have applied some hunks. The rest I will revisit at
opportune moment.
I have also taken care of org-e-odt.
--
[re-sent, sorry if you get this twice]
Michael Brand writes:
> With an Org file containing only "* a\n" the old exporter is ok but the
> new exporter release_7.8.10-633 on 23.3.1 makes an ODT reported as
> "corrupt" by OOo. Attached are the Org and ODT exported as old, new
> and new repaired by OO
Hi Jambunathan
On Sat, Jun 2, 2012 at 6:35 PM, Michael Brand
wrote:
[...]
> see attached backtrace
[...]
It seems to me you made the recent commit release_7.8.11-37-gec368e8
for my backtrace. So I tested and can confirm that it is resolved.
Also my original issue with the corrupt ODT is resolved
Jambunathan K writes:
> Have you tried the new exporter?
>
> 1. Add contrib/lisp to load-path
> 2. M-x load-library RET org-export RET
> 3. M-x org-export-dispatch RET
Better yet, hardlink those files in contrib/lisp you want to use into
lisp/, but remember to always edit them in contrib/lisp and
Hi Jambunathan
On Sat, Jun 2, 2012 at 5:18 PM, Jambunathan K wrote:
> After sending out the email, I realized that `org-e-odt-prettify-xml' is
> ON by default in the org-e-odt.el. Now I have turned it off.
>
> Hopefully things are OK at your end with this "fix".
Thank you for looking into this.
Jambunathan K writes:
> Unless you hand-edited the ODT document, I think the error could be
> because of one of the customizations you have. (Do you have
> `org-e-odt-prettify-xml' set to t. If yes, what mode does mimetype
> file open for you. For me, mimetype opens in Fundamental mode.)
Afte
Jambunathan K writes:
> I think the error could be because of one of the customizations you
> have.
Good way to check this is with:
"C:\Program Files\emacs-24.0.97\bin\runemacs.exe" -Q -L
~/src/org-mode/lisp/ -L ~/src/org-mode/contrib/lisp/
(Note the -Q and adjusted load-paths)
M-x load-libra
Michael Brand writes:
> Hi all
>
> If OpenOffice.org 3.2.0 is too old to count please tell me and forget.
>
> With an Org file containing only "* a\n" the old exporter is ok but the
> new exporter release_7.8.10-633 on 23.3.1 makes an ODT reported as
> "corrupt" by OOo. Attached are the Org and O
François Pinard writes:
> Nicolas Goaziou writes:
>> I'd rather pull you into writing a Texinfo back-end for the export
>> engine ;)
Well, Nicolas has been much helpful at getting me started on this one.
> I might aim Python.
Nicolas' works are so nicely done that it would be rather insane n
Nicolas Goaziou writes:
> No, org-export needs testing, and I'm ready to debug it. [...] I do
> not ask you to debug anything, but, if you can provide them, ECM help
> a lot. In any case, please report the problems you get with it.
> [...] I think reporting to this list is fine as it may prev
Hello,
François Pinard writes:
> Nicolas Goaziou writes:
>> Assuming contrib directory is in your load-path, just evaluate
>> (require 'org-export)
>
> It would be that simple? This is surely worth a try then!
>
> Well, I'm quickly encountering a few problems. Are my tries
> premature,
No
Hi Nicolas,
>> when exporting this with the new exporter, the line #+name: plot_baz is
>> exported literally to the both, LaTeX and ODT. Is this a bug?
>>
>> #+name: plot_baz
>> #+begin_src R :exports results :results graphics :file fig_baz.png
>> plot(1:10) #+end_src
>>
>> #+caption: BAZ
>> #+
Andreas Leha writes:
> when exporting this with the new exporter, the line #+name: plot_baz is
> exported literally to the both, LaTeX and ODT. Is this a bug?
>
> #+name: plot_baz
> #+begin_src R :exports results :results graphics :file fig_baz.png
> plot(1:10) #+end_src
>
> #+caption: BAZ
> #
Hi Nicolas,
>> The LaTeX file looks like this:
>> ,
>> | [...]|
>> | \begin{document} |
>> | |
>> | \maketitle
Hello,
Andreas Leha writes:
> The LaTeX file looks like this:
> ,
> | [...]|
> | \begin{document} |
> | |
> | \maketitle
Hi Nicolas,
thanks once more for the prompt reaction!
>
>> #+TITLE: Test subscripts
>> #+OPTIONS: ^:{}
>>
>> * Test
>> Hi all,
>>
>> there seems to be a problem with the option above in the new
>> exporter, as this_o is exported as subscript for me.
>
> I tried various values for `org-export-with-
Hello,
Andreas Leha writes:
> #+TITLE: Test subscripts
> #+OPTIONS: ^:{}
>
> * Test
> Hi all,
>
> there seems to be a problem with the option above in the new
> exporter, as this_o is exported as subscript for me.
I tried various values for `org-export-with-sub-superscripts' and
`org-use-sub-su
Nicolas Goaziou writes:
> Hello,
>
> Andreas Leha writes:
>
>> I experience problems with the new export engine (accessible via
>> org-export-dispatch).
>>
>> When I limit the export to the current subtree,
>> the export fails with
>> ,
>> | if: reference 'foo' not found in this buffer
>> `-
Hello,
Andreas Leha writes:
> I experience problems with the new export engine (accessible via
> org-export-dispatch).
>
> When I limit the export to the current subtree,
> the export fails with
> ,
> | if: reference 'foo' not found in this buffer
> `
> when 'foo' is the name of a source
501 - 595 of 595 matches
Mail list logo
