emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]


From: Viktor Rosenfeld
Subject: Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]
Date: Tue, 21 May 2013 21:54:13 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Hi,

Rasmus wrote:

> Viktor Rosenfeld <address@hidden> writes:
> 
> > Actually, this patch does break LCO files. Now, if you don't set
> > AUTHOR or EMAIL in the letter the default options from the LaTeX
> > exporter always overwrite the settings defined in LCO files.
> 
> This one is tough. . .
> 
> One could #+INCLUDE an org-file but that's not really a fair comment.
> 
> I'm not really sure how to progress.
> 
> 1. One way would be do do a grep on the LCO files, but they might be
>    in the TeX PATH which would vary over TeX systems and OSes.

Way too complicated and brittle, IMHO.

> 2. Have people have empty AUTHOR and EMAIL if they've got the info in
>    an LCO file, but this is not desirable.  
>    - Supply an optional filter to remove this info ex-post, but how
>      would it know when to run?

Empty AUTHOR and EMAIL lines are not user-friendly. However, another
option is to set `user-mail-address' and `user-full-name' to nil, but
then this would also affect other areas of Emacs beside the LaTeX
expoerter (which I currently no use so I can't speak to side-effects).

> 3. Define some function to intelligently guess values based on
>    content.
>    1. Perhaps a TYPE variable.  So if TYPE is "business" or "causal"
>       and I select business a list with business-defaults would be
>       applied.  OTOH this might be too complicated to just writing a
>       LCO files. . .

Basically duplicates LCO files but will never achieve the same
functionality.

> 4. Revert the path.

Or 5, keep the change from SENDER to AUTHOR but revert the default
values to `org-koma-letter-*' variables. (Right now the AUTHOR and EMAIL
lines could be removed because they duplicate the derived latex
backend.)

> What should be the standard?  I'm compelled to go with "work as the
> LaTeX-backend", but it may not be optimal here if there's a need for
> chaining email and name regularly.

I prefer 5. :-)
 
> > Rasmus, couldn't you just set the old `org-koma-letter-sender'
> > option if you don't use LCO files?
> 
> Sure, I just thought it was inconsistent that the framework didn't use
> the same keywords as other backends.  But consistent might lack for
> good reasons.

The default LaTeX exporter does not have LCO files. Sure you can simply
\input a latex file but there is no dedicated support for this in Org
mode, is there? 

The LaTeX exporter also assumes that every LaTeX file needs a title, a
date, and an author, but this is not always true as the scrlttr2 class
shows (title, or subject, is definitely optional). Also, LaTeX blocks
which are evaluated separately don't need these values either. So I
understand striving for consistency, but I think that the use case here
is different enough to break it.

> For me the previous behavior was annoying since I usually don't set
> AUTHOR and this didn't work nicely.
> 
> > Also, I agree that SENDER should have been called AUTHOR. It was a
> > workaround because the LaTeX backend would ignore nil values for
> > AUTHOR in derived backends (but not for EMAIL, so I kept this). This
> > should now have been fixed.
> 
> OK.  So it's OK to switch to the AUTHOR keyword and just the default
> is what we need to settle on?

I think that switching from SENDER to AUTHOR, keeping the
`org-koma-letter-{author,email}' variables in the KOMA backend, but
setting them per default to `user-full-name' and `user-mail-address',
would solve both your problems and let me keep LCO files. I would then
simply set these `org-koma-letter-*' variables to `nil' and document
this setup in the docstring. I'll see tomorrow if this is feasable.

Cheers,
Viktor

> 
> –Rasmus
> 
> --
> . . . Stallman was indeed the tallest possible mountain and by
> standing on his shoulders you could see forever. . .
> 



reply via email to

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