Re: Extending org-koma-letter.el

[Nicolas Goaziou <n.goaziou@gmail.com>]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> I had to write yet another letter, so I digged into this and it's now
> working well enough for me. I made a few changes to the file (which I
> attach):
>
> - fixed bugs to the menu (export to pdf, open pdf), added "export to tex
>   file"
> - put a default address "no address" instead of a blank line, otherwise
>   compilation fails
> - moved the lco file input before the preamble, so that one can specify
>   some additional information (like packages). (This may be
>   questionable, don't hesitate to let me know.)

I think that's fine.

> I now have two questions: a technical one and a non-technical one.
>
> The technical one: I see that org-e-koma extends the latex exporter with
> some options:
>
> (org-export-define-derived-backend koma-letter e-latex
>   :options-alist
>   ((:closing "CLOSING" nil org-koma-letter-closing)
>    (:from-address "FROM_ADDRESS" nil org-koma-letter-from-address newline)
> ...
>
> These options have 3 arguments instead of 4 in the definition of options
> in org-e-latex:
>
>   :options-alist ((:date "DATE" nil org-e-latex-date-format t)
> 		  (:latex-class "LATEX_CLASS" nil org-e-latex-default-class t)
> ...
>
> Is the missing argument the one that lets EXPORT_OPTIONS specify if some
> parts can be omitted for subtree export? Or is it something different?

It's something different: the last argument defines the behaviour when
more than one keyword is found in the buffer. When unspecified, it
defaults to nil. The syntax is the same as `org-export-options-alist',
which defines back-end agnostic export options. You should have a look
at its docstring.

> The non-technical question: I understand this exporter is just a proof
> of concept, but it is working quite well for me, and I'm ready to help
> tweaking this. If I do further modifications, should I send them to the
> list?

I classified it as "proof of concept" because I was too lazy to dig into
Scrlttr2 documentation and provide a complete enough letter back-end.
I would be glad that someone maintains it.

I think the simplest solution is to:

  1. Ask for push access to Org.
  2. Commit file in contrib/ directory.
  3. Add yourself as Maintainer in it (or Author, for that matter).
  4. Commit additional changes when you see fit, without sending the
     file over and over to the ML.

For point 1, see http://orgmode.org/worg/org-contribute.html (For Org
Developers)

Also, it would be nice if you signed FSF papers.

Thank you.


Regards,

-- 
Nicolas Goaziou