From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: Extra space between list items in HTML export Date: Mon, 10 Sep 2012 20:52:00 -0400 Message-ID: <12349.1347324720@alphaville.americas.hpqcorp.net> References: Reply-To: nicholas.dokos@hp.com Return-path: Received: from eggs.gnu.org ([208.118.235.92]:51440) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBEhx-0006Vu-MD for emacs-orgmode@gnu.org; Mon, 10 Sep 2012 20:52:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TBEhw-0001eq-Da for emacs-orgmode@gnu.org; Mon, 10 Sep 2012 20:52:05 -0400 Received: from g6t0184.atlanta.hp.com ([15.193.32.61]:4401) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBEhw-0001em-8P for emacs-orgmode@gnu.org; Mon, 10 Sep 2012 20:52:04 -0400 In-Reply-To: Message from Richard Stanton of "Mon, 10 Sep 2012 16:39:18 PDT." 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: Richard Stanton Cc: "emacs-orgmode@gnu.org" , Jambunathan K Richard Stanton wrote: > Meanwhile, as I understand it (and as implemented in the old exporter), > h:2 should mean that only two levels of section headings should be created > at all. Level 3 should be an itemized list (and therefore, implicitly, > should not have a number). Thus, h:2 should imply n:2, I believe. >From my POV, it's not particularly important that the two knobs be linked: in fact, if they are linked too strongly, there should probably be just one knob; if they are linked but the linkage is weak, they become sources of confusion and misunderstanding. I think independent knobs make things easier most of the time and having to specify them explicitly in the #+OPTIONS: line helps make things unambiguous (and they are very useful when one revisits the file in six months, after having customized a bunch of things that would otherwise change the behaviour: I don't know about you but it's this kind of thing that gets me every time). What is *very* important is that all exporters treat them the *same* way. With Richard's example[fn:1] and the new exporter, we get different behavior with HTML and latex (without the num: option or with num:t): o the second list is unordered in HTML, but enumerated in latex. o we get third level section numbers decorating the list entries in HTML, but not in latex. Somebody needs to decide what the behavior should be, but then *every* exporter should behave the same way wrt that set of options. Sure, there will be situations where it will be impossible to keep them all compatible. Those will be exceptions, treated and documented as such. In particular, the common set of options in the manual should be sacrosanct. If a particular exporter decides to implement a private option, that's OK (there is a parallel with babel language headers here): add a description in worg on a page specific to that exporter. So there'll be three classes of options: o common - all exporters treat them the "same" way. o private. o incompatible - different exporters by necessity treat them differently. The third set should be as close to empty as humanly possible (and very carefully documented - in the manual, not on worg - if non-empty). OTOH, gratuitous differences should be squashed mercilessly. My 2 cents, Nick PS. Consistency may be the hobgoblin of little minds, but it's still very important. And Emerson said: "A foolish consistency ..." in any case :-) Footnotes: [fn:1] I reproduce it here for convenience: --8<---------------cut here---------------start------------->8--- #+OPTIONS: h:2 toc:nil * Example of itemized list ** Blank level 2 header - List 1 - List 2 - List 3 * Level 3 headings as itemized list, with extra space ** Blank level 2 header *** List 1 *** List 2 *** List 3 --8<---------------cut here---------------end--------------->8---