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
