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
