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