From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lawrence Mitchell Subject: Re: unnumbered subsections in latex export Date: Wed, 23 Mar 2011 16:25:49 +0000 Message-ID: References: <20110322051038.21655c80@kuru.homelinux.net> <80d3lj9wj6.fsf@somewhere.org> <20110322053134.669127e9@kuru.homelinux.net> <8999.1300804510@alphaville.dokosmarshall.org> <20110322160814.227fc53f@bhishma.homelinux.net> <27844.1300836065@alphaville.usa.hp.com> <87ipv9gbst.fsf@gnu.org> <7864.1300892560@alphaville.dokosmarshall.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from [140.186.70.92] (port=58561 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q2Qsr-0000Yn-1C for emacs-orgmode@gnu.org; Wed, 23 Mar 2011 12:26:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q2Qso-00025V-87 for emacs-orgmode@gnu.org; Wed, 23 Mar 2011 12:26:08 -0400 Received: from lo.gmane.org ([80.91.229.12]:60352) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q2Qsn-00025H-QI for emacs-orgmode@gnu.org; Wed, 23 Mar 2011 12:26:06 -0400 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Q2Qsj-0000kp-PK for emacs-orgmode@gnu.org; Wed, 23 Mar 2011 17:26:01 +0100 Received: from e4300lm.epcc.ed.ac.uk ([129.215.63.156]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Mar 2011 17:26:01 +0100 Received: from wence by e4300lm.epcc.ed.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Mar 2011 17:26:01 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Nick Dokos wrote: > Bastien wrote: >> Hi Nick, >> Nick Dokos writes: >>> Suvayu Ali wrote: >>>> This works too, but Lawrence's patch makes it much easier and >>>> probably works for other export formats too. Thanks a lot. :) >>> No doubt Lawrence's patch can be extended to work for other exports, but >>> it's not there yet: each exporter would need a change similar to the one >>> that he made to the LaTeX exporter. >> Let's handle this change exporter by exporter. The longest trip starts >> with the first step :) > Sorry, I sent my previous comment without reading ahead for this. I still > would like to see some discussion on this, though. Here it is again: > This is probably obvious but I thought I'd make it explicit, both for > future wanderers and for further discussion: application of these > patches makes the behavior of different exporters potentially > inconsistent with each other. You can drop the potentially here! > IMO, it would be better to accumulate the patches and once all of the > exporters (or perhaps a critical mass: ascii, odt, docbook are the ones > I would like to see get patches, but opinions will vary) have patches, > then apply the whole thing in one commit (together with a documentation > patch). In the meantime, if anybody needs one of them (hi, Suvayu :-)), > they could carry it in their local branch. > Of course, there is no perfect consistency in any case between the exporters, > but I think at least making the effort to keep them consistent is better > than letting them diverge and possibly never converge again. I would agree whole-heartedly with these thoughts. I hadn't necessarily expected my patches to go in straight away, but offered them for perusal. However, this requirement may make it difficult to get new changes into the export system. For example, I'm uninterested in export to backends other than latex and html, so I'm only likely to implement a change for those targets. If no-one else is sufficiently interested in the change to pick up the ball for other backends, it may never get in. This is possibly a good thing (divergence of export functionality and all), but may slow the acceptance of new (useful?) features. For example, I don't know if the docbook backend explicitly writes section numbers in, or if the sectioning is left to the stylesheet. If the latter, can I mark sections as ones that should be numbered and ones that shouldn't? On a somewhat tangential note, while grovelling around in the latex and html backends, it seems to me that the export backends in general could do with some loving. It seems authors of the backends are unclear when to use option variables, when to get the data from the buffer-local options plist and so. This data is therefore treated inconsistently across backends, sometimes (plist-get opt-plist :option) is used, sometimes the default variable org-export-with-option is, sometimes neither are consulted. I'm not sufficiently excited by the grunt work to do anything about it, but maybe I should! Lawrence -- Lawrence Mitchell