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 <alan.schm...@polytechnique.org> 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 > > -- > ⠠⠵ >