Re: Ordered List (Alphabetical) and HTML Export

[Nicolas Goaziou <n.goaziou@gmail.com>]

Bastien <bzg@gnu.org> 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?
>
> <ol type="I"> 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