Re: koma letter exporter: changing the priority of options

[Rasmus <rasmus@gmx.us>]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> I did some experiments and it seems that by default "foldmarks" is
> true. The idea behind the patch is that, if we don't change the default
> values, then things are not output. Let me know if this is fine with you
> and I'll commit this. (I'll also edit the work with the new default
> values.)

Fine with me.

> I still have an issue with the default value for email.
> [...]


> What I propose is the following:
> - we leave the default AUTHOR and EMAIL at nil

I like the default. . .

> - if they are still nil, we output the default values _before_ inputting
>   the lco file
> - if they are no longer nil, we output their values _after_ inputting
>   the lco file

I think we need to treat koma variables more generally (I have some
sketches locally) if anything.  Not make their behavior more
specialized.

> This way, if they are not defined in the file, then the lco can override
> them, otherwise the local option will be the one used.

Just to summarize, we are talking about three emails,
  1. the one set in the config file (defaults)
  2. the one set in a lco file
  3. the one set locally.

You want the above ranking.  But currently 1. and 3. are the same to
the exporter.  So you propose to /alter/ the sequence of the exporter
depending on whether 1. or 3. occurred.  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.  It seems you want to have 1 set to nil when an
email is supplied via 2.

If you really want to go down this patch, fine, I can check out your
suggesting.  But I'm skeptical!

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.

–Rasmus

-- 
ツ