Re: [O] Help with new exporter

[Rasmus]

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

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.

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

–Rasmus

-- 
Send from my Emacs