emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] koma letter exporter: changing the priority of options


From: Viktor Rosenfeld
Subject: Re: [O] koma letter exporter: changing the priority of options
Date: Sun, 9 Jun 2013 20:00:59 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Hi Alan,

Alan Schmitt wrote:

> Hello,
> 
> I just had to write a new letter with a fresh LCO file, and I would like
> to propose to change the priority of options. The current priority is:
> local options > emacs variables > lco file.
> 
> Unfortunately emacs variables have a default value, which means they are
> output in the .tex file even if they are not set. Thus it is impossible
> to set some options in the lco file (such as foldmarks or backaddress).

Why not simply set these Emacs variables to nil? Then they are not
written in the TeX file and the LCO file works as expected.

> I propose to either change the priority to:
> local options > lco file > emacs variables

I chose the current behavior in order to have the LCO file as a default
which can easily be overwritten if wanted by setting an option line for
an individual header. For example, I have foldmarks and backaddress
enabled in my LCO file. Recently I had to sent a few letters by email
where these things don't make a lot of sense. So I disabled them using
#+OPTIONS: foldmarks:nil backaddress:nil
 
> or to not output these options when they have not been set. Here are the
> four options I have not set that end up in my .tex file, shadowing my
> lco configuration:
> 
> ,----
> | \KOMAoption{backaddress}{true}
> | \KOMAoption{foldmarks}{true}
> | \KOMAoption{fromphone}{true}
> | \KOMAoption{fromemail}{true}
> `----

Perhaps the best option would be to change the default value of these
variables to nil? We have almost every option that personalizes
a letter, e.g., opening and closing, set to nil already. The only
benefit of having default values is to show off the features of
org-koma-letter. But it seems to be interfering with people's workflow
so best turn them off.

Cheers,
Viktor
> 
> What do you think?
> 
> Alan
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]