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. -- Nicolas Goaziou
Hi Nicolas, On 2012-01-21, Nicolas Goaziou <n.goaziou@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.
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.
Hello, Samuel Wales <samologist@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
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.
Hello,
Samuel Wales <samologist@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
Hi Nicolas
Nicolas Goaziou <n.goaziou@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
Hello, Martyn Jago <martyn.jago@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
Nicolas Goaziou <n.goaziou@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, 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 ..." I really like #+toc: headlines, etc. They make organizing the front matter easy and transparent. My initial impression is the new exporter is extremely fast. Thanks very much for all your work on this. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
On 2012-01-22, Nicolas Goaziou <n.goaziou@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.
Hi
Nicolas Goaziou <n.goaziou@gmail.com> writes:
[...]
>> 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.
Ah yes, I see - thanks for the clear explanation.
Best, Martyn
Hello, tsd@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: --8<---------------cut here---------------start------------->8--- #+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. --8<---------------cut here---------------end--------------->8--- There is support for the following keywords: inparaenum, asparaenum, inparaitem, asparaitem, inparadesc, asparadesc, all accepting an optional bullet argument. Regards, -- Nicolas Goaziou
Nicolas Goaziou <n.goaziou@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
tsd@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
Aloha Nicolas, Nicolas Goaziou <n.goaziou@gmail.com> writes: > Hello, > > tsd@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
Aloha Nicolas, Nicolas Goaziou <n.goaziou@gmail.com> writes: > tsd@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
Hello,
tsd@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
Nicolas Goaziou <n.goaziou@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
Nicolas Goaziou <n.goaziou@gmail.com> writes: > Hello, > > tsd@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
tsd@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
>> 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/
Hello, Eric Schulte <eric.schulte@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
Nicolas Goaziou <n.goaziou@gmail.com> writes: > tsd@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
Nicolas Goaziou <n.goaziou@gmail.com> writes: > Hello, > > tsd@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
Hello, tsd@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
Hi Nicolas, hello everybody, I am extremely excited about this new export engine; it seems to fill a need I have felt for quite a while now. What I need it for is the following: For the last couple of years, I have used org-mode more and more for working with and translating texts from classical Chinese. Over time, some special conventions have crept in, like the fact that I like (for the draft translation) to work in a way that has a short chunk of Chinese text on the left and, separated by a <tab> character, the translation of that piece following on the same line (there are other special conventions like specialized drawers etc., but I don't need to discuss these here now.) While this is setup is extremely pleasant to work with, at some point I need to separate these two parts in separate texts; the stuff to the left of the <tab> has to go into one file, the stuff to the right to some other file, while at the same time merging the chunks of texts into paragraphs. Now for quite some while if have thought about how to automate that, but until now, I have usually done it by hand with a couple of regex search-and-replace. Now, with the new export engine, it looks like all I would need to do would be to tweak the way paragraphs are handled, while leaving the rest intact, some kind of org to org transform that simply tweaks one single aspect of the text. However, I am a bit baffled on where to start with this. I would be glad if you or somebody else could give me some pointers at how to tackle this problem. (And please be kind, since my elisp fu is pretty insignificant:-( ) All the best, Christian Wittern, Kyoto
Nicolas Goaziou <n.goaziou@gmail.com> writes:
> Hello,
>
> tsd@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)
Nicolas Goaziou <n.goaziou@gmail.com> writes: > Hello, > > tsd@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
Hello, tsd@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
Nicolas Goaziou <n.goaziou@gmail.com> writes: > Hello, > > tsd@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
tsd@tsdye.com (Thomas S. Dye) writes: > Nicolas Goaziou <n.goaziou@gmail.com> writes: > >> tsd@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
Nicolas Goaziou <n.goaziou@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
Nicolas Goaziou <n.goaziou@gmail.com> writes: > tsd@tsdye.com (Thomas S. Dye) writes: > >> Nicolas Goaziou <n.goaziou@gmail.com> writes: >> >>> tsd@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
> 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,
Hello,
Achim Gratz <Stromeko@nexgo.de> writes:
> Nicolas Goaziou <n.goaziou@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
On Fri, Jan 27, 2012 at 01:58:26PM +0100, Nicolas Goaziou wrote:
> Achim Gratz <Stromeko@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
Hello,
Christian Wittern <cwittern@gmail.com> writes:
> For the last couple of years, I have used org-mode more and more for
> working with and translating texts from classical Chinese. Over time,
> some special conventions have crept in, like the fact that I like (for
> the draft translation) to work in a way that has a short chunk of
> Chinese text on the left and, separated by a <tab> character, the
> translation of that piece following on the same line (there are other
> special conventions like specialized drawers etc., but I don't need to
> discuss these here now.)
>
> While this is setup is extremely pleasant to work with, at some point
> I need to separate these two parts in separate texts; the stuff to the
> left of the <tab> has to go into one file, the stuff to the right to
> some other file, while at the same time merging the chunks of texts
> into paragraphs. Now for quite some while if have thought about how
> to automate that, but until now, I have usually done it by hand with
> a couple of regex search-and-replace.
>
> Now, with the new export engine, it looks like all I would need to do
> would be to tweak the way paragraphs are handled, while leaving the
> rest intact, some kind of org to org transform that simply tweaks one
> single aspect of the text. However, I am a bit baffled on where to
> start with this. I would be glad if you or somebody else could give
> me some pointers at how to tackle this problem. (And please be kind,
> since my elisp fu is pretty insignificant:-( )
While I understand the shape of your input, I fail to see what you
output should you look like. For example, given the following paragraph,
--8<---------------cut here---------------start------------->8---
text A text A'
line 2 line 2 bis
A line with *emphasis* A traduced line with *emphasis*
--8<---------------cut here---------------end--------------->8---
what exactly do you want to obtain ?
Regards,
--
Nicolas Goaziou
Nicolas I will let Christian answer for himself. > [Nicolas] > While I understand the shape of your input, I fail to see what you > output should you look like. For example, given the following paragraph, > > text A text A' > line 2 line 2 bis > A line with *emphasis* A traduced line with *emphasis* > >> [Christian] >> I need to separate these two parts in separate texts; the stuff to the >> left of the <tab> has to go into one file, the stuff to the right to >> some other file, >> while at the same time merging the chunks of texts >> into paragraphs. If I interpret the above lines, I imagine his request more along the following lines: text A text A' line 2 line 2 My name is Jambunathan. I live Mon nom est Jambunathan. Je vis in India. .................... en India....................... He wants the "English column" to be collected in to an English file and the "French column" to be collected in to a French file. It is possible that "English column" constitutes a poem and the "French column" is a line-by-line translation of the column to the left. In some sense, he wants to tangle the "English column", let's say as verse_en.org and "French column" to verse_fr.org and later include them as a table cell or a column of a 2-C section. Notionally something like: |------------------------+-----------------------| |#+INCLUDE: verse_en.org |#+INCLUDE: verse_fr.org| |------------------------+-----------------------| Put another way, collect Column-X in to Paragraph-X and do whatver. ps: French translation is courtesy google. --
Hello,
Rick Frankel <rick@rickster.com> writes:
> On Fri, Jan 27, 2012 at 01:58:26PM +0100, Nicolas Goaziou wrote:
>> Achim Gratz <Stromeko@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
Hello, Jambunathan K <kjambunathan@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
Hi all,
Jambunathan K wrote:
> Nicolas
>
> I will let Christian answer for himself.
>
>> [Nicolas]
>> While I understand the shape of your input, I fail to see what you
>> output should you look like. For example, given the following paragraph,
>>
>> text A text A'
>> line 2 line 2 bis
>> A line with *emphasis* A traduced line with *emphasis*
>>
>
>>> [Christian]
>>> I need to separate these two parts in separate texts; the stuff to the
>>> left of the <tab> has to go into one file, the stuff to the right to
>>> some other file,
>
>>> while at the same time merging the chunks of texts
>>> into paragraphs.
>
> If I interpret the above lines, I imagine his request more along the
> following lines:
>
> text A text A'
> line 2 line 2
>
> My name is Jambunathan. I live Mon nom est Jambunathan. Je vis
> in India. .................... en India.......................
>
> He wants the "English column" to be collected in to an English file and
> the "French column" to be collected in to a French file.
>
> It is possible that "English column" constitutes a poem and the "French
> column" is a line-by-line translation of the column to the left.
>
> In some sense, he wants to tangle the "English column", let's say as
> verse_en.org and "French column" to verse_fr.org and later include them
> as a table cell or a column of a 2-C section.
>
> Notionally something like:
> |------------------------+-----------------------|
> |#+INCLUDE: verse_en.org |#+INCLUDE: verse_fr.org|
> |------------------------+-----------------------|
>
> Put another way, collect Column-X in to Paragraph-X and do whatver.
>
> ps: French translation is courtesy google.
Just a side comment: isn't easier to work in 2 different files or buffers
(eventually, within the same file) and use some sort of "parallel"
follow-mode? I thought such a thing existed, but can't find it back right
now.
Anyway, it would be quite easy to implement: it's more or less implementing
C-v/M-v so that it's done in two parallel buffers at the same time, instead of
just in one!?
Best regards,
Seb
--
Sebastien Vauban
Hi all,
Nicolas Goaziou <n.goaziou@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
Nicolas Goaziou <n.goaziou@gmail.com> writes: > Hello, > > Jambunathan K <kjambunathan@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
Nicolas Goaziou <n.goaziou@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
Nicolas Goaziou <n.goaziou@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 ...) (inner-re ...) (type ...) (headers ...) (balanced 1) (preserve-indent ...) match-end) (while (and ... ...) (if ... ... ...)) (when (not ...) (error "unbalanced begin/end_%s blocks with %S" type ...)) (setq match-end (copy-marker ...)) (unless preserve-indent (setq body ...)) (unless (memq type types) (setq types ...)) (save-match-data (interblock start match-start)) (when (setq func ...) (let ... ...)) (set-marker match-start nil) (set-marker body-start nil) (set-marker match-end nil)) (while (re-search-forward beg-re nil t) (let* (... ... ... ... ... ... ... ... match-end) (while ... ...) (when ... ...) (setq match-end ...) (unless preserve-indent ...) (unless ... ...) (save-match-data ...) (when ... ...) (set-marker match-start nil) (set-marker body-start nil) (set-marker match-end nil)) (setq start (point))) (let ((beg-re "^\\([ ]*\\)#\\+begin_\\(\\S-+\\)[ ]*\\(.*\\)?[ \n]")) (while (re-search-forward beg-re nil t) (let* ... ... ... ... ... ... ... ... ... ... ...) (setq start ...))) (progn (fset (quote interblock) (function* ...)) (goto-char (point-min)) (setq start (point)) (let (...) (while ... ... ...)) (interblock start (point-max)) (run-hooks (quote org-export-blocks-postblock-hook))) (unwind-protect (progn (fset ... ...) (goto-char ...) (setq start ...) (let ... ...) (interblock start ...) (run-hooks ...)) (if --cl-letf-bound-- (fset ... --cl-letf-save--) (fmakunbound ...))) (let* ((--cl-letf-bound-- ...) (--cl-letf-save-- ...)) (unwind-protect (progn ... ... ... ... ... ...) (if --cl-letf-bound-- ... ...))) (letf ((... ...)) (goto-char (point-min)) (setq start (point)) (let (...) (while ... ... ...)) (interblock start (point-max)) (run-hooks (quote org-export-blocks-postblock-hook))) (letf* ((... ...)) (goto-char (point-min)) (setq start (point)) (let (...) (while ... ... ...)) (interblock start (point-max)) (run-hooks (quote org-export-blocks-postblock-hook))) (flet ((interblock ... ...)) (goto-char (point-min)) (setq start (point)) (let (...) (while ... ... ...)) (interblock start (point-max)) (run-hooks (quote org-export-blocks-postblock-hook))) (let ((case-fold-search t) (types ...) matched indentation type func start end body headers preserve-indent progress-marker) (flet (...) (goto-char ...) (setq start ...) (let ... ...) (interblock start ...) (run-hooks ...))) (save-window-excursion (let (... ... matched indentation type func start end body headers preserve-indent progress-marker) (flet ... ... ... ... ... ...))) org-export-blocks-preprocess() (progn (org-export-blocks-preprocess) (org-element-parse-buffer nil visible-only)) (let ((buffer-invisibility-spec nil)) (org-clone-local-variables --original-buffer "^\\(org-\\|orgtbl-\\|major-mode$\\|outline-regexp$\\)") (insert --buffer-string) (mapc (lambda ... ...) --overlays) (goto-char (point-min)) (progn (org-export-blocks-preprocess) (org-element-parse-buffer nil visible-only))) (progn (let (...) (org-clone-local-variables --original-buffer "^\\(org-\\|orgtbl-\\|major-mode$\\|outline-regexp$\\)") (insert --buffer-string) (mapc ... --overlays) (goto-char ...) (progn ... ...))) (unwind-protect (progn (let ... ... ... ... ... ...)) (and (buffer-name temp-buffer) (kill-buffer temp-buffer))) (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn ...) (and ... ...))) (with-current-buffer temp-buffer (unwind-protect (progn ...) (and ... ...))) (let ((temp-buffer ...)) (with-current-buffer temp-buffer (unwind-protect ... ...))) (with-temp-buffer (let (...) (org-clone-local-variables --original-buffer "^\\(org-\\|orgtbl-\\|major-mode$\\|outline-regexp$\\)") (insert --buffer-string) (mapc ... --overlays) (goto-char ...) (progn ... ...))) (let ((--original-buffer #<buffer latex-export.org>) (--offset 0) (--buffer-string #("#+TITLE: latex-export.org\n#+AUTHOR: Thomas Dye\n#+EMAIL: tsd@tsdye.com\n#+DATE: 2012-01-21 Sat\n#+DESCRIPTION:\n#+KEYWORDS:\n#+LANGUAGE: en\n#+OPTIONS: H:3 num:1 toc:nil \\n:nil @:t ::t |:t ^:t -:t f:t *:t <:t\n#+OPTIONS: TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc\n#+INFOJS_OPT: view:nil toc:nil ltoc:t mouse:underline buttons:0 path:http://orgmode.org/org-info.js\n#+EXPORT_SELECT_TAGS: export\n#+EXPORT_EXCLUDE_TAGS: noexport\n#+LINK_UP: \n#+LINK_HOME: \n#+XSLT:\n#+LaTeX_HEADER: \\usepackage{paralist}\n\n#+BEGIN_abstract\nThis is an abstract.\n#+END_abstract\n\n#+toc: headlines\n#+toc: tables\n#+toc: figures\n\n* First heading\n :PROPERTIES:\n :ID: A0EF6F8D-DC06-4AA7-8090-401B90BDACF0\n :END:\n\nNote the use of =#+toc: headlines= together with =#+OPTIONS: toc:nil=\nto produce a table of contents without a =\\vspace*= following.\n\nIn Section [[First heading]] we will set up Section [[Table heading]].\n\n** First sub heading\nThis is some text after the subheading.\n\n* Table heading\nThis is a test table. Note that the new exporter faithfully\nreproduces the behavior of the old exporter. Look into how it might\nbe modified to produce tables with the booktabs package. \n\n#+CAPTION: A test table\n#+LABEL: tab:test\n| One | Two |\n|-----+-----|\n| 1 | 2 |\n\n* Figure heading\n\nThis is an example of adding a figure.\n\n#+CAPTION[An example photograph]: An example photograph.\n#+NAME: fig:photo\n[[file:~/Public/projects/308/photo/IMG_0072_cropped.jpg]]\n\n* Reference heading\n\nThis is a reference \n\n* List heading\nThis is an in-paragraph enumerated list:\n #+attr_latex: inparaenum (i)\n - one;\n - two; and\n - three.\n\nThis should be a sentence in a new paragraph.\n* Listing heading\nThis is a listing.\n\n#+BEGIN_SRC python :results output\nprint \"hello world\"\n#+END_SRC\n\n#+RESULTS:\n: hello world\n\n" 0 8 ... 8 13 ... 13 29 ... 29 30 ... 30 39 ... 39 43 ... 43 53 ... 53 54 ... 54 62 ... 62 67 ... 67 80 ... 80 81 ... 81 88 ... 88 94 ... 94 108 ... 108 109 ... 109 123 ... 123 124 ... 124 135 ... 135 136 ... 136 151 ... 151 152 ... 152 221 ... 221 222 ... 222 294 ... 294 295 ... 295 364 ... 364 393 ... 393 394 ... 394 395 ... 395 423 ... 423 424 ... 424 455 ... 455 456 ... 456 469 ... 469 470 ... 470 483 ... 483 484 ... 484 491 ... 491 492 ... 492 529 ... 529 530 ... 530 531 ... 531 547 ... 547 548 ... 548 568 ... 568 569 ... 569 583 ... 583 584 ... 584 585 ... 585 601 ... 601 602 ... 602 615 ... 615 616 ... 616 630 ... 630 631 ... 631 632 ... 632 634 ... 634 647 ... 647 648 ... 648 662 ... 662 665 ... 665 669 ... 669 676 ... 676 712 ... 712 713 ... 713 720 ... 720 737 ... 737 738 ... 738 756 ... 756 757 ... 757 770 ... 770 771 ... 771 791 ... 791 832 ... 832 833 ... 833 843 ... 843 844 ... 844 867 ... 867 868 ... 868 869 ... 869 881 ... 881 882 ... 882 883 ... 883 884 ... 884 908 ... 908 909 ... 909 910 ... 910 922 ... 922 923 ... 923 924 ... 924 925 ... 925 928 ... 928 929 ... 929 931 ... 931 948 ... 948 990 ... 990 992 ... 992 1005 ... 1005 1067 ... 1067 1279 ... 1279 1280 ... 1280 1282 ... 1282 1296 ... 1296 1338 ... 1338 1394 ... 1394 1395 ... 1395 1412 ... 1412 1413 ... 1413 1414 ... 1414 1415 ... 1415 1467 ... 1467 1468 ... 1468 1469 ... 1469 1470 ... 1470 1472 ... 1472 1474 ... 1474 1491 ... 1491 1515 ... 1515 1517 ... 1517 1529 ... 1529 1530 ... 1530 1571 ... 1571 1601 ... 1601 1682 ... 1682 1684 ... 1684 1699 ... 1699 1700 ... 1700 1719 ... 1719 1720 ... 1720 1754 ... 1754 1755 ... 1755 1756 ... 1756 1760 ... 1760 1761 ... 1761 1762 ... 1762 1774 ... 1774 1775 ... 1775 1784 ... 1784 1785 ... 1785 1786 ... 1786 1796 ... 1796 1797 ... 1797 1799 ... 1799 1811 ... 1811 1812 ...)) (--overlays ...)) (with-temp-buffer (let ... ... ... ... ... ...))) (org-export-with-current-buffer-copy (org-export-blocks-preprocess) (org-element-parse-buffer nil visible-only)) (org-export-filter-apply-functions (plist-get info :filter-parse-tree) (org-export-with-current-buffer-copy (org-export-blocks-preprocess) (org-element-parse-buffer nil visible-only)) backend) (progn (when subtreep (let ... ...)) (org-export-filter-apply-functions (plist-get info :filter-parse-tree) (org-export-with-current-buffer-copy ... ...) backend)) (let* ((info ...) (raw-data ...)) (setq info (org-combine-plists info ...)) (let* (... ... ...) (when org-export-copy-to-kill-ring ...) output)) (save-restriction (when (org-region-active-p) (narrow-to-region ... ...) (goto-char ...)) (when (and subtreep ...) (org-with-limited-levels ...)) (let* (... ...) (setq info ...) (let* ... ... output))) (save-excursion (save-restriction (when ... ... ...) (when ... ...) (let* ... ... ...))) org-export-as(e-latex nil nil nil nil) (let ((out ...) (buffer ...)) (with-current-buffer buffer (erase-buffer) (insert out) (goto-char ...)) buffer) org-export-to-buffer(e-latex "*Org E-LaTeX Export*" nil nil nil) (let ((outbuf ...)) (with-current-buffer outbuf (latex-mode)) (when org-export-show-temporary-export-buffer (switch-to-buffer-other-window outbuf))) (cond ((member* --cl-var-- ...) (let ... ... ...)) ((member* --cl-var-- ...) (org-e-ascii-export-to-ascii ... ... ... ...)) ((eql --cl-var-- ...) (let ... ... ...)) ((eql --cl-var-- ...) (org-e-latex-export-to-latex ... ... ...)) ((eql --cl-var-- ...) (org-e-latex-export-to-pdf ... ... ...)) ((eql --cl-var-- ...) (org-open-file ...)) (t (error "No command associated with key %s" ...))) (let ((--cl-var-- ...)) (cond (... ...) (... ...) (... ...) (... ...) (... ...) (... ...) (t ...))) (case (if (< raw-key 27) (+ raw-key 96) raw-key) ((65 78 85) (let ... ... ...)) ((97 110 117) (org-e-ascii-export-to-ascii ... ... ... ...)) (76 (let ... ... ...)) (108 (org-e-latex-export-to-latex ... ... ...)) (112 (org-e-latex-export-to-pdf ... ... ...)) (100 (org-open-file ...)) (t (error "No command associated with key %s" ...))) (let* ((input ...) (raw-key ...) (scope ...)) (case (if ... ... raw-key) (... ...) (... ...) (76 ...) (108 ...) (112 ...) (100 ...) (t ...))) org-export-dispatch() call-interactively(org-export-dispatch t nil) execute-extended-command(nil) call-interactively(execute-extended-command nil nil) All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Nicolas Goaziou <n.goaziou@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).
--
Jambunathan K <kjambunathan@gmail.com> writes: > Nicolas Goaziou <n.goaziou@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
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. --
Jambunathan K <kjambunathan@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
Sent from my iPhone On Jan 27, 2012, at 9:21 AM, Achim Gratz <Stromeko@nexgo.de> wrote: > Jambunathan K <kjambunathan@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 > >
Thomas S. Dye <tsd@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:
602300000000000000000000 (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
Sent from my iPhone On Jan 27, 2012, at 8:31 AM, Jambunathan K <kjambunathan@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
Hi, Jambunathan and Nicolas, On 2012-01-27 22:47, Jambunathan K wrote: > Nicolas > > I will let Christian answer for himself. Thanks Jambunathan, you are not only an excellent coder, but also an expert mind reader:-) What you describe is exactly what I want to achieve. > text A text A' > line 2 line 2 > > My name is Jambunathan. I live Mon nom est Jambunathan. Je vis > in India. .................... en India....................... > > He wants the "English column" to be collected in to an English file and > the "French column" to be collected in to a French file. > In some sense, he wants to tangle the "English column", let's say as > verse_en.org and "French column" to verse_fr.org Exactly. The reason for wanting to do this is that the above is my setup for translating, but in some cases the publication will have only the translation, for such cases, I want to extract just the translation. This should then produce a new org file, that simple has either everything before the tab (the original) or everything after the tab (the translation), while leaving all lines that do not contain a <tab> character as they are. I assume this would be an easy task with the new exporter -- but still a bit at loss on where to start... All the best, Christian -- Christian Wittern, Kyoto
Hi Sebastian,
On 2012-01-27 23:03, Sebastien Vauban wrote:
> Just a side comment: isn't easier to work in 2 different files or buffers
> (eventually, within the same file) and use some sort of "parallel"
> follow-mode? I thought such a thing existed, but can't find it back right
> now. Anyway, it would be quite easy to implement: it's more or less
> implementing C-v/M-v so that it's done in two parallel buffers at the same
> time, instead of just in one!? Best regards, Seb
What you describe is Two-Column mode, and this was suggested by Jambunathan
before. I did try this alley, but for me org-mode works better. One of the
reasons for this is, that there are some structural aspects that are common
to both files. Another reason is that I want to be able grep through the
files and be able to see matching lines in both languages -- this helps me
ensure a consistent translation. So the current setup is really nice for me
for doing the work, but now I need to construct the pipeline for
publication. As Jambunathan put it, this is really a problem of tangling
the output.
BTW, I think the general exporter should also be able to to a org-mode to
org-mode conversion. This would provide a general framework to
systematically correct little problems in files. I guess here it shows that
I am coming from the XML world, where a conversion from one XML file to
another XML file with slight alterations of some aspects is a very common
pattern.
All the best,
Christian
--
Christian Wittern, Kyoto
On Sat, Jan 28 2012, Christian Wittern wrote: > Hi, Jambunathan and Nicolas, > > On 2012-01-27 22:47, Jambunathan K wrote: >> Nicolas >> >> I will let Christian answer for himself. > Thanks Jambunathan, you are not only an excellent coder, but also an > expert mind reader:-) > What you describe is exactly what I want to achieve. > >> text A text A' >> line 2 line 2 >> >> My name is Jambunathan. I live Mon nom est Jambunathan. Je vis >> in India. .................... en India....................... >> >> He wants the "English column" to be collected in to an English file and >> the "French column" to be collected in to a French file. > >> In some sense, he wants to tangle the "English column", let's say as >> verse_en.org and "French column" to verse_fr.org > > Exactly. The reason for wanting to do this is that the above is my > setup for translating, but in some cases the publication will have > only the translation, for such cases, I want to extract just the > translation. This should then produce a new org file, that simple has > either everything before the tab (the original) or everything after > the tab (the translation), while leaving all lines that do not contain > a <tab> character as they are. I also use org mode for translating (from modern Chinese, coincidentally), and as Sebastien mentioned, I find it easiest to split a single file into two subtrees, source and target, then split the window so that I've got the two subtrees side-by-side. You could use follow-mode at this point, though I don't. Selective export then becomes trivial, though you'd have a harder time getting it into a two-column table. It's always annoying to ask how to do something and then be told to do something else, so I'm not going to do that, but I do think you might encounter fewer difficulties making the above setup do what you want, rather than the TAB arrangement. Of course, classical Chinese (particularly poetry) lends itself better to doing discrete chunks one at a time… modern prose would be a nightmare with TABs, though. I've toyed with a home-made follow-type setup, where the two subtrees are displayed in split windows as above, and the sub-headings of the two subtrees have properties pointing to the IDs of their corresponding sub-heading (ie, source chapters are linked to target chapters and vice versa). I got about halfway to implementing something where corresponding paragraphs are highlighted in the non-active window, before getting distracted by an actual translation deadline. (The pie-in-the-sky next step would be to use org-mode to maintain a TMX-formatted translation database (http://en.wikipedia.org/wiki/Translation_Memory_eXchange), and allow for automatic insertion of translations of known terms, a library I expect to have written some time before the obsoletion of Emacs itself.) Anyway, I'm not sure I had much of a point, but if there are any other translators using org-mode, it might be interesting to discuss how we could make it more useful, perhaps in a separate thread. Eric -- Gnu Emacs 24.0.92.1 (i686-pc-linux-gnu, GTK+ Version 2.24.9) of 2012-01-26 on pellet Org-mode version 7.8.03 (release_7.8.03.249.g742c4e9)
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.
Hello, Samuel Wales <samologist@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
On 2012-01-28, Nicolas Goaziou <n.goaziou@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
Samuel Wales <samologist@gmail.com> writes: > On 2012-01-28, Nicolas Goaziou <n.goaziou@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
On 2012-01-28, Nicolas Goaziou <n.goaziou@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.
Samuel Wales <samologist@gmail.com> writes: > On 2012-01-28, Nicolas Goaziou <n.goaziou@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
Hello,
Christian Wittern <cwittern@gmail.com> writes:
> Exactly. The reason for wanting to do this is that the above is my
> setup for translating, but in some cases the publication will have
> only the translation, for such cases, I want to extract just the
> translation. This should then produce a new org file, that simple has
> either everything before the tab (the original) or everything after
> the tab (the translation), while leaving all lines that do not contain
> a <tab> character as they are.
>
> I assume this would be an easy task with the new exporter -- but still
> a bit at loss on where to start...
From here, I'll assume that:
1. you only split paragraphs (not tables, or lists, and so on);
2. your back-end is called `translator';
3. you never use tabs in objects (links, latex-fragments).
The first step would be to initialize a property that will allow to
control the side of the paragraph being exported:
#+begin_src emacs-lisp
(defconst org-translator-option-alist
'((:translator-side nil nil left)))
#+end_src
Another step will be to create the basis of `translator', that is an Org
to Org back-end.
1. For each ELEMENT in `org-element-all-elements', you need to created
an appropriate transcoder in the following shape:
#+begin_src emacs-lisp
(defun org-translator-ELEMENT (element contents info)
"Convert ELEMENT from Org to Org syntax."
(org-element-ELEMENT-interpreter element contents))
#+end_src
This can be done quickly with a macro or some elisp.
2. You should do the same with each OBJECT in
`org-element-all-successors':
#+begin_src emacs-lisp
(defun org-translator-OBJECT (object contents info)
"Convert OBJECT from Org to Org syntax."
(org-element-OBJECT-interpreter object contents))
#+end_src
Though, you will need to duplicate and rename some functions
created, as some objects share the same successor. Thus:
- `org-translator-sub/superscript' will be split into
`org-translator-subscript' and `org-translator-superscript';
- `org-translator-text-markup' will be split into
`org-translator-emphasis' and `org-translator-verbatim';
- `org-translator-latex-or-entity' will be split into
`org-translator-entity' and `org-translator-latex-fragment'.
3. If all went well, you now have an impressive Org to Org converter.
You can even test it with:
#+begin_src emacs-lisp
(switch-to-buffer (org-export-to-buffer 'translator "*Translation*"))
#+end_src
Obviously, there is not much to see.
Now, we're going to redefine `org-translator-paragraph' to properly
ignore one language or the other, depending on `:translator-side' value.
#+begin_src emacs-lisp
(defun org-translator-paragraph (paragraph contents info)
"Convert PARAGRAPH to Org, ignoring one language.
Language kept is determined by `:translator-side' value."
(let ((leftp (eq (plist-get info :translator-side) 'left)))
(replace-regexp-in-string
(if leftp "\t+.*$" "^.*\t+") "" contents)))
#+end_src
Eventually, you need to define two commands to respectively keep left
and right parts and save the output in an appropriate file.
#+begin_src emacs-lisp
(defun org-translator-left (file)
"Save buffer in FILE, with only left language in paragraphs."
(interactive "FFile (left language): ")
(org-export-to-file 'translator file))
(defun org-translator-right (file)
"Save buffer in FILE, with only right language in paragraphs."
(interactive "FFile (right language): ")
(org-export-to-file
'translator file nil nil nil '(:translator-side right)))
#+end_src
This is completely untested.
Regards,
--
Nicolas Goaziou
Nicolas Goaziou <n.goaziou@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
Nicolas Goaziou <n.goaziou@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.
--
Hello,
tsd@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
Hi Nicolas, Thank you very much for taking the time for such a detailed recipe. Today I finally found time to go over it and try to implement my transformer. It turned out to be really easy to get going, but in the end, I hit a roadblock. On 2012-01-29 18:07, Nicolas Goaziou wrote: > > 3. If all went well, you now have an impressive Org to Org converter. > You can even test it with: > > #+begin_src emacs-lisp > (switch-to-buffer (org-export-to-buffer 'translator "*Translation*")) > #+end_src > > Obviously, there is not much to see. It worked wonderful until here. > > Now, we're going to redefine `org-translator-paragraph' to properly > ignore one language or the other, depending on `:translator-side' value. > > #+begin_src emacs-lisp > (defun org-translator-paragraph (paragraph contents info) > "Convert PARAGRAPH to Org, ignoring one language. > Language kept is determined by `:translator-side' value." > (let ((leftp (eq (plist-get info :translator-side) 'left))) > (replace-regexp-in-string > (if leftp "\t+.*$" "^.*\t+") "" contents))) > #+end_src With a little tweaking, I got rid of errors when running this code. However, no changes in the output where observable. Finally, I looked at the output from step 3 above and realized that the parser normalizes my <tab> characters away. Only a bunch of spaces in the output! Ouch!! So I guess I would need an option on the parser to switch tab expansion off. I also intended to implement my transformer in a way that I first define the general org-e-org transformer and then derive a specialized transcormer by somehow inheriting the general transformer and then implement my specialized paragraph transformation. It seems that this is at the moment not possible, but I think it would be good to think about this, that will make defining new exporters or even org-file tweakers a breeze. Anyhow, again thanks for writing the new parser / exporter and for your help with my problem! All the best, Christian -- Christian Wittern, Kyoto
Nicolas Goaziou <n.goaziou@gmail.com> writes: > Hello, > > tsd@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
Nicolas Goaziou <n.goaziou@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
Nicolas Goaziou <n.goaziou@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
Hello,
tsd@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
Nicolas Goaziou <n.goaziou@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
Hello, tsd@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
Nicolas Goaziou <n.goaziou@gmail.com> writes: > Hello, > > tsd@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
tsd@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
Nicolas Goaziou <n.goaziou@gmail.com> writes: > tsd@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
Hi Nicolas, I couldn't make this work. Nicolas Goaziou <n.goaziou@gmail.com> writes: > tsd@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
Hello, tsd@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 "ō" "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
tsd@tsdye.com (Thomas S. Dye) writes: > Nicolas Goaziou <n.goaziou@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
Hi,
Following this discussion, I think that we could discuss some related
features, as exporters are currently evolving and certainly will support new
stuff.
Nicolas Goaziou wrote:
> tsd-P0awH739Ni4AvxtiuMwx3w@public.gmane.org (Thomas S. Dye) writes:
>> Nicolas Goaziou <n.goaziou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.
Speaking of hyperref and its _document properties_, it makes me think of a
generic point for which I don't have yet a really satisfactory solution, that
is about handling dates.
In a PDF document, regarding dates, we have (see output of `pdfinfo'):
- creation date
- modification date
In Org, we have the `#+DATE:' info keyword, with the date that's supposed to
be exported onto the final document format (HTML, PDF, OOo, etc.).
But we don't see when the document has been updated for the last time --
neither when it has been created.
For the former point (date of last update), I've customized Org so that the
`time-stamp' package updates time stamps every time you save the Org buffer:
#+begin_src emacs-lisp
(add-hook 'before-save-hook 'time-stamp)
(add-hook 'org-mode-hook
(lambda ()
;; file modification date
(set (make-local-variable 'time-stamp-format) "%:y-%02m-%02d")
(set (make-local-variable 'time-stamp-start) "^#\\+DATE: +")
(set (make-local-variable 'time-stamp-end) "$")))
#+end_src
That makes my `#+DATE:' info keyword always *up-to-date*.
Though, in some cases:
- I must print a document with a future date (for example, I'm preparing
slides which I will present on next Monday) -- hence, the above breaks this,
because I'd like to have next Monday's date already printed on my slides (at
least on the title page).
- it would be nice to get keep track of the creation date of the Org document,
though this is not really necessary.
Clearly, I should not make the `#+DATE:' info keyword updated, to keep it for
its export function (as the official date to be printed on the title page),
but then it'd be good to have at least a last modification date somewhere.
What do you think of all this? How do you do to keep more info on dates?
Best regards,
Seb
PS- Some global `draft' or `final' info could make some sense too.
--
Sebastien Vauban
Hi Nicolas,
Nicolas Goaziou wrote:
> tsd-P0awH739Ni4AvxtiuMwx3w@public.gmane.org (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 "ō" "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 replacement In 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 replacement Plain 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 replacement Use 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
Hi Nicolas, Nicolas Goaziou <n.goaziou@gmail.com> writes: > Hello, > > tsd@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 "ō" "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
Hello, "Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes: > Speaking of hyperref and its _document properties_, it makes me think of a > generic point for which I don't have yet a really satisfactory solution, that > is about handling dates. > > In a PDF document, regarding dates, we have (see output of `pdfinfo'): > > - creation date > - modification date > > In Org, we have the `#+DATE:' info keyword, with the date that's supposed to > be exported onto the final document format (HTML, PDF, OOo, etc.). > > But we don't see when the document has been updated for the last time -- > neither when it has been created. > > For the former point (date of last update), I've customized Org so that the > `time-stamp' package updates time stamps every time you save the Org buffer: > > #+begin_src emacs-lisp > (add-hook 'before-save-hook 'time-stamp) > > (add-hook 'org-mode-hook > (lambda () > ;; file modification date > (set (make-local-variable 'time-stamp-format) "%:y-%02m-%02d") > (set (make-local-variable 'time-stamp-start) "^#\\+DATE: +") > (set (make-local-variable 'time-stamp-end) "$"))) > #+end_src > > That makes my `#+DATE:' info keyword always *up-to-date*. > > Though, in some cases: > > - I must print a document with a future date (for example, I'm preparing > slides which I will present on next Monday) -- hence, the above breaks this, > because I'd like to have next Monday's date already printed on my slides (at > least on the title page). > > - it would be nice to get keep track of the creation date of the Org document, > though this is not really necessary. > > Clearly, I should not make the `#+DATE:' info keyword updated, to keep it for > its export function (as the official date to be printed on the title page), > but then it'd be good to have at least a last modification date > somewhere. > > What do you think of all this? How do you do to keep more info on > dates? Export systems already provide a {{{modification-time(format-string)}}} macro by default. > Some global `draft' or `final' info could make some sense too. Isn't it too much back-end specific? Regards, -- Nicolas Goaziou
"Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes: > Nicolas Goaziou wrote: >> I used: >> >> (add-to-list 'org-entities-user '("omacr" "\\={o}" nil "ō" "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 replacement In 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 replacement Plain 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 replacement Use 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
Hi all, Nicolas Goaziou wrote: > "Sebastien Vauban" writes: > >> Speaking of hyperref and its _document properties_, it makes me think of a >> generic point for which I don't have yet a really satisfactory solution, that >> is about handling dates. >> >> In a PDF document, regarding dates, we have (see output of `pdfinfo'): >> >> - creation date >> - modification date >> >> In Org, we have the `#+DATE:' info keyword, with the date that's supposed to >> be exported onto the final document format (HTML, PDF, OOo, etc.). >> >> But we don't see when the document has been updated for the last time -- >> neither when it has been created. >> >> For the former point (date of last update), I've customized Org so that the >> `time-stamp' package updates time stamps every time you save the Org buffer: >> >> #+begin_src emacs-lisp >> (add-hook 'before-save-hook 'time-stamp) >> >> (add-hook 'org-mode-hook >> (lambda () >> ;; file modification date >> (set (make-local-variable 'time-stamp-format) "%:y-%02m-%02d") >> (set (make-local-variable 'time-stamp-start) "^#\\+DATE: +") >> (set (make-local-variable 'time-stamp-end) "$"))) >> #+end_src >> >> That makes my `#+DATE:' info keyword always *up-to-date*. >> >> Though, in some cases: >> >> - I must print a document with a future date (for example, I'm preparing >> slides which I will present on next Monday) -- hence, the above breaks this, >> because I'd like to have next Monday's date already printed on my slides (at >> least on the title page). >> >> - it would be nice to get keep track of the creation date of the Org document, >> though this is not really necessary. >> >> Clearly, I should not make the `#+DATE:' info keyword updated, to keep it for >> its export function (as the official date to be printed on the title page), >> but then it'd be good to have at least a last modification date >> somewhere. >> >> What do you think of all this? How do you do to keep more info on >> dates? > > Export systems already provide a {{{modification-time(format-string)}}} > macro by default. Thanks for suggesting this solution which escaped me, but that's only for export purpose. As suggested by the above "hack", I find it nice (in fact, even useful) to have a least 2 dates in the Org buffer itself: - a date for export purpose (an official one, to be printed on the document title page, and so on); - a "last modified date" in the Org buffer is always useful, knowing that you can have the desire to update the file without touching the "official date" : it can be before or after the official date (for example, correcting a typo you found in slides you've presented yesterday)[1]; - optionally, a "creation date" -- once again in the Org source. >> Some global `draft' or `final' info could make some sense too. > > Isn't it too much back-end specific? It could be, you're right. Just drop this one. Best regards, Seb Footnotes: [1] That does not mean that you shouldn't see, in that case, the 2 dates somewhere -- or the official date plus some sort of revision number. -- Sebastien Vauban
Nicolas Goaziou <n.goaziou@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 replacement In 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 replacement Plain 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 replacement Use 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. --
Hello, Christian Wittern <cwittern@gmail.com> writes: >> 3. If all went well, you now have an impressive Org to Org converter. >> You can even test it with: >> >> #+begin_src emacs-lisp >> (switch-to-buffer (org-export-to-buffer 'translator "*Translation*")) >> #+end_src >> >> Obviously, there is not much to see. > It worked wonderful until here. >> Now, we're going to redefine `org-translator-paragraph' to properly >> ignore one language or the other, depending on `:translator-side' value. >> >> #+begin_src emacs-lisp >> (defun org-translator-paragraph (paragraph contents info) >> "Convert PARAGRAPH to Org, ignoring one language. >> Language kept is determined by `:translator-side' value." >> (let ((leftp (eq (plist-get info :translator-side) 'left))) >> (replace-regexp-in-string >> (if leftp "\t+.*$" "^.*\t+") "" contents))) >> #+end_src > > With a little tweaking, I got rid of errors when running this code. > However, no changes in the output where observable. Finally, I looked > at the output from step 3 above and realized that the parser > normalizes my <tab> characters away. Only a bunch of spaces in the > output! Ouch!! > So I guess I would need an option on the parser to switch tab expansion off. > > I also intended to implement my transformer in a way that I first > define the general org-e-org transformer and then derive a specialized > transcormer by somehow inheriting the general transformer and then > implement my specialized paragraph transformation. It seems that > this is at the moment not possible, but I think it would be good to > think about this, that will make defining new exporters or even > org-file tweakers a breeze. In fact the problem is subtle. For example, you don't want include keywords to be expanded and babel block to be executed when exporting from Org to Org. I've added a noexpand keyword for that. Hence, you will need to call your converter with: #+begin_src emacs-lisp (switch-to-buffer (org-export-to-buffer 'translator "*Translation*" nil nil nil nil 'noexpand)) #+end_src The TAB problem is different. I expand tab early because the machine creating the parse-tree and the machine exporting it may not be the same. Tab widths may differ, and it could lead to subtle bugs. I may add a :tab-width property in the initial environment. I'm not sure about it yet. Anyway, your tabs have been replaced with spaces, for now. `tab-width' of them. Your paragraph translator may then become something like: #+begin_src emacs-lisp (defun org-translator-paragraph (paragraph contents info) "Convert PARAGRAPH to Org, ignoring one language. Language kept is determined by `:translator-side' value." (let ((leftp (eq (plist-get info :translator-side) 'left))) (replace-regexp-in-string (format (if leftp " \\{%d,\\}.*$" "^.* \\{%d,\\}") tab-width) "" contents))) #+end_src Is it better? Regards, -- Nicolas Goaziou