Re: [O] [PATCH] ox-koma-letter.el: Reintroduce variables removed in commit 832c6fd with proper defaults (was Re: [patch] ox-koma-letter.el: clean-up/semantic bug [4/4])

[Rasmus]

Alan Schmitt <address@hidden> writes:

> Hello,
>
> Viktor Rosenfeld writes:
>
>> Hi Robert,
>>
>> Robert Klein wrote:
>>
>>> Hi,
>>> 
>>> FWIW, from a users view it would be nice if:
>>> 
>>> - Use Author/Email information from org file
>>> - If not present use information from LCO file
>>> - if neither org file nor LCO file has any information use
>>>   user-full-name and user-email-address
>>> 
>>> Could this be solved by having several e.g. `setkomavar{fromname}'
>>> and so on in the tex file, so is created as follows:

I'd go with 'no'.  It's not aesthetically pleasing and I don't want my
output to look like LyX.  When feasible we should go for beautiful
output.  This isn't always the case at the moment, but still.
 
>>> if no #+AUTHOR in org-file and user-full-name is set:
>>>     add user-full-name
>>> if #+LCO(s) in org-file:
>>>     add LCO file(s)
>>> if #+AUTHOR in org-file:
>>>     add \setkomavar{fromname}{#+AUTHOR}
>>> ....  same for email

Currently the ordering is: #+AUTHOR > #+LCO and AUTHOR default to
(user-full-name).

On a side-note, Viktor: this seems to be the default in scrletter
anyway:
>>> add \setkomavar{signature}{\usekomavar{fromname}}
Could we remove it?  I'd like us to get to a more clean template (C-e
# koma-letter RET).

>> This is what is implemented by the latest patch
>> (http://thread.gmane.org/gmane.emacs.orgmode/72430/focus=72525).
>
> I'm waiting for Rasmus's confirmation that it works for him before
> committing it.

Thanks and sorry for the wait.  No it didn't work for me.  My user
name was always overwritten by "". . .  I couldn't figure out why.

I've attached a patch that work for me (it goes on top of Viktor's
patch 148c737ae79f3a98d8e93147c2d0ec0db3a2389a).  It allows for nil
and it gets up-to-date default values by default.  In my book it's a
bit more clean 'cause it doesn't rely on hooks.  It does, introduce a
new helper function to distinguish between a function value (which are
default for the two variables) and a string value (and nil for that
matter).  I don't know if this is undesirable.  It would crash if you
set the variables to a symbol that isn't nil and isn't a function.

It seems to work in mine and Viktor's use-case (to the best of my
testing ability).

–Rasmus

-- 
⠠⠵