Re: [O] Help with new exporter

[Nick Dokos]

Rasmus <address@hidden> writes:

> Nick. Robert, 
>
> Disclaimer: I didn't follow this thread closely. . . 
>
> Nick Dokos <address@hidden> writes:
>
>>> (sorry, this should've gone to the list the first time)
>>>
>>> Hi John,
>>>
>>> sorry, I can't help you with the filters.
>>>
>>> On the other hand, I don't see any reason why you gt whose square brackets.
>>>
>>> I tried different versions of org-mode, and never got *empty* square
>>> brackets.
>>
>> That was my experience as well...
>
> If one desires empty squares why not use [\mbox{}]?  In LaTeX terms I
> think [\mbox{}] is equivalent or almost equivalent o [], and to Org
> they are different. . .
>

I think you misunderstood here: John Rakestraw seems to get empty sets
of square brackets in the latex file that he produces from his org file.
What Robert pointed out (and what I concurred with) was that when he
runs John's org file through the exporter, he does not get these empty
square brackets. The question is why John on one hand and Robert (and I)
on the other hand see such different behavior from the exporter.

> Otherwise add a (regexp) filter to
> org-export-filter-final-output-functions inserting the missing []s.
>
> Here's an example of a filer I use.  Notice that ox keeps everything
> in a string and in property lists (← just an indexed dictionary).
>
> #+BEGIN_SRC emacs-lisp
> (defun org-latex-filter-nobreaks-double-space (text backend info)
>   "Tries to export \"S1. S2\" as \"S1.~S2\",
>    while letting \"S1.  S2\" be exported without tilde"
>   (when (org-export-derived-backend-p backend 'latex)
>     (replace-regexp-in-string "\\(\\. \\)\\{1\\}\\([^ ]\\)" ".~\\2" text)))
>
> (add-to-list 'org-export-filter-final-output-functions
>              'org-latex-filter-nobreaks-double-space)
> #+END_SRC
>
> (This may not be a great example as one probably should implement it
>  at org-export-before-processing-hook and insert NO-BREAK SPACEs and
>  tell LaTeX how to handle these).
>
>> Rasmus's derived backend idea might work perhaps - I for one wouldn't
>> know how to implement it at this point. But trying to edit artifacts out
>> after the backend is more or less finished seems to me to be a fruitless
>> approach.
>
> I'm not claiming it's easy (Lisp can be pretty daunting, yes?), but
> it's definitely doable.
>

The "fruitless" label was *not* meant for your derived-backend idea: au
contraire.

John is trying to write filters to edit out all the artifacts that he is
getting. That's what I thought was the fruitless approach. The derived
backend approach seems to me to be the *only* (or at least the best)
one for mapping org files to the exam class.

I'm sure it is doable: knowing *how* to do it is another matter though -
and it's not so much the Lisp, it's figuring out how everything has to
go together, given the framework (and all the supporting infrastructure)
that Nicolas has provided. I can deal with the Lisp but I just don't
know enough about the new exporter framework to even do a trivial
backend at this point.

>  1. You start by thinking about how you want your layout to be.  This
>     is particularly the case if you don't want to (mis)use the *s for
>     everything.  For instance the Org file Robert posted had a lot of
>     repeated things that might as well be handeled by the computer.
>  2. Then you write functions that translate the elements that you want
>     to work differently into LaTeX code and put 'em into
>     the :translate-alist.  All functions that you're not adding will
>     come from the LaTeX class.
>
> Here's some documentations (somewhat heavy)
>
>      http://orgmode.org/manual/Adding-export-back_002dends.html
>      http://orgmode.org/worg/dev/org-export-reference.html
>
> and an not-so-enlightening example
>
>      http://orgmode.org/worg/exporters/filter-markup.html
>
>
> Further: I'm working on a section for the manual on ways of adding new
> backends, but alas I must spend my time on other activities at the
> moment. Of course, the present discussion of implementing an exam
> class is a much more interesting example than the cookbook I'm working
> on at the moment :)  
>

More tutorials is exactly what's needed, so thanks for the pointers
- and any future tutorials you provide as well :-)

> –Rasmus

-- 
Nick