From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Ordered List (Alphabetical) and HTML Export Date: Mon, 01 Jul 2013 15:49:35 +0200 Message-ID: <87mwq6qtjk.fsf@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> <87hageh243.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37332) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UteTu-00007X-Oe for emacs-orgmode@gnu.org; Mon, 01 Jul 2013 09:49:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UteTr-0002yX-Vp for emacs-orgmode@gnu.org; Mon, 01 Jul 2013 09:49:26 -0400 In-Reply-To: <87hageh243.fsf@bzg.ath.cx> (Bastien's message of "Mon, 01 Jul 2013 14:54:36 +0200") 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: Bastien Cc: Josiah Schwab , emacs-orgmode@gnu.org Bastien writes: > (I've removed the feature from maint (and master) so that we can take > the time to discuss it.) Fair enough. >> 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)? > > Clearly no. Interesting. As you know, pdflatex will produce, at some levels, alpha bullets for ordered lists, unless told otherwise. So, a. Item exported to 1. Item is wrong (hence your patch), but 1. Item exported to (a) Item isn't wrong (according to your answer). I just cannot make sense out of it. Either Org controls totally its output (my head hurts just thinking about it) or it doesn't. Your patch stands in-between: it's confusing. >> Also, what if users start asking for roman numbers as item markers? > >
    works fine. There are solutions for LaTeX too. Of course there are solutions. For ODT, too. But I certainly don't want to open that can of worms. >> 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? > > No. This users can clearly understand: there are (at least human) > limits to what we can implement. But this is different that saying > him: "Exporting a) b) c) as 1. 2. 3. is a feature, not a bug." That's not what we are telling him. Likewise, we are not promising that exporting a "- " item will always call for a hyphen in the output: it may be a bullet instead. The only promise wrt bullet type and export is: export will preserve `ordered', `unordered' and `description' status of plain lists. That's all. Supporting this "simple" thing already requires hundreds lines of code in some export back-ends. Currently, in Org syntax, "a) b) c)" is an alias for "ordered list", as "1) 2) 3)". > I would perfectly understand that it's too much maintainance ahead. > This sounds perfectly reasonable to me -- and (perhaps paradoxically) > less arbitrary than "this does not fit Org's function, this is only > aesthetic." OK. Count me in the "too much maintenance ahead", then. > Alphabetical lists are aesthetic sugar both in Org and its outputs, I do not agree with "and its outputs" part, since there was nothing in this direction before your patch. > and Org is nice because it tries to keep the input and output both > structurally and aesthetically similar. Does it? In Beamer back-end, a block is very different, visually speaking, from a headline. > Now: I tend to draw the line between what matters to users and what > does not matter, not using the structure vs. aesthetic distinction, > which is very relative. IOW, I'd ask the users if then want it or > not. There can be no line between "what matters to users" and "what does not", because wherever you may put that line, someone will always be interested in a feature on the other side. Tell me about relative distinctions ;) I'll take "structure vs. aesthetics" anytime, because you can always argue about it. On the other hand, there's not much to say when someone tells you: "this feature is very important in my daily work, let's provide it". > Ok, end of rant, back to code :) Whatever the conclusion of this thread is, I hope it will make for a FAQ entry so we do not start it over every now and then. Regards, -- Nicolas Goaziou