Re: koma letter exporter: changing the priority of options

[Rasmus <rasmus@gmx.us>]

Alan,

> Sorry for the delay, I was in vacations with tethering-only internet
> access.

No worries.  A tethering-only vacation sounds great!

>> I spoke too early.  For example this letter no longer works as usual:
>>
>> #+TITLE: test
>> #+OPTIONS: foldmarks:nil
>> * Letter
>>   my letter
>> ** TO	 :TO:
>>    someone
>>    somewhere
>>
>> But this is because nil has a "new" meaning of "not set" as opposed to
>> "false".  Is this OK?  On one hand nil usually means False in ox, I
>> think (e.g. inline:nil → inline comments not posted), but on the other
>> hand nil often means not set in Emacs. . .  It is nice to having to
>> look at the extra setkomavariable, but I'm not sure whether it's
>> right.
>
> I tried to fix it in the updated attached patch. I set a default value
> of "foldmarks-not-set" to the predicate that detects if it is set in the
> file, then I compare its contents. This assumes that the user will not
> give this literal value to the option.

I'll check it out later.

>> I also find something like this ghastly:
>>
>> But perhaps it is the only way to get what you want.
>
> I could not find a way to do it another way, but I'll gladly take any
> suggestion. What we want is:
> - if email is set in the file, use it;
> - otherwise, use the one from the lco;
> - otherwise, use the default one.

Hmm, I guess we'd have to have to assign the variables to certain
lists on the fly.  If the header string is a concat of

    (PREAMBLE-STRING    DEFAULT-VALUES    LCO    BUFFER-LOCAL)

where a member of DEFAULT-VALUES is a cons, e.g.

    ("fromname" . "Rasmus").

Then we can remove all pairs from DEFAULT-VALUES where the first first
element (the "key") also exists in BUFFER-LOCAL.  

It might be too much work?  I'm not sure. . .

I've been thinking about something like that earlier, as I'd like to
sometimes introduce new KOMA-Variables on the fly (e.g. my footer
table prints some the KOMA variable ID if that KOMA variable is
defined).

>> Also, with the current setup, I can only set email before or after.
>> Why?  What if I want to let PLACE be dependent on my LCO file versus
>> my org file?
>
> I think you can do it: if you don't give the option in the file, the one
> from the LCO will be used, otherwise the one in the file will override
> it. The main thing with author and email is that they almost always have
> non-nil default values, whereas place's default value is nil. If this is
> not correct, we can extend the approach for author and email to places
> or other options.

I agree that author and email perhaps deserve special attention, but

–Rasmus

-- 
This is the kind of tedious nonsense up with which I will not put