Re: [O] koma letter exporter: changing the priority of options
Hi Alan, Alan Schmitt writes: >>> 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. >> >> The attached version is updated to apply cleanly on master (after >> applying your other patches). > > I've pushed this. Please don't hesitate to send suggestions to improve > it, or report if it does not work as expected. Great, it'll serve for now. It shouldn't case any breaks. –Rasmus -- C is for Cookie
Re: [O] koma letter exporter: changing the priority of options
Hi Rasmus, alan.schm...@polytechnique.org writes: > alan.schm...@polytechnique.org writes: > >> 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. > > The attached version is updated to apply cleanly on master (after > applying your other patches). I've pushed this. Please don't hesitate to send suggestions to improve it, or report if it does not work as expected. Best, Alan
Re: [O] koma letter exporter: changing the priority of options
ras...@gmx.us writes:
> As Viktor argues, mainly ugly and fragile solutions exist to check the
> LCO file (e.g. find the file with kpsewhich in texlive). Yet, it
> doesn't matter, as all you care about it the location of the variable
> /depending/ on whether it's set in the buffer.
>
> E.g.
>
> #+LCO: test
> * my letter
> text
>
> produces
>
> [...]
> \setkomavar{fromemail}{ras...@gmx.us}
> \LoadLetterOption{test}
> [...]
>
> which may or may not produce result in ras...@gmx.us being printed
> depending on what test.lco contains.
>
> On the other hand
>
> #+EMAIL: ras...@gmx.us
> #+LCO: test
> * my letter
> text
>
> triggers and updatedp variable (how to automate this I'd have to think
> about) and
>
> [...]
> \LoadLetterOption{test}
> \setkomavar{fromemail}{ras...@gmx.us}
> [...]
>
> Is this not what you want?
Yes, this is exactly what I want (and what is being done by the
patch). So if I understand correctly, you propose an alternative way to
do this?
Alan
Re: [O] koma letter exporter: changing the priority of options
Alan Schmitt writes:
>>> 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.
>>
>> (PREAMBLE-STRINGDEFAULT-VALUESLCOBUFFER-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.
>
> This could be a way to do it. However, I don't know how to detect the
> variables in the LCO file, which is why they may be duplicated in the
> tex file.
As Viktor argues, mainly ugly and fragile solutions exist to check the
LCO file (e.g. find the file with kpsewhich in texlive). Yet, it
doesn't matter, as all you care about it the location of the variable
/depending/ on whether it's set in the buffer.
E.g.
#+LCO: test
* my letter
text
produces
[...]
\setkomavar{fromemail}{ras...@gmx.us}
\LoadLetterOption{test}
[...]
which may or may not produce result in ras...@gmx.us being printed
depending on what test.lco contains.
On the other hand
#+EMAIL: ras...@gmx.us
#+LCO: test
* my letter
text
triggers and updatedp variable (how to automate this I'd have to think
about) and
[...]
\LoadLetterOption{test}
\setkomavar{fromemail}{ras...@gmx.us}
[...]
Is this not what you want?
–Rasmus
--
ツ
Re: [O] koma letter exporter: changing the priority of options
Hi Rasmus,
ras...@gmx.us writes:
>>> 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-STRINGDEFAULT-VALUESLCOBUFFER-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. . .
This could be a way to do it. However, I don't know how to detect the
variables in the LCO file, which is why they may be duplicated in the
tex file.
Alan
Re: [O] koma letter exporter: changing the priority of options
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-STRINGDEFAULT-VALUESLCOBUFFER-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
Re: [O] koma letter exporter: changing the priority of options
alan.schm...@polytechnique.org writes:
> 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.
The attached version is updated to apply cleanly on master (after
applying your other patches).
Alan
>From 6c930ee3cca8db5af333e8822686f7783e72c14b Mon Sep 17 00:00:00 2001
From: Alan Schmitt
Date: Mon, 22 Jul 2013 16:46:02 +0200
Subject: [PATCH] Koma exporter: Ensure customization to LCO files are taken
into account
* contrib/lisp/ox-koma-letter.el: Change default values to match the scrlttr2
default values. Track which options are set in the file and only output the
corresponding options when they are changed.
---
contrib/lisp/ox-koma-letter.el | 49 +++---
1 file changed, 37 insertions(+), 12 deletions(-)
diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 6f5529f..240de29 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -232,7 +232,7 @@ English manual of 2012-07-22)."
-(defcustom org-koma-letter-use-backaddress t
+(defcustom org-koma-letter-use-backaddress nil
"Print return address in small line above to address."
:group 'org-export-koma-letter
:type 'boolean)
@@ -247,12 +247,12 @@ Use `foldmarks:true' to activate default fold marks or
:group 'org-export-koma-letter
:type 'string)
-(defcustom org-koma-letter-use-phone t
+(defcustom org-koma-letter-use-phone nil
"Print sender's phone number."
:group 'org-export-koma-letter
:type 'boolean)
-(defcustom org-koma-letter-use-email t
+(defcustom org-koma-letter-use-email nil
"Print sender's email address."
:group 'org-export-koma-letter
:type 'boolean)
@@ -299,9 +299,11 @@ A headline is only used if #+OPENING is not set. See also
org-koma-letter-default-class
org-latex-default-class) t)
(:author "AUTHOR" nil (org-koma-letter--get-value org-koma-letter-author) t)
+(:author-changed-in-buffer-p "AUTHOR" nil nil t)
(:from-address "FROM_ADDRESS" nil nil newline)
(:phone-number "PHONE_NUMBER" nil org-koma-letter-phone-number)
(:email "EMAIL" nil (org-koma-letter--get-value org-koma-letter-email) t)
+(:email-changed-in-buffer-p "EMAIL" nil nil t)
(:to-address "TO_ADDRESS" nil nil newline)
(:place "PLACE" nil org-koma-letter-place)
(:opening "OPENING" nil org-koma-letter-opening)
@@ -318,9 +320,13 @@ A headline is only used if #+OPENING is not set. See also
(:with-after-letter nil "after-letter-order"
org-koma-letter-special-tags-after-letter)
(:with-backaddress nil "backaddress" org-koma-letter-use-backaddress)
+(:with-backaddress-changed-in-buffer-p nil "backaddress" nil)
(:with-foldmarks nil "foldmarks" org-koma-letter-use-foldmarks)
+(:with-foldmarks-changed-in-buffer-p nil "foldmarks" "foldmarks-not-set")
(:with-phone nil "phone" org-koma-letter-use-phone)
+(:with-phone-changed-in-buffer-p nil "phone" nil)
(:with-email nil "email" org-koma-letter-use-email)
+(:with-email-changed-in-buffer-p nil "email" nil)
(:with-place nil "place" org-koma-letter-use-place)
(:with-subject nil "subject" org-koma-letter-subject-format))
:translate-alist '((export-block . org-koma-letter-export-block)
@@ -540,11 +546,19 @@ holding export options."
info)))
(let ((lco (plist-get info :lco))
(author (plist-get info :author))
+ (author-set (plist-get info :author-changed-in-buffer-p))
(from-address (org-koma-letter--determine-to-and-from info 'from))
(phone-number (plist-get info :phone-number))
(email (plist-get info :email))
+ (email-set (plist-get info :email-changed-in-buffer-p))
(signature (plist-get info :signature)))
(concat
+ ;; author or email not set in file: may be overridden by lco
+ (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
(let ((lco-files (split-string lco " "))
@@ -553,11 +567,12 @@ holding export options."
(setq lco-def (format "%s\\LoadLetterOption{%s}\n" lco-def lco-file)))
lco-def))
;; Define "From" data.
- (when author (format "\\setkomavar{fromname}{%s}\n"
- (org-export-data author info)))
+ (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 email (format "\\setkomavar{fromemail}{%s}\n" email))
+ (when phone-number
+ (format "\\setkomavar{fromphone}{%s}\n" phone-number))
+ (when (
Re: [O] koma letter exporter: changing the priority of options
Hello Rasmus,
Sorry for the delay, I was in vacations with tethering-only internet
access.
ras...@gmx.us writes:
> The following message is a courtesy copy of an article
> that has been posted to gmane.emacs.orgmode as well.
>
> Rasmus writes:
>
>> Alan,
>>
>>> alan.schm...@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
>From 1299e543992d00f98d52a967c5a802213ce09799 Mon Sep 17 00:00:00 2001
From: Alan Schmitt
Date: Mon, 22 Jul 2013 16:46:02 +0200
Subject: [PATCH] Koma exporter: Ensure customization to LCO files are taken
into account
* contrib/lisp/ox-koma-letter.el: Change default values to match the scrlttr2
default values. Track which options are set in the file and only output the
corresponding options when they are changed.
---
contrib/lisp/ox-koma-letter.el | 49 +++---
1 file changed, 37 insertions(+), 12 deletions(-)
diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index d149f9d..9ae4d32 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -228,7 +228,7 @@ English manual of 2012-07-22)"
-(defcustom org-koma-letter-use-backaddress t
+(defcustom org-koma-letter-use-backaddress nil
"Print return address in small line above to address."
:group 'org-export-koma-letter
:type 'boolean)
@@ -243,12 +243,12 @@ Use `foldmarks:true' to activate default fold marks or
:group 'org-export-koma-letter
:type 'string)
-(defcustom org-koma-letter-use-phone t
+(d
Re: [O] koma letter exporter: changing the priority of options
Rasmus writes:
> Alan,
>
>> alan.schm...@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 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. 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?
–Rasmus
--
When the facts change, I change my mind. What do you do, sir?
Re: [O] koma letter exporter: changing the priority of options
Alan, > alan.schm...@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'm so sorry I haven't looked at this before now despite promising to do it much earlier (off-list)! The changed in buffer approach is cleaver and elegant. Good job Alan and Nicolas!. > From 9a6995fe9dcbb792a76fd8f0737a02d4d4015f82 Mon Sep 17 00:00:00 2001 > From: Alan Schmitt > Date: Mon, 22 Jul 2013 16:46:02 +0200 > Subject: [PATCH] Koma exporter: Ensure customization to LCO files are taken > into account > > * contrib/lisp/ox-koma-letter.el: Change default values to match the scrlttr2 > default values. Track which options are set in the file and only output the > corresponding options when they are changed. > --- > contrib/lisp/ox-koma-letter.el | 47 > +++--- > 1 file changed, 35 insertions(+), 12 deletions(-) > > diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el > index 44626a9..ff71bd3 100644 > --- a/contrib/lisp/ox-koma-letter.el > +++ b/contrib/lisp/ox-koma-letter.el > @@ -228,7 +228,7 @@ English manual of 2012-07-22)" > > > > -(defcustom org-koma-letter-use-backaddress t > +(defcustom org-koma-letter-use-backaddress nil >"Print return address in small line above to address." >:group 'org-export-koma-letter >:type 'boolean) > @@ -243,12 +243,12 @@ Use `foldmarks:true' to activate default fold marks or >:group 'org-export-koma-letter >:type 'string) > -(defcustom org-koma-letter-use-phone t > +(defcustom org-koma-letter-use-phone nil >"Print sender's phone number." >:group 'org-export-koma-letter >:type 'boolean) > > -(defcustom org-koma-letter-use-email t > +(defcustom org-koma-letter-use-email nil >"Print sender's email address." >:group 'org-export-koma-letter >:type 'boolean) Great! > @@ -287,9 +287,11 @@ Use `foldmarks:true' to activate default fold marks or > org-koma-letter-default-class > org-latex-default-class) t) > (:author "AUTHOR" nil (org-koma-letter--get-custom > org-koma-letter-author) t) > +(:author-changed-in-buffer-p "AUTHOR" nil nil t) > (:from-address "FROM_ADDRESS" nil nil newline) > (:phone-number "PHONE_NUMBER" nil org-koma-letter-phone-number) > (:email "EMAIL" nil (org-koma-letter--get-custom org-koma-letter-email) > t) > +(:email-changed-in-buffer-p "EMAIL" nil nil t) > (:to-address "TO_ADDRESS" nil nil newline) > (:place "PLACE" nil org-koma-letter-place) > (:opening "OPENING" nil org-koma-letter-opening) > @@ -306,9 +308,13 @@ Use `foldmarks:true' to activate default fold marks or > (:with-after-letter nil "after-letter-order" > org-koma-letter-special-tags-after-letter) > (:with-backaddress nil "backaddress" org-koma-letter-use-backaddress) > +(:with-backaddress-changed-in-buffer-p nil "backaddress" nil) > (:with-foldmarks nil "foldmarks" org-koma-letter-use-foldmarks) > +(:with-foldmarks-changed-in-buffer-p nil "foldmarks" nil) > (:with-phone nil "phone" org-koma-letter-use-phone) > +(:with-phone-changed-in-buffer-p nil "phone" nil) > (:with-email nil "email" org-koma-letter-use-email) > +(:with-email-changed-in-buffer-p nil "email" nil) > (:with-place nil "place" org-koma-letter-use-place) > (:with-subject nil "subject" org-koma-letter-subject-format)) >:translate-alist '((export-block . org-koma-letter-export-block) > @@ -522,11 +528,19 @@ holding export options." > info))) > (let ((lco (plist-get info :lco)) >(author (plist-get info :author)) > + (author-set (plist-get info :author-changed-in-buffer-p)) >(from-address (org-koma-letter--determine-special-value info 'from)) >(phone-number (plist-get info :phone-number)) >(email (plist-get info :email)) > + (email-set (plist-get info :email-changed-in-buffer-p)) >(signature (plist-get info :signature))) > (concat > + ;; author or email
Re: [O] koma letter exporter: changing the priority of options
alan.schm...@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?
Best,
Alan
>From 9a6995fe9dcbb792a76fd8f0737a02d4d4015f82 Mon Sep 17 00:00:00 2001
From: Alan Schmitt
Date: Mon, 22 Jul 2013 16:46:02 +0200
Subject: [PATCH] Koma exporter: Ensure customization to LCO files are taken
into account
* contrib/lisp/ox-koma-letter.el: Change default values to match the scrlttr2
default values. Track which options are set in the file and only output the
corresponding options when they are changed.
---
contrib/lisp/ox-koma-letter.el | 47 +++---
1 file changed, 35 insertions(+), 12 deletions(-)
diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 44626a9..ff71bd3 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -228,7 +228,7 @@ English manual of 2012-07-22)"
-(defcustom org-koma-letter-use-backaddress t
+(defcustom org-koma-letter-use-backaddress nil
"Print return address in small line above to address."
:group 'org-export-koma-letter
:type 'boolean)
@@ -243,12 +243,12 @@ Use `foldmarks:true' to activate default fold marks or
:group 'org-export-koma-letter
:type 'string)
-(defcustom org-koma-letter-use-phone t
+(defcustom org-koma-letter-use-phone nil
"Print sender's phone number."
:group 'org-export-koma-letter
:type 'boolean)
-(defcustom org-koma-letter-use-email t
+(defcustom org-koma-letter-use-email nil
"Print sender's email address."
:group 'org-export-koma-letter
:type 'boolean)
@@ -287,9 +287,11 @@ Use `foldmarks:true' to activate default fold marks or
org-koma-letter-default-class
org-latex-default-class) t)
(:author "AUTHOR" nil (org-koma-letter--get-custom org-koma-letter-author) t)
+(:author-changed-in-buffer-p "AUTHOR" nil nil t)
(:from-address "FROM_ADDRESS" nil nil newline)
(:phone-number "PHONE_NUMBER" nil org-koma-letter-phone-number)
(:email "EMAIL" nil (org-koma-letter--get-custom org-koma-letter-email) t)
+(:email-changed-in-buffer-p "EMAIL" nil nil t)
(:to-address "TO_ADDRESS" nil nil newline)
(:place "PLACE" nil org-koma-letter-place)
(:opening "OPENING" nil org-koma-letter-opening)
@@ -306,9 +308,13 @@ Use `foldmarks:true' to activate default fold marks or
(:with-after-letter nil "after-letter-order"
org-koma-letter-special-tags-after-letter)
(:with-backaddress nil "backaddress" org-koma-letter-use-backaddress)
+(:with-backaddress-changed-in-buffer-p nil "backaddress" nil)
(:with-foldmarks nil "foldmarks" org-koma-letter-use-foldmarks)
+(:with-foldmarks-changed-in-buffer-p nil "foldmarks" nil)
(:with-phone nil "phone" org-koma-letter-use-phone)
+(:with-phone-changed-in-buffer-p nil "phone" nil)
(:with-email nil "email" org-koma-letter-use-email)
+(:with-email-changed-in-buffer-p nil "email" nil)
(:with-place nil "place" org-koma-letter-use-place)
(:with-subject nil "subject" org-koma-letter-subject-format))
:translate-alist '((export-block . org-koma-letter-export-block)
@@ -522,11 +528,19 @@ holding export options."
info)))
(let ((lco (plist-get info :lco))
(author (plist-get info :author))
+ (author-set (plist-get info :author-changed-in-buffer-p))
(from-address (org-koma-letter--determine-special-value info 'from))
(phone-number (plist-get info :phone-number))
(email (plist-get info :email))
+ (email-set (plist-get info :email-changed-in-buffer-p))
(signature (plist-get info :signature)))
(concat
+ ;; author or email not set in file: may be overridden by lco
+ (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
(let ((lco-files (split-string lco " "))
@@ -535,11 +549,12 @@ holding export options."
(setq lco-def (format "%s\\LoadLetterOption{%s}\n" lco-def lco-file)))
lco-def))
;; Defin
Re: [O] koma letter exporter: changing the priority of options
n.goaz...@gmail.com writes: > Alan Schmitt writes: > >> This is a promising approach. Unfortunately I cannot make it work: >> email-changed-in-buffer-p is always equal to nil, even with an EMAIL in >> the buffer (which I see picked up during export). >> >> Here is what I have. This is the code to set up the EMAIL keyword: >> >> (:email "EMAIL" nil (org-koma-letter--get-custom org-koma-letter-email) >> t) >> (:email-changed-in-buffer-p "EMAIL" nil nil t) >> >> Do we agree there should be two entries for "EMAIL"? > > Yes. But ox.el assumed there could be only one property per keyword. > I removed this limitation. > > Could you pull latest Org and try again? Thanks a lot, it's indeed working. I'll rework my patch using this. Alan
Re: [O] koma letter exporter: changing the priority of options
Alan Schmitt writes: > This is a promising approach. Unfortunately I cannot make it work: > email-changed-in-buffer-p is always equal to nil, even with an EMAIL in > the buffer (which I see picked up during export). > > Here is what I have. This is the code to set up the EMAIL keyword: > > (:email "EMAIL" nil (org-koma-letter--get-custom org-koma-letter-email) t) > (:email-changed-in-buffer-p "EMAIL" nil nil t) > > Do we agree there should be two entries for "EMAIL"? Yes. But ox.el assumed there could be only one property per keyword. I removed this limitation. Could you pull latest Org and try again? Regards, -- Nicolas Goaziou
Re: [O] koma letter exporter: changing the priority of options
Hello Nicolas, n.goaz...@gmail.com writes: > Hello, > > Alan Schmitt 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? > > I didn't follow this thread closely, but to answer your question, you > can add the following option: > > (:email-changed-in-buffer-p "EMAIL" nil nil t) > > If (plist-get info :email-changed-in-buffer-p) is non-nil, email was set > from a buffer keyword. This is a promising approach. Unfortunately I cannot make it work: email-changed-in-buffer-p is always equal to nil, even with an EMAIL in the buffer (which I see picked up during export). Here is what I have. This is the code to set up the EMAIL keyword: (:email "EMAIL" nil (org-koma-letter--get-custom org-koma-letter-email) t) (:email-changed-in-buffer-p "EMAIL" nil nil t) Do we agree there should be two entries for "EMAIL"? Thanks, Alan
Re: [O] koma letter exporter: changing the priority of options
Hello, Alan Schmitt 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? I didn't follow this thread closely, but to answer your question, you can add the following option: (:email-changed-in-buffer-p "EMAIL" nil nil t) If (plist-get info :email-changed-in-buffer-p) is non-nil, email was set from a buffer keyword. Regards, -- Nicolas Goaziou
Re: [O] koma letter exporter: changing the priority of options
Hi Rasmus and Viktor,
listuse...@gmail.com writes:
> Hi,
>
> Alan Schmitt wrote:
>
>> - (format "\\KOMAoption{backaddress}{%s}\n" (if with-backaddress "true"
>> "false"))
>> - (format "\\KOMAoption{foldmarks}{%s}\n" (if with-foldmarks
>> with-foldmarks "false"))
>> - (format "\\KOMAoption{fromphone}{%s}\n" (if with-phone "true"
>> "false"))
>> - (format "\\KOMAoption{fromemail}{%s}\n" (if with-email "true"
>> "false"
>> + (if with-backaddress (format "\\KOMAoption{backaddress}{true}\n") "")
>> + (if (not (equal with-foldmarks "true")) (format
>> "\\KOMAoption{foldmarks}{%s}\n" with-foldmarks) "")
>> + (if with-phone (format "\\KOMAoption{fromphone}{true}\n") "")
>> + (if with-email (format "\\KOMAoption{fromemail}{true}\n") "")))
>
> If I read the patch correctly then the consequence is that you cannot
> configure your LCO file to set defaults for these values and inhibit
> them in specific letters by setting the corresponding option to nil. For
> example, in my LCO file I enable all of these options but sometimes I
> don't want to have foldmarks or a backaddress or whatever. So I can
> write #+OPTIONS: backaddress:nil and it is supressed. The patch changes
> that.
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?
Alan
Re: [O] koma letter exporter: changing the priority of options
Hi Viktor and Allan, >> I think we need to treat koma variables more generally (I have some >> sketches locally) if anything. Not make their behavior more >> specialized. > > Could you elaborate on what you mean by this? I want to be able to generate and set /any/ Koma variable from emacs, including making my own ones. Sometimes I use custom koma variables depending on the letter and my footer then looks for the values of the koma variables and typeset the footer depending on which variables are available. As "half" of current template sets koma variables, this seems like something worthwhile doing. I have a defun to set an arbitrary koma variables, but I haven't looked more into it. >> 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. > > That is a valid criticism. I'd rather not have data specified in the TeX > file that is overwritten later on. However, if you lose the LCO file, > presumably you can't regenerate the lettern anyway. Nah, but you still "wrong" data in your template. >> 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. > > That approach, in my view, seems overly complicated and also very > brittle. I not advocating for its inclusion as a general solution(!), but as a specific solution in the case where you don't want to set the user email to nil, but still want to use it some of the time. It's brittle to the extend that Texlive is brittle. Kpsewhich should find the files (running from the same folder) if latex can find them. Making the /location/ of a variable /in the output/ a function of whether it's one value or the other is an ugly hack IMO. (Same as the above, but the above you can keep in your own config file). If we want to go down that path a better way is to let the user decide on the relative importance of variables versus LCO files. 1. To let the placement of koma variables and lco files be configurable via special [BRACKET] keywords as in org-latex-class. 2. To let the preamble be "blocks", as with the end material (ps cc encl), and let users deceit the way they want material to come. E.g. if some variable is '(komavars lco) then lco is typeset before komavars. –Rasmus -- Dung makes an excellent fertilizer
Re: [O] koma letter exporter: changing the priority of options
Hi, Rasmus wrote: > I think we need to treat koma variables more generally (I have some > sketches locally) if anything. Not make their behavior more > specialized. Could you elaborate on what you mean by this? > 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. That is a valid criticism. I'd rather not have data specified in the TeX file that is overwritten later on. However, if you lose the LCO file, presumably you can't regenerate the lettern anyway. > 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. That approach, in my view, seems overly complicated and also very brittle. Cheers, Viktor > > –Rasmus > > -- > ツ >
Re: [O] koma letter exporter: changing the priority of options
Hi,
Alan Schmitt wrote:
> - (format "\\KOMAoption{backaddress}{%s}\n" (if with-backaddress "true"
> "false"))
> - (format "\\KOMAoption{foldmarks}{%s}\n" (if with-foldmarks
> with-foldmarks "false"))
> - (format "\\KOMAoption{fromphone}{%s}\n" (if with-phone "true" "false"))
> - (format "\\KOMAoption{fromemail}{%s}\n" (if with-email "true"
> "false"
> + (if with-backaddress (format "\\KOMAoption{backaddress}{true}\n") "")
> + (if (not (equal with-foldmarks "true")) (format
> "\\KOMAoption{foldmarks}{%s}\n" with-foldmarks) "")
> + (if with-phone (format "\\KOMAoption{fromphone}{true}\n") "")
> + (if with-email (format "\\KOMAoption{fromemail}{true}\n") "")))
If I read the patch correctly then the consequence is that you cannot
configure your LCO file to set defaults for these values and inhibit
them in specific letters by setting the corresponding option to nil. For
example, in my LCO file I enable all of these options but sometimes I
don't want to have foldmarks or a backaddress or whatever. So I can
write #+OPTIONS: backaddress:nil and it is supressed. The patch changes
that.
> 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.)
>
> I still have an issue with the default value for email. I have set-up my
> email address in emacs, and it's picked up by the koma exporter. I want
> to use a different address in my work letters (which use a custom lco
> file), but the email address is overridden by the one picked up by the
> following function:
>
> (defun org-koma-letter-email ()
> "Return the current `user-mail-address'"
> user-mail-address)
>
> What I propose is the following:
> - we leave the default AUTHOR and EMAIL at nil
> - 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
>
> 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.
>
> What do you think?
Seems fine by me.
Cheers,
Viktor
>
> Alan
>
Re: [O] koma letter exporter: changing the priority of options
Alan Schmitt 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 -- ツ
Re: [O] koma letter exporter: changing the priority of options
Hello,
ras...@gmx.us writes:
> Viktor Rosenfeld writes:
>
>>> ,
>>> | \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.
>
> Doesn't this also more or less correspond to the default value of
> scrlttr2? If so there's no reason to add it to the tex file and nil
> is indeed a better default.
It took me a while to look at this (basically until I had to write
another letter), but here is a patch I propose to commit to do this.
--8<---cut here---start->8---
diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 44626a9..8a98689 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -228,7 +228,7 @@ English manual of 2012-07-22)"
-(defcustom org-koma-letter-use-backaddress t
+(defcustom org-koma-letter-use-backaddress nil
"Print return address in small line above to address."
:group 'org-export-koma-letter
:type 'boolean)
@@ -243,12 +243,12 @@ Use `foldmarks:true' to activate default fold marks or
:group 'org-export-koma-letter
:type 'string)
-(defcustom org-koma-letter-use-phone t
+(defcustom org-koma-letter-use-phone nil
"Print sender's phone number."
:group 'org-export-koma-letter
:type 'boolean)
-(defcustom org-koma-letter-use-email t
+(defcustom org-koma-letter-use-email nil
"Print sender's email address."
:group 'org-export-koma-letter
:type 'boolean)
@@ -554,10 +554,10 @@ holding export options."
(with-phone (plist-get info :with-phone))
(with-email (plist-get info :with-email)))
(concat
- (format "\\KOMAoption{backaddress}{%s}\n" (if with-backaddress "true"
"false"))
- (format "\\KOMAoption{foldmarks}{%s}\n" (if with-foldmarks
with-foldmarks "false"))
- (format "\\KOMAoption{fromphone}{%s}\n" (if with-phone "true" "false"))
- (format "\\KOMAoption{fromemail}{%s}\n" (if with-email "true" "false"
+ (if with-backaddress (format "\\KOMAoption{backaddress}{true}\n") "")
+ (if (not (equal with-foldmarks "true")) (format
"\\KOMAoption{foldmarks}{%s}\n" with-foldmarks) "")
+ (if with-phone (format "\\KOMAoption{fromphone}{true}\n") "")
+ (if with-email (format "\\KOMAoption{fromemail}{true}\n") "")))
;; Document start
"\\begin{document}\n\n"
;; Subject
--8<---cut here---end--->8---
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.)
I still have an issue with the default value for email. I have set-up my
email address in emacs, and it's picked up by the koma exporter. I want
to use a different address in my work letters (which use a custom lco
file), but the email address is overridden by the one picked up by the
following function:
(defun org-koma-letter-email ()
"Return the current `user-mail-address'"
user-mail-address)
What I propose is the following:
- we leave the default AUTHOR and EMAIL at nil
- 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
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.
What do you think?
Alan
Re: [O] koma letter exporter: changing the priority of options
Viktor Rosenfeld writes:
>> ,
>> | \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.
Doesn't this also more or less correspond to the default value of
scrlttr2? If so there's no reason to add it to the tex file and nil
is indeed a better default.
–Rasmus
--
Hooray!
Re: [O] koma letter exporter: changing the priority of options
Viktor Rosenfeld writes: > 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. Yes, this would be a good choice. I'll do it, unless someone complains. Thanks, Alan
Re: [O] koma letter exporter: changing the priority of options
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
>
[O] koma letter exporter: changing the priority of options
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).
I propose to either change the priority to:
local options > lco file > emacs variables
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}
`
What do you think?
Alan
