Hello Rasmus,

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

rasmus@gmx.us writes:

> The following message is a courtesy copy of an article
> that has been posted to gmane.emacs.orgmode as well.
>
> Rasmus <rasmus@gmx.us> writes:
>
>> Alan,
>>
>>> alan.schmitt@polytechnique.org writes:
>>>
>>>> Yes, this is not satisfactory (and the email and author is also
>>>> problematic in this regard). We need to know whether an option was set
>>>> in the file, independently of its default value. Is there a way to do
>>>> this?
>>>
>>> Thanks to Nicolas, I've been able to create a cleaner solution: we track
>>> some of the variables (ones for which we currently output something by
>>> default, typically because they are set or because we choose to always
>>> output something, like from-phone), and we only output the code if the
>>> variable was set in the file. Thus if nothing is set, the lco file
>>> wins. Note that with this approach, one can have a default in the lco
>>> that is overridden by the file, for instance for foldmarks or to display
>>> phone numbers.
>>>
>>> Regarding the name and email, we output it before the lco if they are
>>> not specified in the file, and after if they are.
>>>
>>> What do you think of this approach? Are there other variables we should
>>> track?
>
> 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 also find something like this ghastly:
>
>       (unless author-set
> 	(when author (format "\\setkomavar{fromname}{%s}\n"
> 			     (org-export-data author info))))
>       (unless email-set
> 	(when email (format "\\setkomavar{fromemail}{%s}\n" email)))
>       ^^^^^^^^^^^^^^^^^^^^^^
>       ;; Letter Class Option File
>       (when lco
>       [...]
>       ))
>       ;; Define "From" data.
>       (when (and author author-set) (format "\\setkomavar{fromname}{%s}\n"
> 					    (org-export-data author info)))
>       (when from-address (format "\\setkomavar{fromaddress}{%s}\n" from-address))
>       (when phone-number
> 	(format "\\setkomavar{fromphone}{%s}\n" phone-number))
>       (when (and email email-set) (format "\\setkomavar{fromemail}{%s}\n" email))
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> 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.

> 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.

Best,

Alan