Re: [patch] ox-koma-letter

[Rasmus <rasmus@gmx.us>]

Michael,

> I mean customized LCO files.  For my former company I had made a
> letter class for business letters based on scrlttr2.cls with two LCO
> files.  the first LCO file *company.lco* contained the general
> information about the company (address, bank account, etc.).  A
> second LCO file *my_name.lco* contained the personal information of
> (e-mail address, name, phone extension).  With *my_name.lco* calling
> *company.lco* the document class command for my letter finally was:
>
> \documentclass[my_name]{our_company_letter_class}
>
> With suitable setting of org-latex-classes not even the LCO feature
> would be needed in ox-koma-letter.  However I would leave it there for
> more flexibility.

That's cool.  Personally, I like this approach.  But while lco files
are still readable they are not very nice.  But not that terrible
either.

In fact to use the scrlttr2 support in Org I had to adjust a LCO files
because it's currently loaded after LATEX_HEADER arguments (so all
customization was overwritten).  I didn't like that.

> Yes, I can imagine such cases.  My problem with the current
> implementation was, that for instance, the phone number was preset in
> org-latex-classes.  That urged me to customize this variable although
> everything was already well defined in *my_name.lco*.  So, please take
> care to preset such variables with nil, where nil shall have the
> meaning
> of 'ignore this variable'.

I agree.  This is anything but flexible, and I didn't even consider
it.  I also noted that there's a lot of silly defaults.  So probably
we should set everything to nil and do a "nil check" before inserting
stuff into the TeX file.  This would also make for a clearer output
file, which is in itself something we should aim for.

> Maybe we should write a user guide *before* further implementation
> steps.

I agree.  A "question zero" is whether we eventually want to have an
org-letter which could, in principle, output to something different
than scrlttr2.

Other things: 

  - Cleaning defaults
  - Only insert KOMAVARs when non-nil.
  - Which variables to include.  E.g. Michael's list vs. every
    komavar.
  - consider the order of KOMAVARs, e.g. do we really want
    LATEX_HEADER before LCO-like stuff?  Do we want a KOMA_HEADER
   (or LETTER_HEADER) which comes after LCO?


What to you think?

> Mmmh ... never thought about this aspect.  I simply dictated the order
> of CC, ENCL and PS in my implementation.  Thus your current
> AFTER_CLOSING is the best solution, if you want to provide full
> flexibility.

Or having the order of ENCL, PS, CC and "AFTER_CLOSING" in the TeX
file be governed by the order in the Org file.  I guess this should be
feasible, although I currently do not know how to code.  I think it's
desireable, though. 

–Rasmus

-- 
When in doubt, do it!