From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: Re: unnumbered subsections in latex export Date: Wed, 23 Mar 2011 12:42:20 -0400 Message-ID: <8930.1300898540@alphaville.dokosmarshall.org> 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> Reply-To: nicholas.dokos@hp.com Return-path: Received: from [140.186.70.92] (port=46179 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q2R8q-0002kP-0E for emacs-orgmode@gnu.org; Wed, 23 Mar 2011 12:42:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q2R8o-0006MV-89 for emacs-orgmode@gnu.org; Wed, 23 Mar 2011 12:42:39 -0400 Received: from vms173009pub.verizon.net ([206.46.173.9]:50395) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q2R8o-0006MH-4y for emacs-orgmode@gnu.org; Wed, 23 Mar 2011 12:42:38 -0400 Received: from alphaville.dokosmarshall.org ([unknown] [173.76.32.106]) by vms173009.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LII00MY5RQKTT50@vms173009.mailsrvcs.net> for emacs-orgmode@gnu.org; Wed, 23 Mar 2011 11:42:26 -0500 (CDT) In-reply-to: Message from Lawrence Mitchell of "Wed, 23 Mar 2011 16:25:49 -0000." 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: Lawrence Mitchell Cc: nicholas.dokos@hp.com, emacs-orgmode@gnu.org Lawrence Mitchell wrote: > > patches makes the behavior of different exporters potentially > > inconsistent with each other. > > You can drop the potentially here! > Well, some people might not use the feature... > > 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. > Yes, the equivalent of a DoS attack on org's progress: nobody wants that. One thing that might work for things like this is a git feature branch that contains the patches for the feature. That would allow people to pull from it and try it out. Once the feature is "complete" in some sense, the branch could be merged to the release branch. I'm not sure how much more work that would be for Bastien, but it seems to be a fairly widespread workflow in git circles (see e.g. http://nvie.com/posts/a-successful-git-branching-model/ for a pretty nice description.) > 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? > I don't know either - but I'll take a look at ascii and docbook at some point (although I hope somebody will beat me to it :-) ) And I'm sure Jambunathan will take care of the odt exporter. > > 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. +10 on that. > I'm not sufficiently excited by the grunt work to do > anything about it, but maybe I should! > You would have the undying gratitude of all of us. Isn't that motivation enough? :-) Thanks, Nick