Re: koma letter exporter: changing the priority of options

[Rasmus <rasmus@gmx.us>]

Hi Viktor and Allan,

>> I think we need to treat koma variables more generally (I have some
>> sketches locally) if anything.  Not make their behavior more
>> specialized.
>
> Could you elaborate on what you mean by this?

I want to be able to generate and set /any/ Koma variable from emacs,
including making my own ones.  Sometimes I use custom koma variables
depending on the letter and my footer then looks for the values of the
koma variables and typeset the footer depending on which variables are
available.  

As "half" of current template sets koma variables, this seems like
something worthwhile doing.  

I have a defun to set an arbitrary koma variables, but I haven't
looked more into it.
  
>> But you'd still end up with
>> two emails in your file, and if you lost the LCO file the other email
>> would still be there.
>
> That is a valid criticism. I'd rather not have data specified in the TeX
> file that is overwritten later on. However, if you lose the LCO file,
> presumably you can't regenerate the lettern anyway.

Nah, but you still "wrong" data in your template.

>> I slightly less mind-boggling approach would be to replace the default
>> function with one that (1) fetches the LCO values from the file (but
>> what if they are remote?); (2) obtains the path via kpsewhich (run
>> from the current dir); (3) run grep on each of these files with some
>> intelligent keyword.  The only hard part is (1) and (2) and (3) are
>> almost foolproof.
>
> That approach, in my view, seems overly complicated and also very
> brittle.

I not advocating for its inclusion as a general solution(!), but as a
specific solution in the case where you don't want to set the user
email to nil, but still want to use it some of the time.  

It's brittle to the extend that Texlive is brittle.  Kpsewhich should
find the files (running from the same folder) if latex can find them.

Making the /location/ of a variable /in the output/ a function of
whether it's one value or the other is an ugly hack IMO.  (Same as the
above, but the above you can keep in your own config file).

If we want to go down that path a better way is to let the user decide
on the relative importance of variables versus LCO files.

1. To let the placement of koma variables and lco files be
   configurable via special [BRACKET] keywords as in org-latex-class.

2. To let the preamble be "blocks", as with the end material (ps cc
   encl), and let users deceit the way they want material to come.
   E.g. if some variable is '(komavars lco) then lco is typeset before
   komavars.


–Rasmus


-- 
Dung makes an excellent fertilizer