Bastien b...@altern.org wrote:
Hi Nicolas,
Nicolas Goaziou n.goaz...@gmail.com 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 }
Nick Dokos nicholas.do...@hp.com writes:
FWIW, I cannot reproduce this.
Me neither, dunno what I did. Sorry for the noise,
--
Bastien
On Tue, Aug 21, 2012 at 01:34:16AM -0400, Nick Dokos wrote:
Rick Frankel r...@rickster.com 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 t.png
Hello,
Rick Frankel r...@rickster.com 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
Hello,
Rick Frankel r...@rickster.com 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
On Tue, Aug 21, 2012 at 12:54:25AM +0200, Nicolas Goaziou wrote:
Hello,
Rick Frankel r...@rickster.com 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
Rick Frankel r...@rickster.com wrote:
On Tue, Aug 21, 2012 at 12:54:25AM +0200, Nicolas Goaziou wrote:
Hello,
Rick Frankel r...@rickster.com writes:
Has the syntax for latex attributes changed in the new exporter, or is
is the following a bug?
Neither. Though, at some point,
Hi Niclolas,
thanks for your answer and explaination.
· Nicolas Goaziou n.goaz...@gmail.com wrote:
Hello,
Holst Thomas (DGS-EC/ESE4) thomas.ho...@de.bosch.com writes:
Perhaps there is a misunderstanding.
There was. Now I get it.
So it isn't about blocks. It is about LaTeX-fragments in
Hello,
Thomas Holst thomas.ho...@de.bosch.com 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 |
Nicolas Goaziou n.goaz...@gmail.com writes:
Achim Gratz strom...@nexgo.de 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
Hi Nicolas,
· Nicolas Goaziou n.goaz...@gmail.com wrote:
Hello,
Thomas Holst thomas.ho...@de.bosch.com 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:
Da: Thomas Holst thomas.ho...@de.bosch.com
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
Hello,
Thomas Holst thomas.ho...@de.bosch.com 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
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,
Holst Thomas (DGS-EC/ESE4) thomas.ho...@de.bosch.com 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
Hello,
Jonathan Leech-Pepin jonathan.leechpe...@gmail.com 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.
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:
[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
Hello,
Thomas Holst thomas.ho...@de.bosch.com 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
Hello,
Myles English mylesengl...@gmail.com 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
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
Myles English mylesengl...@gmail.com 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.
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... again, that
Hello,
Achim Gratz strom...@nexgo.de 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
Hello,
Achim Gratz strom...@nexgo.de 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
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 strom...@nexgo.de 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
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-12
Hello,
Achim Gratz strom...@nexgo.de 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 n.goaz...@gmail.com 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
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 Blofeld]+
Hello,
Achim Gratz strom...@nexgo.de 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
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 know
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
Achim Gratz strom...@nexgo.de 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
Jambunathan K kjambunat...@gmail.com writes:
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
Achim Gratz strom...@nexgo.de 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
Hello,
Achim Gratz strom...@nexgo.de 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
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 rather
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 n.goaz...@gmail.com 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
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 n.goaz...@gmail.com writes:
Hello,
Charles Berry ccbe...@ucsd.edu 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
Hello,
Charles Berry ccbe...@ucsd.edu 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
Hello,
Achim Gratz strom...@nexgo.de 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
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 gensymed
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
Hello,
Achim Gratz strom...@nexgo.de 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
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.
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 strom...@nexgo.de 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
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 after
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 in
Hello,
Achim Gratz strom...@nexgo.de 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
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 and
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)
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
Hi Nicolas,
Hello,
Andreas Leha andreas.l...@med.uni-goettingen.de 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:
|
Hello,
Andreas Leha andreas.l...@med.uni-goettingen.de 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
|
Hello,
Thorsten Jolitz tjol...@googlemail.com 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
Hello,
Bernt Hansen be...@norang.ca 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
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
Hello,
Achim Gratz strom...@nexgo.de 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
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
Achim Gratz strom...@nexgo.de 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
Nicolas Goaziou writes:
Achim Gratz strom...@nexgo.de 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
Hello,
Achim Gratz strom...@nexgo.de writes:
here's my first stab on fixing some of that:
From d7ef1bfbaef873521731697d86112029f02cdc8b Mon Sep 17 00:00:00 2001
From: Achim Gratz strom...@stromeko.de
Date: Sat, 2 Jun 2012 18:38:24 +0200
Subject: [PATCH 5/5] Make byte-compiler more happy
*
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
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
beginning of
Achim Gratz strom...@nexgo.de 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
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
Hi Jambunathan
On Sat, Jun 2, 2012 at 6:35 PM, Michael Brand
michael.ch.br...@gmail.com 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
[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 OOo
Achim Gratz strom...@nexgo.de 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.
--
Hi Achim
On Sun, Jun 3, 2012 at 3:13 PM, Achim Gratz strom...@nexgo.de 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
Michael Brand michael.ch.br...@gmail.com 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
Jambunathan K kjambunat...@gmail.com 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
Jambunathan K kjambunat...@gmail.com 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
Hi Jambunathan
On Sat, Jun 2, 2012 at 5:18 PM, Jambunathan K kjambunat...@gmail.com 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
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
François Pinard pin...@iro.umontreal.ca writes:
Nicolas Goaziou n.goaz...@gmail.com 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
Hello,
François Pinard pin...@iro.umontreal.ca writes:
Nicolas Goaziou n.goaz...@gmail.coma 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
Nicolas Goaziou n.goaz...@gmail.com 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
Hello,
Andreas Leha andreas.l...@med.uni-goettingen.de 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
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-sub-superscripts'
Hello,
Andreas Leha andreas.l...@med.uni-goettingen.de writes:
The LaTeX file looks like this:
,
| [...]|
| \begin{document} |
|
Hi Nicolas,
The LaTeX file looks like this:
,
| [...]|
| \begin{document} |
| |
| \maketitle
Andreas Leha andreas.l...@med.uni-goettingen.de 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)
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
#+label: fig-baz
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
Andreas Leha andreas.l...@med.uni-goettingen.de 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
Hello,
Andreas Leha andreas.l...@med.uni-goettingen.de 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
501 - 588 of 588 matches
Mail list logo
