From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Ordered List (Alphabetical) and HTML Export Date: Mon, 1 Jul 2013 16:29:14 +0200 Message-ID: <169A8CB7-A236-4EEC-B47B-9D262BB33BE3@gmail.com> References: <51a7a129.901a420a.1422.197b@mx.google.com> <87sizzp6j4.fsf@bzg.ath.cx> <871u7isjjr.fsf@gmail.com> <8738rymvrk.fsf@bzg.ath.cx> <87wqpaqz3c.fsf@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49647) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Utf6U-0004eE-TH for emacs-orgmode@gnu.org; Mon, 01 Jul 2013 10:29:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Utf6T-00011s-8o for emacs-orgmode@gnu.org; Mon, 01 Jul 2013 10:29:18 -0400 Received: from mail-wi0-x235.google.com ([2a00:1450:400c:c05::235]:53462) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Utf6T-0000z9-0M for emacs-orgmode@gnu.org; Mon, 01 Jul 2013 10:29:17 -0400 Received: by mail-wi0-f181.google.com with SMTP id hq4so3132891wib.14 for ; Mon, 01 Jul 2013 07:29:15 -0700 (PDT) In-Reply-To: <87wqpaqz3c.fsf@gmail.com> 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: Nicolas Goaziou Cc: Josiah Schwab , Bastien , emacs-orgmode@gnu.org On 1.7.2013, at 13:49, Nicolas Goaziou wrote: > Bastien writes: > >> Given that Org allows alphabetical list, the OP question is >> natural and will come back. > > Of course it will. And it had been discussed when the feature was > introduced. I don't mind discussing it again, but there's nothing new on > the table. I thought it had a FAQ entry: I was wrong. > >> There is no clue in Org that alphabetical lists are just visual clues. > > The manual is one clue. Quoting section "2.7 Plain lists" > > Org knows ordered lists, unordered lists, and description lists. > * _Unordered_ list items start with '-', '+', or '*'(1) as bullets. > * _Ordered_ list items start with a numeral followed by either a > period or a right parenthesis(2), such as '1.' or '1)'(3). If you > want a list to start with a different value (e.g., 20), start the > text of the item with '[@20]'(4). Those constructs can be used in > any item of the list in order to enforce a particular numbering. > * _Description_ list items are unordered list items, and contain the > separator ' :: ' to distinguish the description _term_ from the > description. > > "Alphabetical list" is only a footnote in this paragraph and clearly not > a type on its own. Merely a convenience. > >> I see no harm in supporting more flexibility where we can. > > Only where it makes sense: this is not Org's job to replace CSS. Org is > about structure, not appearance. Hi, as I have expressed earlier in a different thread, I think Nicolas is right here. The backend should decide how lists (ordered and unordered) are formatted, because this is the right way construct document structure. LaTeX and HTML are really the guide there. Lists are written with enumerate and itemize, and the style sets the bullets for different levels. When I write documents, I often choose only different types of bullets to make it easier for me to remember what level I am on. I think in almost all cases the structure created by a good document formatter will provide the cleanest and most readable output. So I would like to keep the current convention. If we must, we can have something like the [@N] to enforce a particular bullet style. - Carsten > > Also, I do see harm. Introducing a "feature" in one major back-end means > updating other major back-ends, for the sake of consistency. LaTeX (as > in "pdflatex") already does a good job to produce item markers. It is > also configurable. Enforcing it is almost certainly a bad idea anyway. > > Let's think about it. If user has a non-nil > `org-list-allow-alphabetical' and don't use them, should we make sure > that items are _never_ alphabetical in the output (i.e. always numbers)? > Also, what if users start asking for roman numbers as item markers? > Greek letters? Of course, Org doesn't provide them in the buffer, but > doesn't it sound silly to offer alphabetical lists only when so many > other types are supported by the targeted languages? Shouldn't back-ends > do the extra step in that direction? > > We must draw a clear line between what Org should and shouldn't do. IMO, > this patch is on the wrong side of the line. > >> Let me know what you think, > > I think the same as I did way back when we introduced this. I don't like > alphabetical lists and I don't think we should offer more support for > them. I would be happier if there was less possible bullets in Org > syntax. This probably won't happen, but I see no reason to make the > situation worse. > > > Regards, > > -- > Nicolas Goaziou >