Re: [patch] ox-koma-letter

[Michael Strey <mstrey@strey.biz>]

Hi Rasmus,

Thank you for sharing this patch.  I have changed ox-koma-letter.el as
well to fit my needs but didn't publish my changes.

On Mon, Feb 25, 2013 at 09:25:58PM +0100, Rasmus wrote:

[...]

> I have been working on extending the KOMA letter support in Org.  The
> backend is still rough and I would like to more stuff such as
> designing firstfood and firsthead with org elements (e.g. I use a
> tabularx for my firstfood with varioues stuff).
> 
> I have changed the following objects:
[...]
>   3. Added from-bank, invoice and other keywords like that.  Still
>      many to go, but some of them would probably need some thought.
>      For instance firstfoot should work differently depending on
>      whether it is given a NAMEd table or a string.  Any though? 
[...]

IMO your approach goes into a questionable direction here.  Following it
we will end up defining the complete letterhead and letter layout by
setting org-mode variables.  Wouldn't it be better to use Markus Kohm's
concept of letter class options to set all the static stuff?

If I write a letter, I would like to say "this is a business letter from
Michael Strey", give the address the date and maybe some references and start
writing.  I do not want to give in my phone number, my e-mail address or my
backaddress.  I don't even want to see them in the org-mode document.
Therefore I have two letter class options, one for my private letters and
one for my business letters that contain the complete letter head and
foot, phone number, backaddress, e-mail address and so on.

Following this concept ox-koma-letter.el should support LCO and the
following variables and nothing else:

- customer
- date
- invoice
- myref
- specialmail
- subject
- title
- yourmail
- yourref
- address
- opening
- closing
- cc
- encl
- ps
- language


>   2. Added AFTER_CLOSING and AFTER_LETTER keywords for arbitrary code
>      after \closing{.} and \end{letter}, respectively.
>      a. A weird bug I don't understand is why I cannot have
>         #+AFTER_CLOSING{\ps{ps:}}
>      b. Would it be better to have a dedicated, say, PS and ENCL rather
>         than the generic AFTER_CLOSING?

I would opt for dedicated variables.

Regards,
-- 
Michael Strey 
www.strey.biz