Re: [O] [ANN] ASCII back-end for new export engine
Hi Nicolas,
Nicolas Goaziou wrote:
t...@tsdye.com (Thomas S. Dye) writes:
I defined a new entity in org-entities-user, but the new exporter
appears to ignore it. Does it look at this variable, or just
org-entities?
I used:
(add-to-list 'org-entities-user '(omacr \\={o} nil #333; o o ō))
without a problem.
IIUC, you specify how to translate some LaTeX-like command to the different
back-ends. But I don't see DocBook nor OOo in the list:
┏
┃ User-defined entities used in Org-mode to produce special characters.
┃ Each entry in this list is a list of strings. It associates the name
┃ of the entity that can be inserted into an Org file as \name with the
┃ appropriate replacements for the different export backends. The order
┃ of the fields is the following
┃
┃ name As a string, without the leading backslash
┃ LaTeX replacementIn ready LaTeX, no further processing will take place
┃ LaTeX mathp A Boolean, either t or nil. t if this entity needs
┃ to be in math mode.
┃ HTML replacement In ready HTML, no further processing will take place.
┃ Usually this will be an ...; entity.
┃ ASCII replacementPlain ASCII, no extensions. Symbols that cannot be
┃ represented will be left as they are, but see the.
┃ variable `org-entities-ascii-explanatory'.
┃ Latin1 replacement Use the special characters available in latin1.
┃ utf-8 replacementUse the special characters available in utf-8.
┃
┃ If you define new entities here that require specific LaTeX packages to be
┃ loaded, add these packages to `org-export-latex-packages-alist'.
┗
Aren't those backends missing? Or do I miss how it really is used?
Best regards,
Seb
--
Sebastien Vauban
Re: [O] [ANN] ASCII back-end for new export engine
Hi Nicolas,
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
I defined a new entity in org-entities-user, but the new exporter
appears to ignore it. Does it look at this variable, or just
org-entities?
I used:
(add-to-list 'org-entities-user '(omacr \\={o} nil #333; o o ō))
without a problem.
Thanks. User error on this end.
I played around a bit with entities defined in org-entities, and these
do transcode properly. How do I get one in the middle of a word? If I
leave a space after the entity, the space ends up in the output. If I
don't leave a space, the entity isn't recognized.
Use {}, i.e. some w\omacr{}rd (new exporter only).
Yes, that works, too.
Thanks again for the help.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] [ANN] ASCII back-end for new export engine
Sebastien Vauban
wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes:
Nicolas Goaziou wrote:
I used:
(add-to-list 'org-entities-user '(omacr \\={o} nil #333; o o ō))
without a problem.
IIUC, you specify how to translate some LaTeX-like command to the different
back-ends. But I don't see DocBook nor OOo in the list:
┏
┃ User-defined entities used in Org-mode to produce special characters.
┃ Each entry in this list is a list of strings. It associates the name
┃ of the entity that can be inserted into an Org file as \name with the
┃ appropriate replacements for the different export backends. The order
┃ of the fields is the following
┃
┃ name As a string, without the leading backslash
┃ LaTeX replacementIn ready LaTeX, no further processing will take
place
┃ LaTeX mathp A Boolean, either t or nil. t if this entity needs
┃ to be in math mode.
┃ HTML replacement In ready HTML, no further processing will take
place.
┃ Usually this will be an ...; entity.
┃ ASCII replacementPlain ASCII, no extensions. Symbols that cannot be
┃ represented will be left as they are, but see the.
┃ variable `org-entities-ascii-explanatory'.
┃ Latin1 replacement Use the special characters available in latin1.
┃ utf-8 replacementUse the special characters available in utf-8.
┃
┃ If you define new entities here that require specific LaTeX packages to
be
┃ loaded, add these packages to `org-export-latex-packages-alist'.
┗
Aren't those backends missing? Or do I miss how it really is used?
I think most back-ends understand at least one of the formats used in
this alist. For example the DocBook one just reads HTML entry.
Regards,
--
Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes: IIUC, you specify how to translate some LaTeX-like command to the different back-ends. But I don't see DocBook nor OOo in the list: ┏ ┃ User-defined entities used in Org-mode to produce special characters. ┃ Each entry in this list is a list of strings. It associates the name ┃ of the entity that can be inserted into an Org file as \name with the ┃ appropriate replacements for the different export backends. The order ┃ of the fields is the following ┃ ┃ name As a string, without the leading backslash ┃ LaTeX replacementIn ready LaTeX, no further processing will take place ┃ LaTeX mathp A Boolean, either t or nil. t if this entity needs ┃ to be in math mode. ┃ HTML replacement In ready HTML, no further processing will take place. ┃ Usually this will be an ...; entity. ┃ ASCII replacementPlain ASCII, no extensions. Symbols that cannot be ┃ represented will be left as they are, but see the. ┃ variable `org-entities-ascii-explanatory'. ┃ Latin1 replacement Use the special characters available in latin1. ┃ utf-8 replacementUse the special characters available in utf-8. ┃ ┃ If you define new entities here that require specific LaTeX packages to be ┃ loaded, add these packages to `org-export-latex-packages-alist'. ┗ Aren't those backends missing? Or do I miss how it really is used? I think most back-ends understand at least one of the formats used in this alist. For example the DocBook one just reads HTML entry. ODT uses utf-8. Also see http://lists.gnu.org/archive/html/emacs-orgmode/2012-01/msg00475.html. --
Re: [O] [ANN] ASCII back-end for new export engine
Hello, t...@tsdye.com (Thomas S. Dye) writes: This docstring at line 186 of org-e-latex.el is incomplete Fixed. BTW, I have the experimental LaTeX exporter working on a real project now. It is performing very well for me. Good to hear. I still need to fix the #+toc: listings keyword (which currently provides a wrong command), though, and implement booktabs, as suggested in another thread. Thanks again. Regards, -- Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
This docstring at line 186 of org-e-latex.el is incomplete
Fixed.
BTW, I have the experimental LaTeX exporter working on a real project
now. It is performing very well for me.
Good to hear. I still need to fix the #+toc: listings keyword (which
currently provides a wrong command), though, and implement booktabs, as
suggested in another thread.
Thanks again.
Regards,
Hi Nicolas,
A couple of questions.
The old exporter recognized LaTeX commands for accented characters. So,
\=o in the Org mode file would yield \={o} in the LaTeX file. The new
exporter gives $\backslash$=o for this construct. How does the new
LaTeX exporter recognize accented characters?
I can't find a way to get creator information into \hypersetup{} without
also having it inserted as normal text at the end of the file. Is this
possible?
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] [ANN] ASCII back-end for new export engine
t...@tsdye.com (Thomas S. Dye) writes:
The old exporter recognized LaTeX commands for accented characters. So,
\=o in the Org mode file would yield \={o} in the LaTeX file. The new
exporter gives $\backslash$=o for this construct.
Indeed, the parser recognizes LaTeX commands and environments, but is
more strict with other LaTeXisms.
How does the new
LaTeX exporter recognize accented characters?
The Org way (portable across major back-ends) to handle this is to
define an new entity, and name it for example omacr[1]. You can
then access it with \omacr in your buffer.
Other (but inferior) solutions could be to define a macro:
#+macro: omacr \={o}
or use an export snippet:
@e-latex{\={o}}
I can't find a way to get creator information into \hypersetup{} without
also having it inserted as normal text at the end of the file. Is this
possible?
That's not possible at the moment.
There are three states for creator, on, off and comment, and two places
to insert the information (in hypersetup and at the end of the exported
data).
What would be a correct way to handle the different configurations here?
Regards,
[1] I'm a bit surprised that it doesn't exist in `org-entities', as
many national characters are already there.
--
Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes:
t...@tsdye.com (Thomas S. Dye) writes:
The old exporter recognized LaTeX commands for accented characters. So,
\=o in the Org mode file would yield \={o} in the LaTeX file. The new
exporter gives $\backslash$=o for this construct.
Indeed, the parser recognizes LaTeX commands and environments, but is
more strict with other LaTeXisms.
How does the new
LaTeX exporter recognize accented characters?
The Org way (portable across major back-ends) to handle this is to
define an new entity, and name it for example omacr[1]. You can
then access it with \omacr in your buffer.
Yes, this seems like a good solution. Thanks.
Other (but inferior) solutions could be to define a macro:
#+macro: omacr \={o}
or use an export snippet:
@e-latex{\={o}}
I can't find a way to get creator information into \hypersetup{} without
also having it inserted as normal text at the end of the file. Is this
possible?
That's not possible at the moment.
There are three states for creator, on, off and comment, and two places
to insert the information (in hypersetup and at the end of the exported
data).
What would be a correct way to handle the different configurations here?
Perhaps:
- off, no information is inserted
- on, information is inserted in \hypersetup{} and as text at the end of the
file
- comment, information is inserted in \hypersetup and as a comment at the
end of the file.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] [ANN] ASCII back-end for new export engine
Hi Nicolas,
I couldn't make this work.
Nicolas Goaziou n.goaz...@gmail.com writes:
t...@tsdye.com (Thomas S. Dye) writes:
The old exporter recognized LaTeX commands for accented characters. So,
\=o in the Org mode file would yield \={o} in the LaTeX file. The new
exporter gives $\backslash$=o for this construct.
Indeed, the parser recognizes LaTeX commands and environments, but is
more strict with other LaTeXisms.
How does the new
LaTeX exporter recognize accented characters?
The Org way (portable across major back-ends) to handle this is to
define an new entity, and name it for example omacr[1]. You can
then access it with \omacr in your buffer.
I defined a new entity in org-entities-user, but the new exporter
appears to ignore it. Does it look at this variable, or just
org-entities?
I played around a bit with entities defined in org-entities, and these
do transcode properly. How do I get one in the middle of a word? If I
leave a space after the entity, the space ends up in the output. If I
don't leave a space, the entity isn't recognized.
All the best,
Tom
Other (but inferior) solutions could be to define a macro:
#+macro: omacr \={o}
or use an export snippet:
@e-latex{\={o}}
I can't find a way to get creator information into \hypersetup{} without
also having it inserted as normal text at the end of the file. Is this
possible?
That's not possible at the moment.
There are three states for creator, on, off and comment, and two places
to insert the information (in hypersetup and at the end of the exported
data).
What would be a correct way to handle the different configurations here?
Regards,
[1] I'm a bit surprised that it doesn't exist in `org-entities', as
many national characters are already there.
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] [ANN] ASCII back-end for new export engine
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
I defined a new entity in org-entities-user, but the new exporter
appears to ignore it. Does it look at this variable, or just
org-entities?
I used:
--8---cut here---start-8---
(add-to-list 'org-entities-user '(omacr \\={o} nil #333; o o ō))
--8---cut here---end---8---
without a problem.
I played around a bit with entities defined in org-entities, and these
do transcode properly. How do I get one in the middle of a word? If I
leave a space after the entity, the space ends up in the output. If I
don't leave a space, the entity isn't recognized.
Use {}, i.e. some w\omacr{}rd (new exporter only).
Regards,
--
Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
t...@tsdye.com (Thomas S. Dye) writes:
Nicolas Goaziou n.goaz...@gmail.com writes:
There are three states for creator, on, off and comment, and two places
to insert the information (in hypersetup and at the end of the exported
data).
What would be a correct way to handle the different configurations here?
Perhaps:
- off, no information is inserted
- on, information is inserted in \hypersetup{} and as text at the end of
the file
- comment, information is inserted in \hypersetup and as a comment at the
end of the file.
This is now the case. Thanks.
Regards,
--
Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
Hello, t...@tsdye.com (Thomas S. Dye) writes: References to org-e-latex-packages-alist in org-e-latex.el docstrings should be to org-export-latex-packages-alist. This should be fixed (along with your other report). Thanks for both reports. Regards, -- Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
I've commited an ASCII back-end for new export engine.
Assuming contrib directory is in your load-path, you just need to
(require 'org-export) to have both LaTeX and ASCII exporters ready to
boot.
You can then access to the dispatcher with M-x org-export-dispatch and
test various configurations from there.
As a reminder, you can ask for a table of contents, list of tables and
list of listings with, respectively, #+toc: headlines, #+toc: tables
and #+toc: listings. Also, drawers[1] are exported transparently by
default.
Feedback is welcome.
Regards,
[1] properties drawers excepted: those are different elements anyway.
Hi Nicolas,
This docstring at line 186 of org-e-latex.el is incomplete:
If your header or `org-export-latex-default-packages-alist'
inserts \\\usepackage[AUTO]{inputenc}\, AUTO will automatically
be replaced with a coding system derived from
`buffer-file-coding-system'.
AUTO is automatically replaced when org-export-latex-packages-alist
inserts it, as well.
BTW, I have the experimental LaTeX exporter working on a real project
now. It is performing very well for me. Great work!
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, t...@tsdye.com (Thomas S. Dye) writes: I haven't been able to export a listing yet. The following source exports with the old exporter, but fails with the experimental exporter. This long standing bug should be fixed now. Regards, Yes, I think it is fixed now. Thanks for your good work. Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, I've commited an ASCII back-end for new export engine. Assuming contrib directory is in your load-path, you just need to (require 'org-export) to have both LaTeX and ASCII exporters ready to boot. You can then access to the dispatcher with M-x org-export-dispatch and test various configurations from there. As a reminder, you can ask for a table of contents, list of tables and list of listings with, respectively, #+toc: headlines, #+toc: tables and #+toc: listings. Also, drawers[1] are exported transparently by default. Feedback is welcome. Regards, [1] properties drawers excepted: those are different elements anyway. Hi Nicolas, On line 427 of org-e-latex.el, reference to the variable org-e-latex-to-pdf-process in the docstring should be to org-e-latex-pdf-process. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, I've commited an ASCII back-end for new export engine. Assuming contrib directory is in your load-path, you just need to (require 'org-export) to have both LaTeX and ASCII exporters ready to boot. You can then access to the dispatcher with M-x org-export-dispatch and test various configurations from there. As a reminder, you can ask for a table of contents, list of tables and list of listings with, respectively, #+toc: headlines, #+toc: tables and #+toc: listings. Also, drawers[1] are exported transparently by default. Feedback is welcome. Regards, [1] properties drawers excepted: those are different elements anyway. Hi Nicolas, References to org-e-latex-packages-alist in org-e-latex.el docstrings should be to org-export-latex-packages-alist. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] [ANN] ASCII back-end for new export engine
Hello, t...@tsdye.com (Thomas S. Dye) writes: I haven't been able to export a listing yet. The following source exports with the old exporter, but fails with the experimental exporter. This long standing bug should be fixed now. Regards, -- Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes: No. Headlines, along with items, keywords and sections, can't have affiliated keywords. Though, they have properties. It may be done with: :PROPERTIES: :NUMBERING: nil :END: But it's still new syntax. It could also be narrowed to :LATEX_NUMBERING: nil, but I think that this feature, if implemented, should be available for every major back-end, much like num:1. This is how headlines are formatted in ODF. #+begin_src nxml text:h text:style-name=Heading_20_1 text:outline-level=1 ... /text:h #+end_src The style name says the paragraph properties of the heading. The outline level (indirectly) specifies the numbering properties. By bumping outline-level to a very high-value it should be possible to have a particular headline to be rendered unnumbered and not enter TOC. As a side note, it looks like we are talking various means of headline behaviour vis a vis numbering 1. numbered and listed 2. unnumbered and listed 3. unnumbered and not listed 4. listified Hope we are able to choose a property name that reflects it's functionality vis-a-vis it's listing behaviour. --
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes: I may be bold, but I still don't get it. num:something is a global option. We're talking about specifying _individually_ which headline wouldn't be numbered. How would a global option solve a local problem? Had another thought about it: if the exporter took note of properties, one could attach a property drawer to that headline. That has the advantage that any subheadings would correctly not be numbered as well, through property inheritance. Would that work? Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] [ANN] ASCII back-end for new export engine
Hi N, Some comments on your great work: Recent version errors with wrong type argument, but I can't privacy-wash yet to show the whole stack trace. make-string(-1 32) (concat aligned-cell (make-string (- col-width ...) 32)) (format %s (concat aligned-cell (make-string ... 32))) (let* ((indent-tabs-mode nil) (align ...) (aligned-cell ...)) (format %s (concat aligned-cell ...))) (let ((col-width ...)) (unless (or org-e-ascii-table-widen-columns ...) (setq cell ...)) (let* (... ... ...) (format %s ...))) For what it's worth. I might need to give you a full stack trace if that is not enough. 22 with latest git. I suspect it is because your exporter actually tries to understand all syntax, while the old one passes through a lot of things (maybe including list-like things). These comments are from an earlier version that worked: I like to separate things like this: === The old exporter left it intact; the new one tries to interpret it even though /text/ and *text* are left intact. I'm guessing this is a new feature that works only on =word=. I'd like to turn it off if it can't be made to not interpret my separator. Most lines are indented by 2 spaces. I'd prefer flush to left. It splits the window even though I have pop-up-windows set to nil. Block quotes indent by 8 or so. That's rather nice, but is there an option to change that to 2 or 4? Lists are not indented although I always indent them by 2. Is there an option to set the fill column and refill paragraphs (roughly like the way HTML does)? I'd find that highly useful. Unfilling too. Feature requesti --export tables using tab characters. If it doesn't exist already. Maybe it does? Footnotes don't have a header. HTML export inserts one. No final newline. One missing footnote . It is going to take me a while to narrow it down. Thanks. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com === Bigotry against people with serious diseases is still bigotry.
Re: [O] [ANN] ASCII back-end for new export engine
Hello, Samuel Wales samolog...@gmail.com writes: Recent version errors with wrong type argument, but I can't privacy-wash yet to show the whole stack trace. I don't need the whole stack trace, but there is at least one table in your buffer that causes problems to the exporter. I'd need to see it. If you don't know which one it is, you can successively mark each table in that buffer and use org-export-dispatch with the region active (it will only export the region) until the culprit is found. These comments are from an earlier version that worked: I like to separate things like this: === The old exporter left it intact; the new one tries to interpret it In Org syntax, this is really a verbatim equal sign. It is exported as such. There are a few solutions to your problem: - Use Org's separator: -; - Disable every emphasis interpretation in the buffer with option *:nil; - Configure format string for verbatim text (org-e-ascii-verbatim-format). That will affect ~code~, =verbatim= and inline src blocks. - Use another separator (i.e. = = =) Most lines are indented by 2 spaces. I'd prefer flush to left. You may customize `org-e-ascii-inner-margin'. It splits the window even though I have pop-up-windows set to nil. This variable is related to `display-buffer', which isn't used to display output. You may want to tweak `org-export-show-temporary-export-buffer', though. Block quotes indent by 8 or so. That's rather nice, but is there an option to change that to 2 or 4? I've pushed a commit introducing variable `org-e-ascii-quote-margin' to solve this. Lists are not indented although I always indent them by 2. e-ascii back-end has its own (configurable) layout. In particular, it doesn't bother with the indentation you use in the original Org buffer. I'm not convinced that lists should be made special and have their own margin variable. There are not many visual markers in the ASCII output, indentation being one of them. I prefer to use them parsimoniously. Is there an option to set the fill column and refill paragraphs (roughly like the way HTML does)? I'd find that highly useful. By default, text is already filled at a fill column of 72. You may customize `org-e-ascii-text-width' for different values. Feature requesti --export tables using tab characters. If it doesn't exist already. Maybe it does? Do you mean inserting tabs instead of white spaces in cells? If that's the case, I'd rather not implement it. Footnotes don't have a header. HTML export inserts one. I've pushed a commit introducing a header for the final footnotes. No final newline. I've pushed a commit fixing this. One missing footnote . It is going to take me a while to narrow it down. I cannot help with so little information. Though, I'd be interested in an ECM. Thanks for your feedback. Regards, -- Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
On 2012-01-28, Nicolas Goaziou n.goaz...@gmail.com wrote: If you don't know which one it is, you can successively mark each table in that buffer and use org-export-dispatch with the region active (it will only export the region) until the culprit is found. I get Before first headline at position ... error. Can't send stack trace now. (org-e-ascii-verbatim-format). That will affect ~code~, =verbatim= and inline src blocks. Can these be affected individually? Or can emphasis be told to be always left in verbatim? It splits the window even though I have pop-up-windows set to nil. Rationale: It is true that this only applies to display-buffer. And this is not only a problem with your exporter. But most of Emacs can be made to work properly with this variable. There are parts that do not. Those require an ever-expanding list of defadvices, same-window-*, and other kludges to use the same window. pop-up-windows is a good candidate for the user to signal the intention to do this for all output buffers. In any case, I added a defadvice. There does not exist any way to say Do not split output windows. So it is a constant struggle. Lists are not indented although I always indent them by 2. e-ascii back-end has its own (configurable) layout. In particular, it doesn't bother with the indentation you use in the original Org buffer. I'm not convinced that lists should be made special and have their own margin variable. There are not many visual markers in the ASCII output, indentation being one of them. I prefer to use them parsimoniously. I might need to stick with the old exporter then. Here are 2 reasons I like indented lists: 1) Notice how it is set off so you know when the end of the list is? 2) Other reasons Feature requesti --export tables using tab characters. If it doesn't exist already. Maybe it does? Do you mean inserting tabs instead of white spaces in cells? If that's the case, I'd rather not implement it. No, I mean that this is a useful way to send things to people who use proportional fonts. Thanks for your feedback. Thanks for your work on the exporter. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com
Re: [O] [ANN] ASCII back-end for new export engine
Samuel Wales samolog...@gmail.com writes: On 2012-01-28, Nicolas Goaziou n.goaz...@gmail.com wrote: If you don't know which one it is, you can successively mark each table in that buffer and use org-export-dispatch with the region active (it will only export the region) until the culprit is found. I get Before first headline at position ... error. Can't send stack trace now. Ok. Be sure to have latest git, though. (org-e-ascii-verbatim-format). That will affect ~code~, =verbatim= and inline src blocks. Can these be affected individually? No. Or can emphasis be told to be always left in verbatim? Yes. Simply override actual function translating verbatim text by putting this in your config. #+begin_src emacs-lisp (defun org-e-ascii-verbatim (verbatim contents info) Return a VERBATIM object from Org to ASCII. CONTENTS is nil. INFO is a plist holding contextual information. (let ((marker (org-element-get-property :marker verbatim)) (value (org-element-get-property :value verbatim))) (concat marker value marker))) #+end_src 1) Notice how it is set off so you know when the end of the list is? - This is an item with some text. This is obviously inside the list. This is obviously outside the list. Feature requesti --export tables using tab characters. If it doesn't exist already. Maybe it does? Do you mean inserting tabs instead of white spaces in cells? If that's the case, I'd rather not implement it. No, I mean that this is a useful way to send things to people who use proportional fonts. But in the simplest cases, tables will look ugly with proportional fonts, no matter if you use tabs or not. It isn't worth the struggle. Regards, -- Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
On 2012-01-28, Nicolas Goaziou n.goaz...@gmail.com wrote: - This is an item with some text. Sets off much less. No, I mean that this is a useful way to send things to people who use proportional fonts. But in the simplest cases, tables will look ugly with proportional fonts, no matter if you use tabs or not. It isn't worth the struggle. Simplest case is perhaps short numbers which always works perfectly with tabs. Even with ugliness, tabs make it easier to understand the table IMO. I won't press the issues, but did not want those to be misunderstood.
Re: [O] [ANN] ASCII back-end for new export engine
Samuel Wales samolog...@gmail.com writes: On 2012-01-28, Nicolas Goaziou n.goaz...@gmail.com wrote: - This is an item with some text. Sets off much less. Well. I'm still not sure why plain lists should have their own indentation. In that case, tables, latex-environments, etc. should too. Though, you can still configure what you want with an appropriate filter: #+begin_src emacs-lisp (add-to-list 'org-export-filter-plain-list-functions (lambda (plain-list back-end) (if (not (eq back-end 'e-ascii)) plain-list (replace-regexp-in-string ^plain-list #+end_src No, I mean that this is a useful way to send things to people who use proportional fonts. But in the simplest cases, tables will look ugly with proportional fonts, no matter if you use tabs or not. It isn't worth the struggle. Simplest case is perhaps short numbers which always works perfectly with tabs. Even with ugliness, tabs make it easier to understand the table IMO. I won't press the issues, but did not want those to be misunderstood. I understand. You may want to test this advice, which will convert a table to tsv if #+attr_ascii: tsv is set above the table. #+begin_src emacs-lisp (defadvice org-e-ascii-table (around table-tsv) (if (or (not (member tsv (org-element-get-property :attr_ascii table))) (eq (org-element-get-property :type table) 'table.el)) ad-do-it (setq ad-return-value (orgtbl-to-tsv (org-table-to-lisp (org-element-get-property :raw-table table)) nil #+end_src Regards, -- Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
I have no objection to implement limited numbering in both LaTeX and ASCII back-ends, but I'd like to know if it can be handled consistently in every other major back-end, too. I'm CC-ing Jambunathan to know his opinion about it. I can support this in ODT exporter. We can make this a feature of the new export engine. A way to set individual headings as numbered or unnumbered would be deluxe. Perhaps this is possible, but I haven't found it? It would require to modify Org's syntax (how to tell which headline has to be numbered and which has not?). It is not possible at the moment. Let us not support this. Regards,
Re: [O] [ANN] ASCII back-end for new export engine
Hello, Achim Gratz strom...@nexgo.de writes: Nicolas Goaziou n.goaz...@gmail.com writes: But it's still new syntax. It could also be narrowed to :LATEX_NUMBERING: nil, but I think that this feature, if implemented, should be available for every major back-end, much like num:1. Unless I miss something, if num:* would be allowed in addition to integers, the LaTeX crowd would be pleased, no terribly new syntax would be needed and all other backends could take note to skip numbering that headline. Maybe one could throw in nil and none as an alias for *. I don't understand. What would num:* achieve? Regards, -- Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
On Fri, Jan 27, 2012 at 01:58:26PM +0100, Nicolas Goaziou wrote: Achim Gratz strom...@nexgo.de writes: Unless I miss something, if num:* would be allowed in addition to integers, the LaTeX crowd would be pleased, no terribly new syntax would be needed and all other backends could take note to skip numbering that headline. Maybe one could throw in nil and none as an alias for *. I don't understand. What would num:* achieve? I think it's an attempt to be mnemonically similar to LaTeX -- section* for an unnumbered section. rick
Re: [O] [ANN] ASCII back-end for new export engine
Hello, Rick Frankel r...@rickster.com writes: On Fri, Jan 27, 2012 at 01:58:26PM +0100, Nicolas Goaziou wrote: Achim Gratz strom...@nexgo.de writes: Unless I miss something, if num:* would be allowed in addition to integers, the LaTeX crowd would be pleased, no terribly new syntax would be needed and all other backends could take note to skip numbering that headline. Maybe one could throw in nil and none as an alias for *. I don't understand. What would num:* achieve? I think it's an attempt to be mnemonically similar to LaTeX -- section* for an unnumbered section. I may be bold, but I still don't get it. num:something is a global option. We're talking about specifying _individually_ which headline wouldn't be numbered. How would a global option solve a local problem? Regards, -- Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
Hello, Jambunathan K kjambunat...@gmail.com writes: I have no objection to implement limited numbering in both LaTeX and ASCII back-ends, but I'd like to know if it can be handled consistently in every other major back-end, too. I'm CC-ing Jambunathan to know his opinion about it. I can support this in ODT exporter. We can make this a feature of the new export engine. I've now implemented this for e-latex and e-ascii back-ends. A way to set individual headings as numbered or unnumbered would be deluxe. Perhaps this is possible, but I haven't found it? It would require to modify Org's syntax (how to tell which headline has to be numbered and which has not?). It is not possible at the moment. Let us not support this. I tend to agree here. This can be obviously discussed on the list, detail specifications and so on, but I'd rather postpone any real coding in this area until new exporter is installed in core. Regards, -- Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
Hi all, Nicolas Goaziou n.goaz...@gmail.com writes: I tend to agree here. This can be obviously discussed on the list, detail specifications and so on, but I'd rather postpone any real coding in this area until new exporter is installed in core. I strongly support this. We should try to leave key syntax elements untouched before integrating the new exporter to core. Besides, such questions can be tackled by letting the user specify rules like dont-number-headlines-of-level-x or the likes that don't require syntactic changes. My 2 cents, -- Bastien
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Jambunathan K kjambunat...@gmail.com writes: I have no objection to implement limited numbering in both LaTeX and ASCII back-ends, but I'd like to know if it can be handled consistently in every other major back-end, too. I'm CC-ing Jambunathan to know his opinion about it. I can support this in ODT exporter. We can make this a feature of the new export engine. I've now implemented this for e-latex and e-ascii back-ends. Great! This works nicely for me. A way to set individual headings as numbered or unnumbered would be deluxe. Perhaps this is possible, but I haven't found it? It would require to modify Org's syntax (how to tell which headline has to be numbered and which has not?). It is not possible at the moment. Let us not support this. I tend to agree here. This can be obviously discussed on the list, detail specifications and so on, but I'd rather postpone any real coding in this area until new exporter is installed in core. Yes, this is not a burning issue. In my experience, use of \section* etc. is not frequent. It is certainly not a reason to keep the new exporter from moving toward the Org mode core. Thanks for making the num: option really useful for LaTeX export. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes: I may be bold, but I still don't get it. num:something is a global option. We're talking about specifying _individually_ which headline wouldn't be numbered. How would a global option solve a local problem? It doesn't, I missed that point. I don't think it's so terribly important to warrant any extended effort. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
I've commited an ASCII back-end for new export engine.
Assuming contrib directory is in your load-path, you just need to
(require 'org-export) to have both LaTeX and ASCII exporters ready to
boot.
You can then access to the dispatcher with M-x org-export-dispatch and
test various configurations from there.
As a reminder, you can ask for a table of contents, list of tables and
list of listings with, respectively, #+toc: headlines, #+toc: tables
and #+toc: listings. Also, drawers[1] are exported transparently by
default.
Feedback is welcome.
Regards,
[1] properties drawers excepted: those are different elements anyway.
Aloha Nicolas,
I haven't been able to export a listing yet. The following source
exports with the old exporter, but fails with the experimental exporter.
* Listing heading
#+BEGIN_SRC python :results output
print hello world
#+END_SRC
With the old exporter I get:
\section{Listing heading}
\label{sec-6}
\begin{verbatim}
print hello world
\end{verbatim}
The backtrace with the experimental exporter follows.
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
get-file-buffer(nil)
(org-babel-expand-noweb-references info (get-file-buffer
org-current-export-file))
(if (org-babel-noweb-p (nth 2 info) :export)
(org-babel-expand-noweb-references info (get-file-buffer
org-current-export-file)) (nth 1 info))
(setcar (nthcdr 1 info) (if (org-babel-noweb-p ... :export)
(org-babel-expand-noweb-references info ...) (nth 1 info)))
(setf (nth 1 info) (if (org-babel-noweb-p ... :export)
(org-babel-expand-noweb-references info ...) (nth 1 info)))
(progn (when (member ... ...) (org-babel-exp-in-export-file lang ...) (setf
hash ...)) (setf (nth 1 info) (if ... ... ...)) (org-babel-exp-do-export info
(quote block) hash))
(if info (progn (when ... ... ...) (setf ... ...) (org-babel-exp-do-export
info ... hash)))
(when info (when (member ... ...) (org-babel-exp-in-export-file lang ...)
(setf hash ...)) (setf (nth 1 info) (if ... ... ...)) (org-babel-exp-do-export
info (quote block) hash))
(let* ((info ...) (lang ...) (raw-params ...) hash) (when info (when ... ...
...) (setf ... ...) (org-babel-exp-do-export info ... hash)))
(save-excursion (goto-char (match-beginning 0)) (let* (... ... ... hash)
(when info ... ... ...)))
org-babel-exp-src-block(#(print \hello world\\n 0 1 (fontified t
font-lock-fontified t font-lock-multiline t face py-builtins-face) 1 5
(fontified t font-lock-fontified t font-lock-multiline t face py-builtins-face)
5 6 (fontified t font-lock-fontified t font-lock-multiline t face nil) 6 7
(fontified t font-lock-fontified t font-lock-multiline t face
font-lock-string-face) 7 19 (fontified t font-lock-fontified t
font-lock-multiline t face font-lock-string-face) 19 20 (fontified t
font-lock-fontified t font-lock-multiline t face font-lock-string-face))
#(python 0 6 (font-lock-multiline t face org-block-begin-line
font-lock-fontified t fontified t)) #(:results 0 8 (font-lock-multiline t
face org-block-begin-line font-lock-fontified t fontified t)) #(output 0 6
(font-lock-multiline t face org-block-begin-line font-lock-fontified t
fontified t)))
apply(org-babel-exp-src-block #(print \hello world\\n 0 1 (fontified t
font-lock-fontified t font-lock-multiline t face py-builtins-face) 1 5
(fontified t font-lock-fontified t font-lock-multiline t face py-builtins-face)
5 6 (fontified t font-lock-fontified t font-lock-multiline t face nil) 6 7
(fontified t font-lock-fontified t font-lock-multiline t face
font-lock-string-face) 7 19 (fontified t font-lock-fontified t
font-lock-multiline t face font-lock-string-face) 19 20 (fontified t
font-lock-fontified t font-lock-multiline t face font-lock-string-face))
(#(python 0 6 (font-lock-multiline t face org-block-begin-line
font-lock-fontified t fontified t)) #(:results 0 8 (font-lock-multiline t
face org-block-begin-line font-lock-fontified t fontified t)) #(output 0 6
(font-lock-multiline t face org-block-begin-line font-lock-fontified t
fontified t
(if (memq type org-export-blocks-witheld) (apply func body headers))
(progn (if (memq type org-export-blocks-witheld) (apply func body
headers)))
(unwind-protect (progn (if ... ...)) (set-match-data
save-match-data-internal (quote evaporate)))
(let ((save-match-data-internal ...)) (unwind-protect (progn ...)
(set-match-data save-match-data-internal ...)))
(save-match-data (if (memq type org-export-blocks-witheld) (apply func
body headers)))
(let ((replacement ...)) (when replacement (delete-region match-start
match-end) (goto-char match-start) (insert replacement) (unless preserve-indent
...)))
(progn (let (...) (when replacement ... ... ... ...)))
(if (setq func (cadr ...)) (progn (let ... ...)))
(when (setq func (cadr ...)) (let (...) (when replacement ... ... ... ...)))
(let* ((match-start ...) (body-start ...) (indentation ...)
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes: A way to set individual headings as numbered or unnumbered would be deluxe. Perhaps this is possible, but I haven't found it? It would require to modify Org's syntax (how to tell which headline has to be numbered and which has not?). It is not possible at the moment. Let us not support this. I tend to agree here. I wonder whether there is a one-to-one correspondence between how the headline appears in regular text and how it appears in TOC. If it appears numbered in regular text should it appear numbered in TOC? TOC in ODT exporter is specified by associating an outline level attribute with the headings. The headlines are then collected up to certain level (with each level being associated with a given format). The above model for TOC generation, as LibreOffice sees it, is incompatible with associating headlines as numbered or unnumbered in arbitrary manner. I think headline numbering has to be evaluated in conjunction with TOC (which is but a index entry). --
Re: [O] [ANN] ASCII back-end for new export engine
Jambunathan K kjambunat...@gmail.com writes: Nicolas Goaziou n.goaz...@gmail.com writes: A way to set individual headings as numbered or unnumbered would be deluxe. Perhaps this is possible, but I haven't found it? It would require to modify Org's syntax (how to tell which headline has to be numbered and which has not?). It is not possible at the moment. Let us not support this. I tend to agree here. I wonder whether there is a one-to-one correspondence between how the headline appears in regular text and how it appears in TOC. If it appears numbered in regular text should it appear numbered in TOC? The LaTeX classes with which I'm familiar all ensure that the TOC entry matches the in-text heading wrt numbered/unnumbered. I think this is a principle of document design (which might of course be subverted for some purpose). TOC in ODT exporter is specified by associating an outline level attribute with the headings. The headlines are then collected up to certain level (with each level being associated with a given format). The above model for TOC generation, as LibreOffice sees it, is incompatible with associating headlines as numbered or unnumbered in arbitrary manner. I think headline numbering has to be evaluated in conjunction with TOC (which is but a index entry). Is it the case that ODT lacks the distinction made by LaTeX between, say, \section and \section*? The former is numbered if its depth = secnumdepth and unnumbered otherwise. It appears in the TOC if its depth is = tocdepth, regardless of whether or not it is numbered. The numbering of depths is determined by the class, because the number and kinds of sections vary by document class. Numbering isn't something the user thinks about--it is set by the sectioning command, according to the class file. The \section* form is a special case. It produces an unnumbered heading that does not appear in the TOC. hth, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] [ANN] ASCII back-end for new export engine
Tom The aspect I am exploring is this: Does numbering behavious occur uniformly for a *given* level? For example, are we talking of a scenario where level 3 heading in Tree-1 is numbered while level 3 heading on a Tree-2 is unnumbered. What would be the behaviour of level 4 heading in Tree-1. It seems to me, that an unnumbered heading is a mnemonic(?) for creating a paragraph (albeit a short one) that is styled very much like a heading. When one looks at a printed document, one doesn't really know what mechanism were used to achieve a particular typesetting effect and there could be multiple mechanisms by which the same effect could be achieved. If the above paragraph is true , I think the right thing to do would be to associate a paragraph style with *just* the heading component of an Org's outline level and leave it to the exporter what particular code it wants to emit. --
Re: [O] [ANN] ASCII back-end for new export engine
Jambunathan K kjambunat...@gmail.com writes: Does numbering behavious occur uniformly for a *given* level? For example, are we talking of a scenario where level 3 heading in Tree-1 is numbered while level 3 heading on a Tree-2 is unnumbered. What would be the behaviour of level 4 heading in Tree-1. You can make any level heading unnumbered in LaTeX by adding a * to the section command, without affecting other headings on the same level. You can also specify a different entry to appear in the TOC than in the document — albeit the purpose is to have a short form of the heading in the TOC and the full heading in the document, you can actually specify two totally different strings. It seems to me, that an unnumbered heading is a mnemonic(?) for creating a paragraph (albeit a short one) that is styled very much like a heading. No, LaTeX has \paragraph for that. LaTeX concerns itself with the document structure, it has styles to take care about the formatting. When one looks at a printed document, one doesn't really know what mechanism were used to achieve a particular typesetting effect and there could be multiple mechanisms by which the same effect could be achieved. The point of LaTeX is that you don't manually muck with the formatting at all. If it looks like a heading, then it was a heading and not a paragraph that's been formatted like a heading. 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
Re: [O] [ANN] ASCII back-end for new export engine
Sent from my iPhone On Jan 27, 2012, at 9:21 AM, Achim Gratz strom...@nexgo.de wrote: Jambunathan K kjambunat...@gmail.com writes: Does numbering behavious occur uniformly for a *given* level? For example, are we talking of a scenario where level 3 heading in Tree-1 is numbered while level 3 heading on a Tree-2 is unnumbered. What would be the behaviour of level 4 heading in Tree-1. You can make any level heading unnumbered in LaTeX by adding a * to the section command, without affecting other headings on the same level. You can also specify a different entry to appear in the TOC than in the document — albeit the purpose is to have a short form of the heading in the TOC and the full heading in the document, you can actually specify two totally different strings. Yes, TOC and running heads if the class defines them. It seems to me, that an unnumbered heading is a mnemonic(?) for creating a paragraph (albeit a short one) that is styled very much like a heading. No, LaTeX has \paragraph for that. LaTeX concerns itself with the document structure, it has styles to take care about the formatting. \paragraph and \subparagraph can both be numbered sections in LaTeX. The names are confusing. Apparently, the alternatives, \subsubsubsection and \subsubsubsubsection weren't appealing. Tom When one looks at a printed document, one doesn't really know what mechanism were used to achieve a particular typesetting effect and there could be multiple mechanisms by which the same effect could be achieved. The point of LaTeX is that you don't manually muck with the formatting at all. If it looks like a heading, then it was a heading and not a paragraph that's been formatted like a heading. 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
Re: [O] [ANN] ASCII back-end for new export engine
Thomas S. Dye t...@tsdye.com wrote: \paragraph and \subparagraph can both be numbered sections in LaTeX. The names are confusing. Apparently, the alternatives, \subsubsubsection and \subsubsubsubsection weren't appealing. No wonder - it's sorta like writing Avogadro's number like this: 6023 (not sure I got the right number of zeroes either). Maybe LaTeX should introduce scientific notation: \sub^3section and \sub^4section Tongue-firmly-in-cheek-ly yours, Nick
Re: [O] [ANN] ASCII back-end for new export engine
Sent from my iPhone On Jan 27, 2012, at 8:31 AM, Jambunathan K kjambunat...@gmail.com wrote: Tom The aspect I am exploring is this: Does numbering behavious occur uniformly for a *given* level? For example, are we talking of a scenario where level 3 heading in Tree-1 is numbered while level 3 heading on a Tree-2 is unnumbered. What would be the behaviour of level 4 heading in Tree-1. It seems to me, that an unnumbered heading is a mnemonic(?) for creating a paragraph (albeit a short one) that is styled very much like a heading. When one looks at a printed document, one doesn't really know what mechanism were used to achieve a particular typesetting effect and there could be multiple mechanisms by which the same effect could be achieved. LaTeX formats \section* just like \section, except it is not numbered even if \section is, it doesn't change the numbering of subsequent \sections, and it does not appear in TOC. If the above paragraph is true , I think the right thing to do would be to associate a paragraph style with *just* the heading component of an Org's outline level and leave it to the exporter what particular code it wants to emit. -- At some point a property would be useful. Back ends could deal with it differently. Tom
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
I think that your understanding of the new exporter architecture is
intimate and secure. I'm happy to follow your lead here.
I know for sure my way around the new exporter, but my LaTeX skills
aren't on par with that knowledge.
Anyway, I've pushed a commit which tries to create smart links.
Basically, links without a description pointing to an headline will be
turned into \ref{headline-label}, unless headline's numbering is off, in
which case they become \hyperref[headline-label]{headline-title}.
Nothing is changed for links providing their own description, and links
not pointing to headlines.
That should remove the need for a variable.
What do you think about it?
I think this is a very nice solution, especially the handling of links
to sections with and without numbering.
Thanks,
eric
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1
: using Org-mode version 7.8.03 (release_7.8.03.237.g674bb)
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
I think that your understanding of the new exporter architecture is
intimate and secure. I'm happy to follow your lead here.
I know for sure my way around the new exporter, but my LaTeX skills
aren't on par with that knowledge.
Anyway, I've pushed a commit which tries to create smart links.
Basically, links without a description pointing to an headline will be
turned into \ref{headline-label}, unless headline's numbering is off, in
which case they become \hyperref[headline-label]{headline-title}.
Nothing is changed for links providing their own description, and links
not pointing to headlines.
That should remove the need for a variable.
What do you think about it?
Yes, this seems to work nicely. Thanks!
You mentioned unnumbered headlines. I wonder, would it be possible (or
useful) to have the num: option take an integer (like toc:)? As I
understand it now, its value is either nil or not nil. It doesn't
manipulate \secnumdepth, but instead uses \section*, etc. In LaTeX,
section* means not only that the section isn't numbered, but also that
it doesn't go into the table of contents. There are many times when it
is useful to put unnumbered sections in the table of contents.
I've been doing #+LaTeX_HEADER: \setcounter{secnumdepth}{1}, and this
works fine. However, it would be nicer to do num: 1.
A way to set individual headings as numbered or unnumbered would be
deluxe. Perhaps this is possible, but I haven't found it?
It looks like a terrific example of the power of your parser.
No, its (albeit useless) power is revealed by the fact that \n:t is
now supported in LaTeX (and ASCII). Such a feat was close to impossible
with the previous engine.
More seriously, being recursive, the new engine can export thinks like
some *text /with nested/ emphasis* and even */important/*.
It looks like there will need to be many changes to the documentation.
And, more importantly, it is mostly made of independent parts, for
easier maintenance. For example, if I want to fix or improve links in
e-latex back-end, I know I have to start diving in
`org-e-latex-link'. That function may call other internal functions,
but, at least, I have a starting point. That will also be true for any
other back-end to come.
Regards,
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] [ANN] ASCII back-end for new export engine
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
You mentioned unnumbered headlines. I wonder, would it be possible (or
useful) to have the num: option take an integer (like toc:)? As I
understand it now, its value is either nil or not nil. It doesn't
manipulate \secnumdepth, but instead uses \section*, etc. In LaTeX,
section* means not only that the section isn't numbered, but also that
it doesn't go into the table of contents. There are many times when it
is useful to put unnumbered sections in the table of contents.
I've been doing #+LaTeX_HEADER: \setcounter{secnumdepth}{1}, and this
works fine. However, it would be nicer to do num: 1.
I have no objection to implement limited numbering in both LaTeX and
ASCII back-ends, but I'd like to know if it can be handled consistently
in every other major back-end, too. I'm CC-ing Jambunathan to know his
opinion about it.
A way to set individual headings as numbered or unnumbered would be
deluxe. Perhaps this is possible, but I haven't found it?
It would require to modify Org's syntax (how to tell which headline has
to be numbered and which has not?). It is not possible at the moment.
Regards,
--
Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
You mentioned unnumbered headlines. I wonder, would it be possible (or
useful) to have the num: option take an integer (like toc:)? As I
understand it now, its value is either nil or not nil. It doesn't
manipulate \secnumdepth, but instead uses \section*, etc. In LaTeX,
section* means not only that the section isn't numbered, but also that
it doesn't go into the table of contents. There are many times when it
is useful to put unnumbered sections in the table of contents.
I've been doing #+LaTeX_HEADER: \setcounter{secnumdepth}{1}, and this
works fine. However, it would be nicer to do num: 1.
I have no objection to implement limited numbering in both LaTeX and
ASCII back-ends, but I'd like to know if it can be handled consistently
in every other major back-end, too. I'm CC-ing Jambunathan to know his
opinion about it.
A way to set individual headings as numbered or unnumbered would be
deluxe. Perhaps this is possible, but I haven't found it?
It would require to modify Org's syntax (how to tell which headline has
to be numbered and which has not?). It is not possible at the moment.
Could this be achieved without a syntax change by adding a new LaTeX
attribute, similar to inparaenum and friends?
#+attr_latex: *
* An Unnumbered Heading
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] [ANN] ASCII back-end for new export engine
t...@tsdye.com (Thomas S. Dye) writes: Nicolas Goaziou n.goaz...@gmail.com writes: t...@tsdye.com (Thomas S. Dye) writes: A way to set individual headings as numbered or unnumbered would be deluxe. Perhaps this is possible, but I haven't found it? It would require to modify Org's syntax (how to tell which headline has to be numbered and which has not?). It is not possible at the moment. Could this be achieved without a syntax change by adding a new LaTeX attribute, similar to inparaenum and friends? #+attr_latex: * * An Unnumbered Heading No. Headlines, along with items, keywords and sections, can't have affiliated keywords. Though, they have properties. It may be done with: :PROPERTIES: :NUMBERING: nil :END: But it's still new syntax. It could also be narrowed to :LATEX_NUMBERING: nil, but I think that this feature, if implemented, should be available for every major back-end, much like num:1. Regards, -- Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes: But it's still new syntax. It could also be narrowed to :LATEX_NUMBERING: nil, but I think that this feature, if implemented, should be available for every major back-end, much like num:1. Unless I miss something, if num:* would be allowed in addition to integers, the LaTeX crowd would be pleased, no terribly new syntax would be needed and all other backends could take note to skip numbering that headline. Maybe one could throw in nil and none as an alias for *. 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] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes: t...@tsdye.com (Thomas S. Dye) writes: Nicolas Goaziou n.goaz...@gmail.com writes: t...@tsdye.com (Thomas S. Dye) writes: A way to set individual headings as numbered or unnumbered would be deluxe. Perhaps this is possible, but I haven't found it? It would require to modify Org's syntax (how to tell which headline has to be numbered and which has not?). It is not possible at the moment. Could this be achieved without a syntax change by adding a new LaTeX attribute, similar to inparaenum and friends? #+attr_latex: * * An Unnumbered Heading No. Headlines, along with items, keywords and sections, can't have affiliated keywords. Though, they have properties. It may be done with: :PROPERTIES: :NUMBERING: nil :END: But it's still new syntax. It could also be narrowed to :LATEX_NUMBERING: nil, but I think that this feature, if implemented, should be available for every major back-end, much like num:1. A properties drawer makes a lot of sense to me in this situation. It would be great if Org Mode had its own mechanisms to specify 1) the level to which sections are numbered and 2) which headlines do not appear in the table of contents. The back-ends could respond to these in an appropriate way or not at all. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] [ANN] ASCII back-end for new export engine
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
I think that your understanding of the new exporter architecture is
intimate and secure. I'm happy to follow your lead here.
I know for sure my way around the new exporter, but my LaTeX skills
aren't on par with that knowledge.
Anyway, I've pushed a commit which tries to create smart links.
Basically, links without a description pointing to an headline will be
turned into \ref{headline-label}, unless headline's numbering is off, in
which case they become \hyperref[headline-label]{headline-title}.
Nothing is changed for links providing their own description, and links
not pointing to headlines.
That should remove the need for a variable.
What do you think about it?
It looks like a terrific example of the power of your parser.
No, its (albeit useless) power is revealed by the fact that \n:t is
now supported in LaTeX (and ASCII). Such a feat was close to impossible
with the previous engine.
More seriously, being recursive, the new engine can export thinks like
some *text /with nested/ emphasis* and even */important/*.
And, more importantly, it is mostly made of independent parts, for
easier maintenance. For example, if I want to fix or improve links in
e-latex back-end, I know I have to start diving in
`org-e-latex-link'. That function may call other internal functions,
but, at least, I have a starting point. That will also be true for any
other back-end to come.
Regards,
--
Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes:
[...]
As a side note, #+label has been deprecated in favor of #+name (though
the former is immediately translated into the latter at parse time).
Sorry for hijacking this thread. But this side note is only valid for
the new exporter, correct? As it does not yield the expected result in
the current LaTeX and odt exporter (the only ones I tried).
== test.org ===
* Test name
#+caption: Test name
#+name: testname
#+begin_src R :exports results :results graphics :file foo.png
plot(1)
#+end_src
As can be seen in Figure \ref{testname}...
As can be seen in Figure [[testname]]
#+caption: Test name 2
#+label: testnametwo
#+begin_src R :exports results :results graphics :file bar.png
plot(1)
#+end_src
As can be seen in Figure \ref{testnametwo}...
As can be seen in Figure [[testnametwo]]
#+caption: Test name 3
#+label: testnamethree
#+name: testnamethree
#+begin_src R :exports results :results graphics :file bar.png
plot(1)
#+end_src
As can be seen in Figure \ref{testnamethree}...
As can be seen in Figure [[testnamethree]]
===
Best,
Andreas
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
#+CAPTION[An example photograph]: An example photograph.
#+NAME: fig:photo
for me, yields:
\caption{\label{fig:photo}An example photograph}
I was expecting:
\caption[An example photograph]{\label{fig:photo}An example
photograph}
I get the expected caption command in that case, even from a fresh emacs
-q. You may need to reload Org, or even Emacs.
Regards,
Thanks, that worked.
The file name passed to \includegraphics is formed like this:
~/path/to/graphics/file
My LaTeX doesn't recognize this as a path.
The old exporter passed a file name where the tilde was expanded:
/Users/user/path/to/graphics/file
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] [ANN] ASCII back-end for new export engine
t...@tsdye.com (Thomas S. Dye) writes: The file name passed to \includegraphics is formed like this: ~/path/to/graphics/file My LaTeX doesn't recognize this as a path. The old exporter passed a file name where the tilde was expanded: /Users/user/path/to/graphics/file It should be fixed now. Thank you. Regards, -- Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
2) If the source block is executed in buffer with (org-ctrl-c-ctrl-c), as shown above, then the exporter appears to export the in-buffer results /and/ the export-generated results (where :exports is results or both) resulting in two sets of identical results in the export. It's out of exporter's scope. I disagree. The current exporter conforms to the value of the :results header argument (e.g., silent, replace, append, etc...) when executing code blocks during export. I see no reason why the new exporter should not as well. When you ask to export some buffer, what is really parsed is a copy of the current buffer with `org-export-blocks-preprocess' applied to it. So, simply apply that function in your test buffer, and you will see what is sent to the parser. That will explain why the results appear twice. In other words, tweaking the output of `org-export-blocks-preprocess' will automatically change the outcome of the export process. Hmm, in light of this description it seems that the new export /should/ have the same behavior WRT code block execution as the current exporter. If not I wonder if a complete minimal example could be provided. Thanks, Regards, -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] ASCII back-end for new export engine
Hello, Eric Schulte eric.schu...@gmx.com writes: It's out of exporter's scope. I disagree. The current exporter conforms to the value of the :results header argument (e.g., silent, replace, append, etc...) when executing code blocks during export. I see no reason why the new exporter should not as well. The new exporter conforms to the output of `org-export-blocks-preprocess'. It doesn't pay attention to header arguments. Hmm, in light of this description it seems that the new export /should/ have the same behavior WRT code block execution as the current exporter. If not I wonder if a complete minimal example could be provided. Martyn Jago provided one in this thread. Here it is: --8---cut here---start-8--- * Test #+begin_src emacs-lisp # :exports both ;; Add two numbers (+ 2 3) #+end_src #+results: : 5 --8---cut here---end---8--- Regards, -- Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes: t...@tsdye.com (Thomas S. Dye) writes: The file name passed to \includegraphics is formed like this: ~/path/to/graphics/file My LaTeX doesn't recognize this as a path. The old exporter passed a file name where the tilde was expanded: /Users/user/path/to/graphics/file It should be fixed now. Thank you. Regards, It is fixed. Thank you! All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
A quick question and a couple of comments on the LaTeX exporter.
With the old exporter I set (setq org-export-latex-hyperref-format
\\ref{%s}) so a link to a headline would cross reference properly in
LaTeX. How do I achieve this with the new exporter? I want my text to
read, e.g., In section 1 ... So far with the new exporter, I've only
been able to get In section First headline ...
Indeed, it seems that I forgot to create that variable in the new
exporter. I don't mind adding it, but I'm not sure about where it should
apply.
At the moment, \\hyperref[%s]{%s} format string is applied to id,
custom-id, target, radio, fuzzy/target and fuzzy/headline links.
Changing all those links with just a single variable seems wrong to me.
Maybe it should replace the default value only for id, custom-id and
fuzzy/headline. And since it would only apply to headlines, it could be
renamed `org-e-latex-link-to-headline-format' or something alike.
What do you think about all of this?
My initial impression is the new exporter is extremely fast.
Unfortunately, it's only an impression. It will be slower than the
current exporter in most cases.
Oh, by the way, it reminds me that I implemented something in the LaTeX
back-end that you had asked for a while ago. If you didn't notice it,
you can try a LaTeX export on the following test buffer:
#+latex_header: \usepackage{paralist}
* Head 1
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua.
#+attr_latex: inparaenum i.
- item 1
- item 2
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua.
There is support for the following keywords: inparaenum, asparaenum,
inparaitem, asparaitem, inparadesc, asparadesc, all accepting an
optional bullet argument.
I've given the paralist facility a test run and it seems to work like a
charm. Thanks very much for augmenting the LaTeX exporter. This will
be a big help.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] [ANN] ASCII back-end for new export engine
Hello, Samuel Wales samolog...@gmail.com writes: In 22, latest git: downcase: Args out of range: image-keep-calm, 651500, 651505 match-string(1 image-keep-calm) (downcase (match-string 1 val)) (concat :macro- (downcase (match-string 1 val))) (intern (concat :macro- (downcase ...))) (plist-put nil (intern (concat :macro- ...)) (match-string 2 val)) [...] I've pushed a patch so macro detection is more careful about corner cases. Please tell me if it works for you. Also, judging by the backtrace, it seems that you are using a strange syntax for defining macros. Would you mind telling me what your #+macro: line is like, and what you do expect from it? Regards, -- Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
Hi Nicolas Nicolas Goaziou n.goaz...@gmail.com writes: Hello, I've commited an ASCII back-end for new export engine. Assuming contrib directory is in your load-path, you just need to (require 'org-export) to have both LaTeX and ASCII exporters ready to boot. You can then access to the dispatcher with M-x org-export-dispatch and test various configurations from there. [...] I've been playing with (org-export-dispatch) with regard to some simple source blocks and have a couple of observations (apologies in advance if source blocks are not fully implemented yet). The test code is: --8---cut here---start-8--- * Test #+begin_src emacs-lisp # :exports both ;; Add two numbers (+ 2 3) #+end_src #+results: : 5 --8---cut here---end---8--- 1) The commented out `# :exports both' appears to be exported as uncommented and relevant (actually, this appears to be true of the original exporter too). 2) If the source block is executed in buffer with (org-ctrl-c-ctrl-c), as shown above, then the exporter appears to export the in-buffer results /and/ the export-generated results (where :exports is results or both) resulting in two sets of identical results in the export. For the record, I much prefer your new Ascii layout, over that provided by the original exporter. HTH Best, Martyn
Re: [O] [ANN] ASCII back-end for new export engine
Hello, Martyn Jago martyn.j...@btinternet.com writes: I've been playing with (org-export-dispatch) with regard to some simple source blocks and have a couple of observations (apologies in advance if source blocks are not fully implemented yet). The test code is: * Test #+begin_src emacs-lisp # :exports both ;; Add two numbers (+ 2 3) #+end_src #+results: : 5 1) The commented out `# :exports both' appears to be exported as uncommented and relevant (actually, this appears to be true of the original exporter too). I cannot reproduce it. Anyway, see my comments below. 2) If the source block is executed in buffer with (org-ctrl-c-ctrl-c), as shown above, then the exporter appears to export the in-buffer results /and/ the export-generated results (where :exports is results or both) resulting in two sets of identical results in the export. It's out of exporter's scope. When you ask to export some buffer, what is really parsed is a copy of the current buffer with `org-export-blocks-preprocess' applied to it. So, simply apply that function in your test buffer, and you will see what is sent to the parser. That will explain why the results appear twice. In other words, tweaking the output of `org-export-blocks-preprocess' will automatically change the outcome of the export process. Regards, -- Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
On 2012-01-22, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, Also, judging by the backtrace, it seems that you are using a strange syntax for defining macros. Would you mind telling me what your #+macro: line is like, and what you do expect from it? I always export a subtree and not a file. That macro definition was elsewhere and there were no macro calls. As the old exporter didn't complain, I didn't know there was a malformed macro. Now getting an invalid search bound error, will report at some point. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com === Bigotry against people with serious diseases is still bigotry.
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
I've commited an ASCII back-end for new export engine.
Assuming contrib directory is in your load-path, you just need to
(require 'org-export) to have both LaTeX and ASCII exporters ready to
boot.
You can then access to the dispatcher with M-x org-export-dispatch and
test various configurations from there.
As a reminder, you can ask for a table of contents, list of tables and
list of listings with, respectively, #+toc: headlines, #+toc: tables
and #+toc: listings. Also, drawers[1] are exported transparently by
default.
Feedback is welcome.
Regards,
[1] properties drawers excepted: those are different elements anyway.
Aloha Nicolas,
I think there might be a problem with the regular expression for
captions on line 703 or org-e-latex.el. I have a dim understanding of
regular expressions and the various parsers, but I suspect the problem
is in this part: [^][].
At any rate, this input:
#+CAPTION: [An example photograph]{An example photograph}.
#+LABEL: fig:photo
yields this (unexpected) output:
\caption{\label{fig:photo}[An example photograph]\{An example photograph\}.}
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] [ANN] ASCII back-end for new export engine
t...@tsdye.com (Thomas S. Dye) writes:
I think there might be a problem with the regular expression for
captions on line 703 or org-e-latex.el. I have a dim understanding of
regular expressions and the various parsers, but I suspect the problem
is in this part: [^][].
At any rate, this input:
#+CAPTION: [An example photograph]{An example photograph}.
#+LABEL: fig:photo
The regexp isn't the problem here. But this all means that I'm breaking
a golden rule: never parse something already parsed.
Anyway, I have switched caption keyword to the dual keywords
category. That means is syntax is now like results keywords' which can
have an optional string (a hash in this case) before their main value.
To put it simply, caption syntax can now be:
#+caption: long name
#+caption[]: long name
#+caption[short name]: long name
much like
#+results[hash]: name
Though,
#+caption[something]:
is equivalent to no caption since the main value is mandatory.
As a side note, #+label has been deprecated in favor of #+name (though
the former is immediately translated into the latter at parse time).
Regards,
--
Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
Aloha Nicolas,
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
A quick question and a couple of comments on the LaTeX exporter.
With the old exporter I set (setq org-export-latex-hyperref-format
\\ref{%s}) so a link to a headline would cross reference properly in
LaTeX. How do I achieve this with the new exporter? I want my text to
read, e.g., In section 1 ... So far with the new exporter, I've only
been able to get In section First headline ...
Indeed, it seems that I forgot to create that variable in the new
exporter. I don't mind adding it, but I'm not sure about where it should
apply.
At the moment, \\hyperref[%s]{%s} format string is applied to id,
custom-id, target, radio, fuzzy/target and fuzzy/headline links.
Changing all those links with just a single variable seems wrong to me.
Maybe it should replace the default value only for id, custom-id and
fuzzy/headline. And since it would only apply to headlines, it could be
renamed `org-e-latex-link-to-headline-format' or something alike.
What do you think about all of this?
I think that your understanding of the new exporter architecture is
intimate and secure. I'm happy to follow your lead here.
My initial impression is the new exporter is extremely fast.
Unfortunately, it's only an impression. It will be slower than the
current exporter in most cases.
I'm sure the difference (which I haven't detected) will be outweighed by
the benefits of the new exporter.
Oh, by the way, it reminds me that I implemented something in the LaTeX
back-end that you had asked for a while ago. If you didn't notice it,
you can try a LaTeX export on the following test buffer:
#+latex_header: \usepackage{paralist}
* Head 1
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua.
#+attr_latex: inparaenum i.
- item 1
- item 2
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua.
There is support for the following keywords: inparaenum, asparaenum,
inparaitem, asparaitem, inparadesc, asparadesc, all accepting an
optional bullet argument.
I hadn't noticed this yet. It looks like a terrific example of the
power of your parser. Many thanks for this functionality.
It will take me a while to understand the practical implications of the
level to which you have abstracted Org mode, but I look forward to the
challenge.
I also look forward to the pleasure of using the new LaTeX exporter.
Thanks again for your good work.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] [ANN] ASCII back-end for new export engine
Aloha Nicolas,
Nicolas Goaziou n.goaz...@gmail.com writes:
t...@tsdye.com (Thomas S. Dye) writes:
I think there might be a problem with the regular expression for
captions on line 703 or org-e-latex.el. I have a dim understanding of
regular expressions and the various parsers, but I suspect the problem
is in this part: [^][].
At any rate, this input:
#+CAPTION: [An example photograph]{An example photograph}.
#+LABEL: fig:photo
The regexp isn't the problem here. But this all means that I'm breaking
a golden rule: never parse something already parsed.
Anyway, I have switched caption keyword to the dual keywords
category. That means is syntax is now like results keywords' which can
have an optional string (a hash in this case) before their main value.
To put it simply, caption syntax can now be:
#+caption: long name
#+caption[]: long name
#+caption[short name]: long name
much like
#+results[hash]: name
Though,
#+caption[something]:
is equivalent to no caption since the main value is mandatory.
This input:
#+CAPTION[An example photograph]: An example photograph.
#+NAME: fig:photo
for me, yields:
\caption{\label{fig:photo}An example photograph}
I was expecting:
\caption[An example photograph]{\label{fig:photo}An example photograph}
As a side note, #+label has been deprecated in favor of #+name (though
the former is immediately translated into the latter at parse time).
I agree it is a good idea to abstract this from the LaTeX backend.
Regards,
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] [ANN] ASCII back-end for new export engine
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
#+CAPTION[An example photograph]: An example photograph.
#+NAME: fig:photo
for me, yields:
\caption{\label{fig:photo}An example photograph}
I was expecting:
\caption[An example photograph]{\label{fig:photo}An example
photograph}
I get the expected caption command in that case, even from a fresh emacs
-q. You may need to reload Org, or even Emacs.
Regards,
--
Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
Hi Nicolas, On 2012-01-21, Nicolas Goaziou n.goaz...@gmail.com wrote: You can then access to the dispatcher with M-x org-export-dispatch and test various configurations from there. There is a problem with the dispatcher that prevents me from testing. It exceeds 78 columns, but more importantly, it does not allow scrolling. My screen height is too small. For an example of a menu that is accessible, please see Magit's, which allow scrolling. (I realize this has nothing to do with your exporter.) I can't tell if c-c c-e A is yours or the old one. Assuming it's yours, I am getting a lot of: ORG-BLOCKQUOTE-START type things instead of indentation. I like the way links are glossed at the end of each section instead of the end of the whole subtree. That is best. I'd like it if the link were indented by 2 spaces underneath the label, so it doesn't exceed the column. As a reminder, you can ask for a table of contents, list of tables and list of listings with, respectively, #+toc: headlines, #+toc: tables and #+toc: listings. Also, drawers[1] are exported transparently by default. Great feature. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com === Bigotry against people with serious diseases is still bigotry.
Re: [O] [ANN] ASCII back-end for new export engine
Two feature requests: 1) optionally squeeze blank lines 2) optionally unfill paragraphs -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com === Bigotry against people with serious diseases is still bigotry.
Re: [O] [ANN] ASCII back-end for new export engine
Hello, Samuel Wales samolog...@gmail.com writes: There is a problem with the dispatcher that prevents me from testing. It exceeds 78 columns, [...] No. The standard UI doesn't even exceed 60 columns. You must be using something else. I can't tell if c-c c-e A is yours or the old one. Assuming it's yours [...] It's the old one. There is no binding to access my dispatcher: just use M-x org-export-dispatch. Regards, -- Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
In 22, latest git: downcase: Args out of range: image-keep-calm, 651500, 651505 match-string(1 image-keep-calm) (downcase (match-string 1 val)) (concat :macro- (downcase (match-string 1 val))) (intern (concat :macro- (downcase ...))) (plist-put nil (intern (concat :macro- ...)) (match-string 2 val)) (cond ((string= key SETUP_FILE) (let ... ...)) ((string= key OPTIONS) (org-export-parse-option-keyword val backend)) ((string= key MACRO) (string-match ^\\([-a-zA-Z0-9_]+\\)[ ]+\\(.*?[ ]*$\\) val) (plist-put nil ... ...))) (org-combine-plists (cond (... ...) (... ...) (... ... ...)) plist) (setq plist (org-combine-plists (cond ... ... ...) plist)) (let ((key ...) (val ...)) (setq plist (org-combine-plists ... plist))) (while (string-match special-re buffer-string start) (setq start (match-end 0)) (let (... ...) (setq plist ...))) (let ((start 0) (special-re ...)) (while (string-match special-re buffer-string start) (setq start ...) (let ... ...))) (let ((case-fold-search t) plist) (let (... ...) (while ... ... ...)) (let* (... ... ... ...) (while ... ... ...) (mapc ... org-element-parsed-keywords)) plist) org-export-get-inbuffer-options(#(#-*- coding: utf-8 -*- ... -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com === Bigotry against people with serious diseases is still bigotry.
