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