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])

[Viktor Rosenfeld]

Hi Rasmus,

Rasmus wrote:

> The following message is a courtesy copy of an article
> that has been posted to gmane.emacs.orgmode as well.
> 
> 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.

I agree that there should not be multiple instances of, e.g.,
\setkomavar{fromname} in the TeX file. I must have overlooked that bit
in the original mail.

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

I think so, yes.

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

Hmm, that's too bad. I tested it pretty thoroughly. Could you maybe
trace the contents of the variable by adding calls to message in various
places?
 
> 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.

Did you send the patch? I did not receive it and it's not available on
gmane.

Cheers,
Viktor

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