From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rasmus Subject: Re: [patch] ox-koma-letter Date: Wed, 27 Feb 2013 13:13:25 +0100 Message-ID: <87wqtudkey.fsf@pank.iue.private> References: <87vc9gkund.fsf@pank.eu> <20130226123819.GQ24632@strey.biz> <87mwuqg4ln.fsf@pank.iue.private> <20130227105102.GV24632@strey.biz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:38651) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAftH-0004gi-Bt for emacs-orgmode@gnu.org; Wed, 27 Feb 2013 07:13:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UAftG-0004a2-84 for emacs-orgmode@gnu.org; Wed, 27 Feb 2013 07:13:43 -0500 Received: from plane.gmane.org ([80.91.229.3]:38941) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UAftG-0004Zp-0k for emacs-orgmode@gnu.org; Wed, 27 Feb 2013 07:13:42 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UAftY-0000JM-Mm for emacs-orgmode@gnu.org; Wed, 27 Feb 2013 13:14:00 +0100 Received: from 192.167.90.132 ([192.167.90.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Feb 2013 13:14:00 +0100 Received: from rasmus by 192.167.90.132 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Feb 2013 13:14:00 +0100 In-Reply-To: <20130227105102.GV24632@strey.biz> (Michael Strey's message of "Wed, 27 Feb 2013 11:51:02 +0100") 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: emacs-orgmode@gnu.org Michael, > I mean customized LCO files. For my former company I had made a > letter class for business letters based on scrlttr2.cls with two LCO > files. the first LCO file *company.lco* contained the general > information about the company (address, bank account, etc.). A > second LCO file *my_name.lco* contained the personal information of > (e-mail address, name, phone extension). With *my_name.lco* calling > *company.lco* the document class command for my letter finally was: > > \documentclass[my_name]{our_company_letter_class} > > With suitable setting of org-latex-classes not even the LCO feature > would be needed in ox-koma-letter. However I would leave it there for > more flexibility. That's cool. Personally, I like this approach. But while lco files are still readable they are not very nice. But not that terrible either. In fact to use the scrlttr2 support in Org I had to adjust a LCO files because it's currently loaded after LATEX_HEADER arguments (so all customization was overwritten). I didn't like that. > Yes, I can imagine such cases. My problem with the current > implementation was, that for instance, the phone number was preset in > org-latex-classes. That urged me to customize this variable although > everything was already well defined in *my_name.lco*. So, please take > care to preset such variables with nil, where nil shall have the > meaning > of 'ignore this variable'. I agree. This is anything but flexible, and I didn't even consider it. I also noted that there's a lot of silly defaults. So probably we should set everything to nil and do a "nil check" before inserting stuff into the TeX file. This would also make for a clearer output file, which is in itself something we should aim for. > Maybe we should write a user guide *before* further implementation > steps. I agree. A "question zero" is whether we eventually want to have an org-letter which could, in principle, output to something different than scrlttr2. Other things: - Cleaning defaults - Only insert KOMAVARs when non-nil. - Which variables to include. E.g. Michael's list vs. every komavar. - consider the order of KOMAVARs, e.g. do we really want LATEX_HEADER before LCO-like stuff? Do we want a KOMA_HEADER (or LETTER_HEADER) which comes after LCO? What to you think? > Mmmh ... never thought about this aspect. I simply dictated the order > of CC, ENCL and PS in my implementation. Thus your current > AFTER_CLOSING is the best solution, if you want to provide full > flexibility. Or having the order of ENCL, PS, CC and "AFTER_CLOSING" in the TeX file be governed by the order in the Org file. I guess this should be feasible, although I currently do not know how to code. I think it's desireable, though. –Rasmus -- When in doubt, do it!