Re: Ordered List (Alphabetical) and HTML Export

[Bastien <bzg@gnu.org>]

(I've removed the feature from maint (and master) so that we can take
the time to discuss it.)

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Bastien <bzg@altern.org> 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.

There is no clue in here.  The way it is, the manual seems to suggest
that alphabetical lists are supported (including in the export) as
long as you have (setq org-list-allow-alphabetical t).  We need to
make the manual more explicit here.

>> 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.

Structure vs. appearance is a useful distinction, but very often it is
overrated as a way to think about what a tool should/should not do.

> 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)?

Clearly no.

> Also, what if users start asking for roman numbers as item markers?

<ol type="I"> works fine.  There are solutions for LaTeX too.

> 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."

> 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.

The patch was too bold, I give you that :)

>> 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.

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."

Alphabetical lists are aesthetic sugar both in Org and its outputs,
and Org is nice because it tries to keep the input and output both 
structurally and aesthetically similar.

For example, horizontal lines in table are purely aesthetic, both
in Org and its output.  (They may have semantic value within the
document, but just as alphabetical bullets.)  Users expect Org to
do a good job at putting the right horizontal lines in the output
because it matters to them.

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.

Ok, end of rant, back to code :)

Thanks,

-- 
 Bastien