From mboxrd@z Thu Jan 1 00:00:00 1970 From: Viktor Rosenfeld Subject: Re: koma letter exporter: changing the priority of options Date: Sat, 20 Jul 2013 13:58:35 +0200 Message-ID: <20130720115835.GB67549@kenny.local> References: <20130609180059.GA2104@kenny.local> <874nd6we8q.fsf@pank.eu> <87ppuetm2m.fsf@gmx.us> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43232) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0Vo9-0002Q0-RB for emacs-orgmode@gnu.org; Sat, 20 Jul 2013 07:58:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V0Vo8-00067x-1g for emacs-orgmode@gnu.org; Sat, 20 Jul 2013 07:58:41 -0400 Received: from mail-ea0-x233.google.com ([2a00:1450:4013:c01::233]:39424) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0Vo7-00067e-RT for emacs-orgmode@gnu.org; Sat, 20 Jul 2013 07:58:39 -0400 Received: by mail-ea0-f179.google.com with SMTP id b15so2921719eae.10 for ; Sat, 20 Jul 2013 04:58:39 -0700 (PDT) Content-Disposition: inline In-Reply-To: <87ppuetm2m.fsf@gmx.us> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Rasmus Cc: alan.schmitt@polytechnique.org, emacs-orgmode@gnu.org 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 > > -- > ツ >