From: Nick Dokos <nicholas.dokos@hp.com>
To: Richard Stanton <stanton@haas.berkeley.edu>
Cc: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>,
Jambunathan K <kjambunathan@gmail.com>
Subject: Re: Extra space between list items in HTML export
Date: Mon, 10 Sep 2012 20:52:00 -0400 [thread overview]
Message-ID: <12349.1347324720@alphaville.americas.hpqcorp.net> (raw)
In-Reply-To: Message from Richard Stanton <stanton@haas.berkeley.edu> of "Mon, 10 Sep 2012 16:39:18 PDT." <CC73C7A7.245CE%stanton@haas.berkeley.edu>
Richard Stanton <stanton@haas.berkeley.edu> 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---
next prev parent reply other threads:[~2012-09-11 0:52 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-10 21:23 Extra space between list items in HTML export Richard Stanton
2012-09-10 21:37 ` Nick Dokos
2012-09-10 22:39 ` Richard Stanton
2012-09-10 23:31 ` Jambunathan K
2012-09-10 23:39 ` Richard Stanton
2012-09-10 23:45 ` Jambunathan K
2012-09-10 23:47 ` Richard Stanton
2012-09-11 0:52 ` Nick Dokos [this message]
2012-09-11 7:30 ` Jambunathan K
2012-09-11 8:00 ` Nick Dokos
2012-09-18 7:26 ` Bastien
2012-09-18 14:34 ` Bastien
2012-09-18 13:26 ` Bastien
2012-09-18 16:13 ` Richard Stanton
2012-09-19 6:53 ` Bastien
2012-09-19 16:01 ` Richard Stanton
2012-09-19 16:45 ` Bastien
2012-09-19 20:55 ` Richard Stanton
2012-09-18 13:25 ` Bastien
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=12349.1347324720@alphaville.americas.hpqcorp.net \
--to=nicholas.dokos@hp.com \
--cc=emacs-orgmode@gnu.org \
--cc=kjambunathan@gmail.com \
--cc=stanton@haas.berkeley.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).