[ANN] ASCII back-end for new export engine

[ANN] ASCII back-end for new export engine

[Nicolas Goaziou]

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

Re: [ANN] ASCII back-end for new export engine

[Samuel Wales]

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.

Re: [ANN] ASCII back-end for new export engine

[Samuel Wales]

Two feature requests:

  1) optionally squeeze blank lines
  2) optionally unfill paragraphs

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
===
Bigotry against people with serious diseases is still bigotry.

Re: [ANN] ASCII back-end for new export engine

[Nicolas Goaziou]

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

Re: [ANN] ASCII back-end for new export engine

[Samuel Wales]

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.

Re: [ANN] ASCII back-end for new export engine

[Nicolas Goaziou]

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

Re: [ANN] ASCII back-end for new export engine

[Martyn Jago]

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

Re: [ANN] ASCII back-end for new export engine

[Nicolas Goaziou]

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

Re: [ANN] ASCII back-end for new export engine

[Thomas S. Dye]

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

Re: [ANN] ASCII back-end for new export engine

[Samuel Wales]

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.

Re: [ANN] ASCII back-end for new export engine

[Martyn Jago]

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

Re: [ANN] ASCII back-end for new export engine

[Nicolas Goaziou]

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

Re: [ANN] ASCII back-end for new export engine

[Thomas S. Dye]

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

Re: [ANN] ASCII back-end for new export engine

[Nicolas Goaziou]

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

Re: [ANN] ASCII back-end for new export engine

[Thomas S. Dye]

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

Re: [ANN] ASCII back-end for new export engine

[Thomas S. Dye]

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

Re: [ANN] ASCII back-end for new export engine

[Nicolas Goaziou]

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

Re: [ANN] ASCII back-end for new export engine

[Andreas Leha]

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

Re: [ANN] ASCII back-end for new export engine

[Thomas S. Dye]

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

Re: [ANN] ASCII back-end for new export engine

[Nicolas Goaziou]

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

Re: [ANN] ASCII back-end for new export engine

[Eric Schulte]

>> 2) If the source block is executed in buffer with (org-ctrl-c-ctrl-c),
>> as shown above, then the exporter appears to export the in-buffer
>> results /and/ the export-generated results (where :exports is results
>> or both) resulting in two sets of identical results in the export.
>
> It's out of exporter's scope.

I disagree.  The current exporter conforms to the value of the :results
header argument (e.g., silent, replace, append, etc...) when executing
code blocks during export.  I see no reason why the new exporter should
not as well.

> When you ask to export some buffer, what is really parsed is a copy of
> the current buffer with `org-export-blocks-preprocess' applied to it.
>
> So, simply apply that function in your test buffer, and you will see
> what is sent to the parser. That will explain why the results appear
> twice.
>
> In other words, tweaking the output of `org-export-blocks-preprocess'
> will automatically change the outcome of the export process.
>

Hmm, in light of this description it seems that the new export /should/
have the same behavior WRT code block execution as the current
exporter.  If not I wonder if a complete minimal example could be
provided.

Thanks,

>
>
> Regards,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [ANN] ASCII back-end for new export engine

[Nicolas Goaziou]

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

Re: [ANN] ASCII back-end for new export engine

[Thomas S. Dye]

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

Re: [ANN] ASCII back-end for new export engine

[Thomas S. Dye]

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

Re: [ANN] ASCII back-end for new export engine

[Nicolas Goaziou]

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

Tweaking the export (was: Re: [ANN] ASCII back-end for new export engine)

[Christian Wittern]

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

Re: [ANN] ASCII back-end for new export engine

[Eric S Fraga]

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)

Re: [ANN] ASCII back-end for new export engine

[Thomas S. Dye]

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

Re: [ANN] ASCII back-end for new export engine

[Nicolas Goaziou]

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

Re: [ANN] ASCII back-end for new export engine

[Thomas S. Dye]

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

Re: [ANN] ASCII back-end for new export engine

[Nicolas Goaziou]

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

Re: [ANN] ASCII back-end for new export engine

[Achim Gratz]

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

Re: [ANN] ASCII back-end for new export engine

[Thomas S. Dye]

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

Re: [ANN] ASCII back-end for new export engine

[Jambunathan K]

> I have no objection to implement limited numbering in both LaTeX and
> ASCII back-ends, but I'd like to know if it can be handled consistently
> in every other major back-end, too. I'm CC-ing Jambunathan to know his
> opinion about it.

I can support this in ODT exporter. We can make this a feature of the
new export engine.

>> A way to set individual headings as numbered or unnumbered would be
>> deluxe.  Perhaps this is possible, but I haven't found it?
>
> It would require to modify Org's syntax (how to tell which headline has
> to be numbered and which has not?). It is not possible at the moment.

Let us not support this.

> Regards,

Re: [ANN] ASCII back-end for new export engine

[Nicolas Goaziou]

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

Re: [ANN] ASCII back-end for new export engine

[Rick Frankel]

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

Re: Tweaking the export

[Nicolas Goaziou]

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

Re: Tweaking the export

[Jambunathan K]

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.
-- 

Re: [ANN] ASCII back-end for new export engine

[Nicolas Goaziou]

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

Re: [ANN] ASCII back-end for new export engine

[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

Re: Tweaking the export

[Sebastien Vauban]

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

Re: [ANN] ASCII back-end for new export engine

[Bastien]

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

Re: [ANN] ASCII back-end for new export engine

[Thomas S. Dye]

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

Re: [ANN] ASCII back-end for new export engine

[Achim Gratz]

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

Re: [ANN] ASCII back-end for new export engine

[Thomas S. Dye]

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

Re: [ANN] ASCII back-end for new export engine

[Jambunathan K]

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).
-- 

Re: [ANN] ASCII back-end for new export engine

[Thomas S. Dye]

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

Re: [ANN] ASCII back-end for new export engine

[Jambunathan K]

Tom 

The aspect I am exploring is this:

Does numbering behavious occur uniformly for a *given* level? For
example, are we talking of a scenario where level 3 heading in Tree-1 is
numbered while level 3 heading on a Tree-2 is unnumbered. What would be
the behaviour of level 4 heading in Tree-1.

It seems to me, that an unnumbered heading is a mnemonic(?) for creating
a paragraph (albeit a short one) that is styled very much like a
heading. When one looks at a printed document, one doesn't really know
what mechanism were used to achieve a particular typesetting effect and
there could be multiple mechanisms by which the same effect could be
achieved.

If the above paragraph is true , I think the right thing to do would be
to associate a paragraph style with *just* the heading component of an
Org's outline level and leave it to the exporter what particular code it
wants to emit.
-- 

Re: [ANN] ASCII back-end for new export engine

[Achim Gratz]

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

Re: [ANN] ASCII back-end for new export engine

[Thomas S. Dye]

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
> 
> 

Re: [ANN] ASCII back-end for new export engine

[Nick Dokos]

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

Re: [ANN] ASCII back-end for new export engine

[Thomas S. Dye]

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

Re: Tweaking the export

[Christian Wittern]

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

Re: Tweaking the export

[Christian Wittern]

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

Re: Tweaking the export

[Eric Abrahamsen]

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)

Re: [ANN] ASCII back-end for new export engine

[Samuel Wales]

Hi N,

Some comments on your great work:

Recent version errors with wrong type argument, but I can't
privacy-wash yet to show the whole stack trace.

  make-string(-1 32)
  (concat aligned-cell (make-string (- col-width ...) 32))
  (format " %s " (concat aligned-cell (make-string ... 32)))
  (let* ((indent-tabs-mode nil) (align ...) (aligned-cell ...))
(format " %s " (concat aligned-cell ...)))
  (let ((col-width ...)) (unless (or org-e-ascii-table-widen-columns
...) (setq cell ...)) (let* (... ... ...) (format " %s " ...)))

For what it's worth.  I might need to give you a full stack trace if
that is not enough.  22 with latest git.

I suspect it is because your exporter actually tries to understand all
syntax, while the old one passes through a lot of things (maybe
including list-like things).


These comments are from an earlier version that worked:

I like to separate things like this:

===

The old exporter left it intact; the new one tries to interpret it
even though /text/ and *text* are left intact.  I'm guessing this is a
new feature that works only on =word=.  I'd like to turn it off if it
can't be made to not interpret my separator.

Most lines are indented by 2 spaces.  I'd prefer flush to left.

It splits the window even though I have pop-up-windows set to nil.

Block quotes indent by 8 or so.  That's rather nice, but is there an
option to change that to 2 or 4?

Lists are not indented although I always indent them by 2.

Is there an option to set the fill column and refill paragraphs
(roughly like the way HTML does)?  I'd find that highly useful.
Unfilling too.

Feature requesti --export tables using tab characters.  If it doesn't
exist already.  Maybe it does?

Footnotes don't have a header.  HTML export inserts one.

No final newline.

One missing footnote .  It is going to take me a while to narrow it down.

Thanks.

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
===
Bigotry against people with serious diseases is still bigotry.

Re: [ANN] ASCII back-end for new export engine

[Nicolas Goaziou]

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

Re: [ANN] ASCII back-end for new export engine

[Samuel Wales]

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

Re: [ANN] ASCII back-end for new export engine

[Nicolas Goaziou]

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

Re: [ANN] ASCII back-end for new export engine

[Samuel Wales]

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.

Re: [ANN] ASCII back-end for new export engine

[Nicolas Goaziou]

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

Re: Tweaking the export

[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

Re: [ANN] ASCII back-end for new export engine

[Achim Gratz]

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

Re: [ANN] ASCII back-end for new export engine

[Jambunathan K]

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.
-- 

Re: [ANN] ASCII back-end for new export engine

[Nicolas Goaziou]

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

Re: Tweaking the export

[Christian Wittern]

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

Re: [ANN] ASCII back-end for new export engine

[Thomas S. Dye]

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

Re: [ANN] ASCII back-end for new export engine

[Thomas S. Dye]

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

Re: [ANN] ASCII back-end for new export engine

[Thomas S. Dye]

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

Re: [ANN] ASCII back-end for new export engine

[Nicolas Goaziou]

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

Re: [ANN] ASCII back-end for new export engine

[Thomas S. Dye]

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

Re: [ANN] ASCII back-end for new export engine

[Nicolas Goaziou]

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

Re: [ANN] ASCII back-end for new export engine

[Thomas S. Dye]

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

Re: [ANN] ASCII back-end for new export engine

[Nicolas Goaziou]

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

Re: [ANN] ASCII back-end for new export engine

[Thomas S. Dye]

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

Re: [ANN] ASCII back-end for new export engine

[Thomas S. Dye]

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

Re: [ANN] ASCII back-end for new export engine

[Nicolas Goaziou]

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 "&#333;" "o" "o" "ō"))
--8<---------------cut here---------------end--------------->8---

without a problem.

> I played around a bit with entities defined in org-entities, and these
> do transcode properly.  How do I get one in the middle of a word?  If I
> leave a space after the entity, the space ends up in the output.  If I
> don't leave a space, the entity isn't recognized.

Use {}, i.e. some w\omacr{}rd (new exporter only).


Regards,

-- 
Nicolas Goaziou

Re: [ANN] ASCII back-end for new export engine

[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

Document date and last updated date

[Sebastien Vauban]

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

Re: [ANN] ASCII back-end for new export engine

[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

Re: [ANN] ASCII back-end for new export engine

[Thomas S. Dye]

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 "&#333;" "o" "o" "ō"))
>
> without a problem.
>
Thanks.  User error on this end.

>> I played around a bit with entities defined in org-entities, and these
>> do transcode properly.  How do I get one in the middle of a word?  If I
>> leave a space after the entity, the space ends up in the output.  If I
>> don't leave a space, the entity isn't recognized.
>
> Use {}, i.e. some w\omacr{}rd (new exporter only).

Yes, that works, too.

Thanks again for the help.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: Document date and last updated date

[Nicolas Goaziou]

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

Re: [ANN] ASCII back-end for new export engine

[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 "&#333;" "o" "o" "ō"))
>>
>> without a problem.
>
> IIUC, you specify how to translate some "LaTeX-like command" to the different
> back-ends. But I don't see DocBook nor OOo in the list:
>
>     ┏━━━━
>     ┃ User-defined entities used in Org-mode to produce special characters.
>     ┃ Each entry in this list is a list of strings.  It associates the name
>     ┃ of the entity that can be inserted into an Org file as \name with the
>     ┃ appropriate replacements for the different export backends.  The order
>     ┃ of the fields is the following
>     ┃ 
>     ┃ name                 As a string, without the leading backslash
>     ┃ LaTeX 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

Re: Document date and last updated date

[Sebastien Vauban]

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

Re: [ANN] ASCII back-end for new export engine

[Jambunathan K]

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.

-- 

Re: Tweaking the export

[Nicolas Goaziou]

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