ayg wrote:

Your proposed syntax would be messed up if someone started a numbered-list line
with an "x". I don't see why @ can't be used, though, if you really want more
wikimarkup. (This is doable by HTML, of course. <ol
type="a"><li>a<li>b<li>c...</ol> Also allows uppercase letters, and lowercase
and uppercase Roman numerals.)

Changed summary to more descriptive.

I support the proposal in comment #1 for "@" char as a markup for abc ordered lists.

@ lorem a. lorem
@ ipsum b. ipsum

lorem 1. lorem

#@ ipsum a. ipsum
#@# dolor 1. dolor
#@#@ sit a. sit

I don't see a huge requirement for adding yet more markup for relatively rare variants. Recommend WONTFIX.

(In reply to comment #3)

I don't see a huge requirement for adding yet more markup for relatively rare
variants. Recommend WONTFIX.

I can't agree with "relatively rare". Laws, bylaws, notices and other stuff like that usually use alphabetical ordered lists. And Wikisources contain this kind of and similar stuff. Wikibooks can contain abc lists if article/book creator decides to order items this way.

If the abc is in first level, it's pretty easily workaroundable by

<div class="abcordered">

1. foo
   1. bar
2. baz

</div>

but if you need to have lower levels abc ordered you must write the entire list in html. (Well yes, you could have x classes to set different levels, but it depends on admins, so users can't create such level in abc if it's not supported in global styles.)

ayg wrote:

We're very unlikely to add more wikimarkup like this, so closing WONTFIX as Brion recommended.

Are we closing bugs just because of lowering down the number of opened ones to say how successful we are in solving of bugs?

Three years old comment, even if Brion's with all the respect, can't be considered valid, or at least actual now, in the situation, when there was some growth of the software as well as of the team of people working on it.

I provided reasonable examples of why and when such markup would be useful.

One of the topics on developer's conference was "rewriting the parser". Apparently good opportunity for adding the requested feature.

Therefore reopening.

We should support
<ol>

1. lorem
2. ipsum
3. dolor

</ol>

Having that in, your alphabetically ordered lists would be done with <ol
type="a">

As a reminder, no new markup is required -- this already works in a wiki page:

<ol type="a">
<li> lorem
<li> ipsum
<li> dolor
</ol>

Especially given we're in a long-term move from low-level markup to structured text and richer editing, I still don't think there's any benefit from trying to think up and implement a second syntax for it.

(In reply to comment #7)

We should support
<ol>

1. lorem
2. ipsum
3. dolor

</ol>

Having that in, your alphabetically ordered lists would be done with <ol
type="a">

Well, I already saw the following weird construction mixing HTML and wikimarkup for ordered lists:

1. <li value="20"> 20th item
2. 21st item
3. 22nd item

I don't know if it's working on purpose or by mistake, however such mixing of code won't help newbies to understand and rather will discourage them from editing.

By mistake. Note that without tidy you get:

21. 20th item
22. 21st item
23. 22nd item

Would creating @ lists be easier?
We need a way to provide parameters to lists (start & type), which can be done in wiki syntax.
Having to to type <ol start=n> and use <li> instead of # is harder than only adding <ol start=n> (specially if you are changing an existing # list!).

Plus, it is consistent with the underlying HTML. There's a # per each <li>, and you may manually provide an specific <ol> before.

ayg wrote:

(In reply to comment #6)

Are we closing bugs just because of lowering down the number of opened ones to
say how successful we are in solving of bugs?

No, we're closing bugs as WONTFIX if we will refuse to accept patches for them because we believe they're a bad idea. That's what WONTFIX means.

Three years old comment, even if Brion's with all the respect, can't be
considered valid, or at least actual now, in the situation, when there was some
growth of the software as well as of the team of people working on it.

Brion's comment is still valid and I agree with it. We should not be adding more special-case wikimarkup to make parsing even harder. Where possible, we should be *removing* magic wikisyntax behavior (like RFC parsing, say). Wikisyntax is too complicated as-is. If you want anything other than the most super-basic effects, you can use HTML.

I provided reasonable examples of why and when such markup would be useful.

You can use HTML just fine in all cases.

One of the topics on developer's conference was "rewriting the parser".
Apparently good opportunity for adding the requested feature.

That's an orthogonal issue. It could be added just as easily now as in a rewrite. We shouldn't add it either way, because it's a bad idea to further complicate wikisyntax for marginal use-cases like this.

(In reply to comment #7)

We should support
<ol>

1. lorem
2. ipsum
3. dolor

</ol>

Having that in, your alphabetically ordered lists would be done with <ol
type="a">

This is still syntactic complication for no very good reason. Why not just use <li> instead of # here, once you explicitly use the <ol> and </ol>? It's not nearly as bad as trying to appropriate an unused character like @, though.

(In reply to comment #7)

We should support
<ol>

1. lorem
2. ipsum
3. dolor

</ol>

Having that in, your alphabetically ordered lists would be done with <ol
type="a">

This is still syntactic complication for no very good reason.

I mean a <ol> tag followed by #s (so it can get parameters). Not to force <ol> before #! A # not preceded by an <ol> would continue opening the <ol> by itself.

ayg wrote:

I know, but you're complicating wikisyntax by making that markup behave differently. It's an extra special case in the parser. That makes reimplementation in another parser harder, makes the parser slower, etc. Once users are already using <ol>, they may as well use <li> too instead of # -- it's not a big usability improvement IMO, so not worth it.

jnichols wrote:

I work on internal wikis for governments and the legal profession. They very often want nested ordered lists with numbers in the top level, lower-case letters in the second level, and lower-case roman numerals in the third level. I know that this can be done using HTML or some extensions, but teaching everyone in a large organization how to use new tags is very difficult, and seeing something like <ol type="a"> does scare away less computer-literate editors. I would love it if you could add wiki markup for lower-alpha and lower-roman ordered lists. Alternatively, it would be nice if was possible to change something in the CSS to make nested ordered lists follow the number->letter->roman pattern. As a third option, it would be nice if you could add a lower-alpha option to the visual editor so the HTML would be hidden.

Jeffery, you can configure the wiki for that with wiki-wide CSS.

Moving this under Parser component.

Closing as WONTFIX for the reasons described by Brion and Aryeh above. We are moving towards HTML5/RDFa with Parsoid and the Visual Editor, the HTML syntax is available already and site-wide CSS can be employed if that is too cumbersome.