Feature request: lists with letters

Feature request: lists with letters

[Titus von der Malsburg]

Items in lists can start with -, +, N), or N. (with N being an
integer).  It’s currently not possible, to use letters as in the
following examples:

a. First item
b. Second item

or

a) First item
b) Second item

I believe it would make sense to allow letters in org-mode because
that’s a very common way to label items in lists.  I know that this has
been discussed previously but to my knowledge there was no
resolution.  The counter argument against letters was that we wouldn’t
know what labels to use when there are more items than letters, but I
think this shouldn’t stop us.  Reasons:

a) Most lists have fewer items and cases where more than 26 labels are
   needed are rare.
b) If a list has more than 26 items, the user is free to switch to
   bullet points or numbers.
c) The limited number of letters hasn’t stopped people from using
   letters in many other contexts.  For example, LaTeX offers letters
   and people think it’s useful.
d) Similarly, people often use Roman numerals (e.g., iv.) although
   they also quickly become impractical (999 = CMXCIX).
e) In some (academic) contexts, e.g. in linguistics, letters are
   conventionally used to label items in lists.
f) Letters worked perfectly fine in this list.

As to the question what org mode should do if a list is two long for
letters: Here are two possible solutions:

a) Label all items beyond the 26th with z, to make it visually very
   salient that there are not enough letters.
b) Start over from letter a after z.
c) Count in base 26 using letters as digits: a … z aa … az ba … bz …

Personally, I would prefer solution c because it gives each item a
unique label to which we can refer.  But solutions a and b would be ok,
too.  It doesn’t really matter because this is just an uninteresting
edge case and we shouldn’t obsess about it when the default case (<=26
items) is complete unproblematic.

Thanks for considering this proposal.

  Titus

Re: Feature request: lists with letters

[Nicolas Goaziou]

Hello,

Titus von der Malsburg <malsburg@posteo.de> writes:

> Items in lists can start with -, +, N), or N. (with N being an
> integer).  It’s currently not possible, to use letters as in the
> following examples:
>
> a. First item
> b. Second item
>
> or
>
> a) First item
> b) Second item
>
> I believe it would make sense to allow letters in org-mode because
> that’s a very common way to label items in lists.  I know that this has
> been discussed previously but to my knowledge there was no
> resolution.  The counter argument against letters was that we wouldn’t
> know what labels to use when there are more items than letters, but I
> think this shouldn’t stop us.  Reasons:
>
> a) Most lists have fewer items and cases where more than 26 labels are
>    needed are rare.
> b) If a list has more than 26 items, the user is free to switch to
>    bullet points or numbers.
> c) The limited number of letters hasn’t stopped people from using
>    letters in many other contexts.  For example, LaTeX offers letters
>    and people think it’s useful.
> d) Similarly, people often use Roman numerals (e.g., iv.) although
>    they also quickly become impractical (999 = CMXCIX).
> e) In some (academic) contexts, e.g. in linguistics, letters are
>    conventionally used to label items in lists.
> f) Letters worked perfectly fine in this list.
>
> As to the question what org mode should do if a list is two long for
> letters: Here are two possible solutions:
>
> a) Label all items beyond the 26th with z, to make it visually very
>    salient that there are not enough letters.
> b) Start over from letter a after z.
> c) Count in base 26 using letters as digits: a … z aa … az ba … bz …
>
> Personally, I would prefer solution c because it gives each item a
> unique label to which we can refer.  But solutions a and b would be ok,
> too.  It doesn’t really matter because this is just an uninteresting
> edge case and we shouldn’t obsess about it when the default case (<=26
> items) is complete unproblematic.
>
> Thanks for considering this proposal.

This proposal was implemented exactly 6 years ago. See
`org-list-allow-alphabetical'.

They introduce false positives, so they are not allowed by default.
Also, they probably should be implemented visually (i.e., with overlays,
à la `org-bullets') not syntactically. Anyway, here they are.

Regards,

-- 
Nicolas Goaziou

Re: Feature request: lists with letters

[Titus von der Malsburg]

[-- Attachment #1: Type: text/plain, Size: 3960 bytes --]


On 2017-02-02 Thu 17:55, Nicolas Goaziou wrote:
> Hello,
>
> Titus von der Malsburg <malsburg@posteo.de> writes:
>
>> Items in lists can start with -, +, N), or N. (with N being an
>> integer).  It’s currently not possible, to use letters as in the
>> following examples:
>>
>> a. First item
>> b. Second item
>>
>> or
>>
>> a) First item
>> b) Second item
>>
>> I believe it would make sense to allow letters in org-mode because
>> that’s a very common way to label items in lists.  I know that this has
>> been discussed previously but to my knowledge there was no
>> resolution.  The counter argument against letters was that we wouldn’t
>> know what labels to use when there are more items than letters, but I
>> think this shouldn’t stop us.  Reasons:
>>
>> a) Most lists have fewer items and cases where more than 26 labels are
>>    needed are rare.
>> b) If a list has more than 26 items, the user is free to switch to
>>    bullet points or numbers.
>> c) The limited number of letters hasn’t stopped people from using
>>    letters in many other contexts.  For example, LaTeX offers letters
>>    and people think it’s useful.
>> d) Similarly, people often use Roman numerals (e.g., iv.) although
>>    they also quickly become impractical (999 = CMXCIX).
>> e) In some (academic) contexts, e.g. in linguistics, letters are
>>    conventionally used to label items in lists.
>> f) Letters worked perfectly fine in this list.
>>
>> As to the question what org mode should do if a list is two long for
>> letters: Here are two possible solutions:
>>
>> a) Label all items beyond the 26th with z, to make it visually very
>>    salient that there are not enough letters.
>> b) Start over from letter a after z.
>> c) Count in base 26 using letters as digits: a … z aa … az ba … bz …
>>
>> Personally, I would prefer solution c because it gives each item a
>> unique label to which we can refer.  But solutions a and b would be ok,
>> too.  It doesn’t really matter because this is just an uninteresting
>> edge case and we shouldn’t obsess about it when the default case (<=26
>> items) is complete unproblematic.
>>
>> Thanks for considering this proposal.
>
> This proposal was implemented exactly 6 years ago. See
> `org-list-allow-alphabetical'.
>
> They introduce false positives, so they are not allowed by default.
> Also, they probably should be implemented visually (i.e., with overlays,
> à la `org-bullets') not syntactically. Anyway, here they are.

Great, and thanks for the response.  I had actually checked the
documentation but it’s very easy to overlook the footnote in which this
is mentioned.

One issue with org-list-allow-alphabetical is that we get numbers
instead of letters when we export to HTML and LaTeX.  I saw the earlier
thread [0] that gives the reasoning for this but I find it
unsatisfying.  If Org allows us to distinguish between -, +, 1., 1), a.,
A., a), A), this should also be honored by the exporter.  Otherwise it’s
rather pointless to allow that distinction in the first place.

IMHO, a clean solution would be to either drop everything but - and
1. or to keep all these and make the exporters honor them.  The former
would breaks existing documents and is therefore out of the
question.  This leaves us with the second solution.

Any chance you are willing to reconsider the decision to ignore
allow-alphabetical during export?  I think it would be very useful to
have that.  I know there are other ways to get alphabetical bullets in
exported documents but they are all specific to certain export targets
and the beauty of Org mode is precisely that we can export to many
different targets.

Thank you for your work on Org mode.  I use it for everything and
without it, I just wouldn’t know what to do.

  Titus

[0] https://lists.gnu.org/archive/html/emacs-orgmode/2013-06/msg00221.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: Feature request: lists with letters

[Nicolas Goaziou]

Hello,

Titus von der Malsburg <malsburg@posteo.de> writes:

> One issue with org-list-allow-alphabetical is that we get numbers
> instead of letters when we export to HTML and LaTeX.  I saw the earlier
> thread [0] that gives the reasoning for this but I find it
> unsatisfying.  If Org allows us to distinguish between -, +, 1., 1), a.,
> A., a), A), this should also be honored by the exporter.

This is also why I dislike the feature.

> Otherwise it’s rather pointless to allow that distinction in the first
> place.

Exactly.

> IMHO, a clean solution would be to either drop everything but - and
> 1. or to keep all these and make the exporters honor them.  The former
> would breaks existing documents and is therefore out of the
> question.  This leaves us with the second solution.

I wouldn't rule that out. Breaking changes happen. We can provide tools
to fix existing documents.

Actually, I like the idea of keeping only "-" and "1.". We could
implement other bullet types as overlays.

> Any chance you are willing to reconsider the decision to ignore
> allow-alphabetical during export?

I still agree with Carsten in the thread you pointed out. Org document
is about structure. The bullet in about typesetting.

> I think it would be very useful to have that. I know there are other
> ways to get alphabetical bullets in exported documents but they are
> all specific to certain export targets and the beauty of Org mode is
> precisely that we can export to many different targets.

The beauty of Org is also to allow to control different export targets
in the same document.

I think this is a non-issue.

Regards,

-- 
Nicolas Goaziou                                                0x80A93738

Re: Feature request: lists with letters

[Titus von der Malsburg]

[-- Attachment #1: Type: text/plain, Size: 2409 bytes --]


On 2017-02-02 Thu 19:57, Nicolas Goaziou wrote:
> Hello,
>
> Titus von der Malsburg <malsburg@posteo.de> writes:
>
>> One issue with org-list-allow-alphabetical is that we get numbers
>> instead of letters when we export to HTML and LaTeX.  I saw the earlier
>> thread [0] that gives the reasoning for this but I find it
>> unsatisfying.  If Org allows us to distinguish between -, +, 1., 1), a.,
>> A., a), A), this should also be honored by the exporter.
>
> This is also why I dislike the feature.
>
>> Otherwise it’s rather pointless to allow that distinction in the first
>> place.
>
> Exactly.
>
>> IMHO, a clean solution would be to either drop everything but - and
>> 1. or to keep all these and make the exporters honor them.  The former
>> would breaks existing documents and is therefore out of the
>> question.  This leaves us with the second solution.
>
> I wouldn't rule that out. Breaking changes happen. We can provide tools
> to fix existing documents.
>
> Actually, I like the idea of keeping only "-" and "1.". We could
> implement other bullet types as overlays.
>
>> Any chance you are willing to reconsider the decision to ignore
>> allow-alphabetical during export?
>
> I still agree with Carsten in the thread you pointed out. Org document
> is about structure. The bullet in about typesetting.

Correct me if I’m wrong but there are a lot of things in Org that are
just about typesetting: *bold*, /italic/, _underlined_, =verbatim= and
~code~, +strike-through+.  Would you remove these things as well?

  Titus

>> I think it would be very useful to have that. I know there are other
>> ways to get alphabetical bullets in exported documents but they are
>> all specific to certain export targets and the beauty of Org mode is
>> precisely that we can export to many different targets.
>
> The beauty of Org is also to allow to control different export targets
> in the same document.
>
> I think this is a non-issue.
>
> Regards,
>
> --
> Nicolas Goaziou                                                0x80A93738


--
Dr. Titus von der Malsburg
Visiting Professor for Computational Psycholinguistics
Department of Linguistics
University of Potsdam, Germany
https://tmalsburg.github.io
PGP fingerprint: C34C 7364 EAAD 4752 FABA  35E6 AE34 59F3 C613 689D
GNU Ring ID: ring:a1494601ee7d214bdfd8105dca065aee6d653556

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: Feature request: lists with letters

[Nicolas Goaziou]

Titus von der Malsburg <malsburg@posteo.de> writes:

> Correct me if I’m wrong but there are a lot of things in Org that are
> just about typesetting: *bold*, /italic/, _underlined_, =verbatim= and
> ~code~, +strike-through+.  Would you remove these things as well?

I could argue that emphasis is not just about typesetting. It conveys
a meaning. How emphasis is rendered _is_ typesetting, however. For
example, "latex" and "beamer" export back-ends render bold text
differently.

Regards,

Re: Feature request: lists with letters

[Eric Abrahamsen]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Titus von der Malsburg <malsburg@posteo.de> writes:
>
>> Correct me if I’m wrong but there are a lot of things in Org that are
>> just about typesetting: *bold*, /italic/, _underlined_, =verbatim= and
>> ~code~, +strike-through+.  Would you remove these things as well?
>
> I could argue that emphasis is not just about typesetting. It conveys
> a meaning. How emphasis is rendered _is_ typesetting, however. For
> example, "latex" and "beamer" export back-ends render bold text
> differently.

It's similar to how HTML went from <i> and <b> to <emph> and <strong>.
The former were presentation directives. The latter are semantic
directives. They're practically the same, for reasons of backwards
compatibility, and conceptual continuity. Org's emphasis markers are
similar -- they *look* like presentation directives, but at this point
they're actually used as semantic directives.

Probably not helpful,
Eric

Re: Feature request: lists with letters

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 2880 bytes --]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Titus von der Malsburg <malsburg@posteo.de> writes:
>
>> One issue with org-list-allow-alphabetical is that we get numbers
>> instead of letters when we export to HTML and LaTeX.  I saw the earlier
>> thread [0] that gives the reasoning for this but I find it
>> unsatisfying.  If Org allows us to distinguish between -, +, 1., 1), a.,
>> A., a), A), this should also be honored by the exporter.
>
> This is also why I dislike the feature.
>
>> Otherwise it’s rather pointless to allow that distinction in the first
>> place.
>
> Exactly.
>
>> IMHO, a clean solution would be to either drop everything but - and
>> 1. or to keep all these and make the exporters honor them.  The former
>> would breaks existing documents and is therefore out of the
>> question.  This leaves us with the second solution.
>
> I wouldn't rule that out. Breaking changes happen. We can provide tools
> to fix existing documents.
>
> Actually, I like the idea of keeping only "-" and "1.". We could
> implement other bullet types as overlays.
>
>> Any chance you are willing to reconsider the decision to ignore
>> allow-alphabetical during export?
>
> I still agree with Carsten in the thread you pointed out. Org document
> is about structure. The bullet in about typesetting.

I must admit, I haven't read the thread mentioned, and I am sure
Carsten's point was correct, but orgmode is more and more used for
non-structure tasks. As an example I see the whole field of reproductive
research and scientific paper writing, which, in my opinion, has many
more elements than structure. Another example are html emails (like them
or not - I also dislike them) which people compose in org, or org as a
LaTeX frontend.

Exporting, i.e. typesetting and sharing, becomes much more important
these days and possibly as important as the structure.

In a nutshell: I agree with Titus' point and also would love to have
alphabetical bullets.

But it is for me not that important if they are alphabetical or numeric
in org - a simple command / which I could put in front of the list, and
*which could be interpreted by the exporter* to do the right thing for
this list would be fine, simmilar to bold, verbtin, ...
The implementation would then be in the exporter.

Cheers,

Rainer

>
>> I think it would be very useful to have that. I know there are other
>> ways to get alphabetical bullets in exported documents but they are
>> all specific to certain export targets and the beauty of Org mode is
>> precisely that we can export to many different targets.
>
> The beauty of Org is also to allow to control different export targets
> in the same document.
>
> I think this is a non-issue.
>
> Regards,

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 454 bytes --]

Re: Feature request: lists with letters

[Titus von der Malsburg]

[-- Attachment #1: Type: text/plain, Size: 3119 bytes --]



Eric Abrahamsen wrote:
>> Titus von der Malsburg <address@hidden> writes:
>>
>>> Correct me if I’m wrong but there are a lot of things in Org that are
>>> just about typesetting: *bold*, /italic/, _underlined_, =verbatim= and
>>> ~code~, +strike-through+.  Would you remove these things as well?
>>
>> I could argue that emphasis is not just about typesetting. It conveys
>> a meaning. How emphasis is rendered _is_ typesetting, however. For
>> example, "latex" and "beamer" export back-ends render bold text
>> differently.
>
>It's similar to how HTML went from <i> and <b> to <emph> and <strong>.
>The former were presentation directives. The latter are semantic
>directives. They're practically the same, for reasons of backwards
>compatibility, and conceptual continuity. Org's emphasis markers are
>similar -- they *look* like presentation directives, but at this point
>they're actually used as semantic directives.

Hi Eric,

I appreciate that it makes sense to make Org more consistent and to use
abstract principles to guide its design.  However, I’m not convinced by
the analogy to HTML since there are some crucial differences between Org
and HTML.

First, HTML is not supposed to be read by humans – it is code.  In
contrast to that, Org is supposed to be human readable and hence, it has
to deal with visual presentation to some degree.  And it actually does:
when I write *bold* in Emacs, a bold font is used.  Nicholas’ point that
Org’s bold has nothing to do with bold fonts is therefore not entirely
correct.  Bold clearly means bold in Org, even if the beamer exporter
interprets this otherwise (which I always found annoying).

Secondly, HTML can afford to be purely semantic because there is CSS to
deal with visual presentation.  In the case of Org, there is no such
thing as CSS, and the only solution is to litter the Org document with
LaTeX and HTML code.  Not appealing at all in my opinion.  Here is an
example to illustrate this:

#+BEGIN_SRC org
Sensation, perception, and memory are of particular
interest to which group of contemporary psychologists?

a. psychoanalysts
b. behaviorists
c. humanistic psychologists
d. cognitive psychologists

The correct answer is d. because …
#+END_SRC

For me and many others, this is a very common use case.  I challenge you
to implement this with current Org such that it will export correctly to
HTML and PDF.  If I’m not mistaken, this is non-trivial.  If there is no
clean and simple solution for this, this strongly suggests that Org
should do the pragmatic thing and support alphabetic bullet points
in its exporters.

More generally, I’m not convinced by the philosophy that Org should be
purely semantic markup and that its syntax should be changed to enforce
this even if this breaks existing documents (Nicholas’ preferred
solution).  Org clearly has a certain WYSIWYG quality and precisely that
is one of the reasons for its success.  We should embrace the fact that
Org is differnt from HTML and not force it to be something that it
isn’t.

  Titus

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: Feature request: lists with letters

[Eric S Fraga]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

On Friday,  3 Feb 2017 at 11:37, Titus von der Malsburg wrote:

[...]

> For me and many others, this is a very common use case.  I challenge you
> to implement this with current Org such that it will export correctly to
> HTML and PDF.  If I’m not mistaken, this is non-trivial.  If there is no

#+begin_src org
  Sensation, perception, and memory are of particular
  interest to which group of contemporary psychologists?

  1. psychoanalysts
  2. behaviorists
  3. humanistic psychologists
  4. <<answer>> cognitive psychologists

  The correct answer is [[answer]] because 
#+end_src

does the job for both LaTeX and HTML although with a number in this
case.  I have not tried with alphabetical enumeration.

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 26.0.50.1, Org release_9.0.3-262-g5210de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 162 bytes --]

Re: Feature request: lists with letters

[Titus von der Malsburg]

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]


On 2017-02-03 Fri 12:40, Eric S Fraga wrote:
> On Friday,  3 Feb 2017 at 11:37, Titus von der Malsburg wrote:
>
> [...]
>
>> For me and many others, this is a very common use case.  I challenge you
>> to implement this with current Org such that it will export correctly to
>> HTML and PDF.  If I’m not mistaken, this is non-trivial.  If there is no
>
> #+begin_src org
>   Sensation, perception, and memory are of particular
>   interest to which group of contemporary psychologists?
>
>   1. psychoanalysts
>   2. behaviorists
>   3. humanistic psychologists
>   4. <<answer>> cognitive psychologists
>
>   The correct answer is [[answer]] because 
> #+end_src
>
> does the job for both LaTeX and HTML although with a number in this
> case.  I have not tried with alphabetical enumeration.

This is nice, but letters are conventionally used in many contexts and I
think making it work with letters is much harder.

  Titus



-- 
Dr. Titus von der Malsburg
Visiting Professor for Computational Psycholinguistics
Department of Linguistics
University of Potsdam, Germany
https://tmalsburg.github.io
PGP fingerprint: C34C 7364 EAAD 4752 FABA  35E6 AE34 59F3 C613 689D
GNU Ring ID: ring:a1494601ee7d214bdfd8105dca065aee6d653556

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: Feature request: lists with letters

[William Denton]

On 3 February 2017, Rainer M Krug wrote:

> I must admit, I haven't read the thread mentioned, and I am sure
> Carsten's point was correct, but orgmode is more and more used for
> non-structure tasks. As an example I see the whole field of reproductive
> research and scientific paper writing, which, in my opinion, has many
> more elements than structure. Another example are html emails (like them
> or not - I also dislike them) which people compose in org, or org as a
> LaTeX frontend.
>
> Exporting, i.e. typesetting and sharing, becomes much more important
> these days and possibly as important as the structure.
>
> In a nutshell: I agree with Titus' point and also would love to have
> alphabetical bullets.

I'm all in favour too, and hope that someone might implement this.

Bill
-- 
William Denton :: Toronto, Canada :: https://www.miskatonic.org/
Caveat lector.

Re: Feature request: lists with letters

[Rasmus]

Titus von der Malsburg <malsburg@posteo.de> writes:

> On 2017-02-03 Fri 12:40, Eric S Fraga wrote:
>> On Friday,  3 Feb 2017 at 11:37, Titus von der Malsburg wrote:
>>
>
>> [...]
>>
>>> For me and many others, this is a very common use case.  I challenge you
>>> to implement this with current Org such that it will export correctly to
>>> HTML and PDF.  If I’m not mistaken, this is non-trivial.  If there is no
>>
>> #+begin_src org
>>   Sensation, perception, and memory are of particular
>>   interest to which group of contemporary psychologists?
>>
>>   1. psychoanalysts
>>   2. behaviorists
>>   3. humanistic psychologists
>>   4. <<answer>> cognitive psychologists
>>
>>   The correct answer is [[answer]] because 
>> #+end_src
>>
>> does the job for both LaTeX and HTML although with a number in this
>> case.  I have not tried with alphabetical enumeration.
>
> This is nice, but letters are conventionally used in many contexts and I
> think making it work with letters is much harder.

You could use this:

    #+html_head: <style>ol {list-style-type: lower-latin;}</style>
    #+latex_header: \renewcommand{\theenumi}{\alph{enumi}}

The answer link would render wrongly in html, though.  I'm don't know if
there's an easy way to get the correct "label" for a list item with
html/js.

Rasmus

-- 
Slaa Patienten ihjel, saa siger Feberen Pas

Re: Feature request: lists with letters

[Titus von der Malsburg]

[-- Attachment #1: Type: text/plain, Size: 1920 bytes --]


On 2017-02-06 Mon 15:34, Rasmus wrote:
> Titus von der Malsburg <malsburg@posteo.de> writes:
>
>> On 2017-02-03 Fri 12:40, Eric S Fraga wrote:
>>> On Friday,  3 Feb 2017 at 11:37, Titus von der Malsburg wrote:
>>>
>>
>>> [...]
>>>
>>>> For me and many others, this is a very common use case.  I challenge you
>>>> to implement this with current Org such that it will export correctly to
>>>> HTML and PDF.  If I’m not mistaken, this is non-trivial.  If there is no
>>>
>>> #+begin_src org
>>>   Sensation, perception, and memory are of particular
>>>   interest to which group of contemporary psychologists?
>>>
>>>   1. psychoanalysts
>>>   2. behaviorists
>>>   3. humanistic psychologists
>>>   4. <<answer>> cognitive psychologists
>>>
>>>   The correct answer is [[answer]] because
>>> #+end_src
>>>
>>> does the job for both LaTeX and HTML although with a number in this
>>> case.  I have not tried with alphabetical enumeration.
>>
>> This is nice, but letters are conventionally used in many contexts and I
>> think making it work with letters is much harder.
>
> You could use this:
>
>     #+html_head: <style>ol {list-style-type: lower-latin;}</style>
>     #+latex_header: \renewcommand{\theenumi}{\alph{enumi}}
>
> The answer link would render wrongly in html, though.  I'm don't know if
> there's an easy way to get the correct "label" for a list item with
> html/js.

That’s a neat hack that might come in handy at some point.  However, it
changes the bullet point to letters for /all/ ordered lists in the
document, not just for those that use letters in the org source.

I think this shows that it’s indeed too difficult to make lists with
letters although such lists are fairly common and even standard in some
areas.  A small change in the exporters could solve this issue and make
Org mode more useful.  I don’t see any downsides.

  Titus

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: Feature request: lists with letters

[Rasmus]

Titus von der Malsburg <malsburg@posteo.de> writes:

> That’s a neat hack that might come in handy at some point.  However, it
> changes the bullet point to letters for /all/ ordered lists in the
> document, not just for those that use letters in the org source.

Yes, I use the simplest possible example.  Here's an example that changes
it for one list at the cost of an extra package.

#+latex_header: \usepackage[shortlabels]{enumitem}
#+attr_latex: :options [a.]
1. one
2. two
3. three


-- 
It was you, Jezebel, it was you

Re: Feature request: lists with letters

[Titus von der Malsburg]

[-- Attachment #1: Type: text/plain, Size: 959 bytes --]


On 2017-02-09 Thu 09:29, Rasmus wrote:
> Titus von der Malsburg <malsburg@posteo.de> writes:
>
>> That’s a neat hack that might come in handy at some point.  However, it
>> changes the bullet point to letters for /all/ ordered lists in the
>> document, not just for those that use letters in the org source.
>
> Yes, I use the simplest possible example.  Here's an example that changes
> it for one list at the cost of an extra package.
>
> #+latex_header: \usepackage[shortlabels]{enumitem}
> #+attr_latex: :options [a.]
> 1. one
> 2. two
> 3. three

Again, this is nice and honestly I admire your skill and knowledge.  But
this solution only works for LaTeX export and not for HTML and other
targets.  When I start writing documents, I often do not even know what
the target is eventually going to be.  Also, I often export org to
multiple targets, for example, my lecture notes are usually exported to
HTML and to PDF.

  Titus

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: Feature request: lists with letters

[Nicolas Goaziou]

Hello,

Titus von der Malsburg <malsburg@posteo.de> writes:

> On 2017-02-09 Thu 09:29, Rasmus wrote:
>> Titus von der Malsburg <malsburg@posteo.de> writes:
>>
>>> That’s a neat hack that might come in handy at some point.  However, it
>>> changes the bullet point to letters for /all/ ordered lists in the
>>> document, not just for those that use letters in the org source.
>>
>> Yes, I use the simplest possible example.  Here's an example that changes
>> it for one list at the cost of an extra package.
>>
>> #+latex_header: \usepackage[shortlabels]{enumitem}
>> #+attr_latex: :options [a.]
>> 1. one
>> 2. two
>> 3. three
>
> Again, this is nice and honestly I admire your skill and knowledge.  But
> this solution only works for LaTeX export and not for HTML and other
> targets.  When I start writing documents, I often do not even know what
> the target is eventually going to be.  Also, I often export org to
> multiple targets, for example, my lecture notes are usually exported to
> HTML and to PDF.

For multiple outputs, you can stack #+attr_ lines, e.g.;

  #+attr_latex: :options [a.]
  #+attr_html: some clever code which I don't know.
  1. one
  2. two

Again, I'm sure it is useful for some documents, but I don't think Org
should provide such WYSIWYG feature. It simply is out of its scope. What
would be next? Provide two different bullet types in the output when the
document also uses two of them?

The point, however, is that it is probably already possible to have
alphabetical lists in the output, as Rasmus pointed out. You may not
dismiss the hints given to you so quickly. It could solve your problem,
only not the way you're expecting it to be solved.

Anyway, I'm not opposed to apply tweaks to back-end if needed. What I'm
opposed to, however, is to _guarantee_,even with a defcustom, that
alphabetical lists in the document become alphabetical lists in the
output.

It is also possible to create your own extended back-ends that generate
alphabetical lists. You might also want to share them here.

Regards,

-- 
Nicolas Goaziou

Re: Feature request: lists with letters

[Eric S Fraga]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

On Saturday, 11 Feb 2017 at 01:20, Nicolas Goaziou wrote:

[...]

> Again, I'm sure it is useful for some documents, but I don't think Org
> should provide such WYSIWYG feature.

Just to let you know that I completely support this statement.  If
people want a word processor, there are plenty about and I would not
want the effort of all those working on org to have their efforts
diluted in this direction.  I do, however, understand the desire for
such features so I am in no way denigrating those that wish for these
extra features.

Being able to customise back end exporters already provides an
incredible amount of tailoring to specific users' requirements.  

While I'm at it, Nicolas, thanks for all your work on org!

eric
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 26.0.50.1, Org release_9.0.4-242-g2c27b8

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: Feature request: lists with letters

[Rasmus]

Hi,

>   #+attr_html: some clever code which I don't know.

Probably `org-html-begin-plain-list' would need to patched to accept
:class or :style.  In general it might be nicer to accept those in more
places.  Then one could do either

"#+attr_html: :class alpha" (with corresponding css) or "#+attr_html:
:style list-style-type: lower-alpha;".

For html in particular, one would need to change the reference label in
the output to match the type of the list.  E.g. if <<point>> is an
lower-alpha type the textContent of [[ref]] must be adjusted.  This is
just how html is.  JS could solve it at display-time, of one could use a
filter to add the right label (shouldn't be too hard as the item element
already have a :bullet in the plist).  

One could also use a prep. filter to add the correct #+attr_ lines at the
necessary places.

IOW the problems are all fairly easy to deal with once we've added :style
and :class support to more places in ox-html.

Rasmus

-- 
Dobbelt-A

Re: Feature request: lists with letters

[Nicolas Goaziou]

Hello,

Rasmus <rasmus@gmx.us> writes:

> IOW the problems are all fairly easy to deal with once we've added :style
> and :class support to more places in ox-html.

Great. Would you, or anyone else, be interested in working on this?

Regards,

-- 
Nicolas Goaziou

Re: Feature request: lists with letters

[Rasmus]

[-- Attachment #1: Type: text/plain, Size: 370 bytes --]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Rasmus <rasmus@gmx.us> writes:
>
>> IOW the problems are all fairly easy to deal with once we've added :style
>> and :class support to more places in ox-html.
>
> Great. Would you, or anyone else, be interested in working on this?

Here's a quick attempt.  Do you want me to push it?

Rasmus

-- 
Bang bang

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-html-plain-list-supports-arbitrary-attributes.patch --]
[-- Type: text/x-diff, Size: 2892 bytes --]

From 0760016f2b100f4050e16f5682eca305178f3494 Mon Sep 17 00:00:00 2001
From: Rasmus <rasmus@gmx.us>
Date: Mon, 13 Feb 2017 17:52:38 +0100
Subject: [PATCH] ox-html: plain list supports arbitrary attributes

* lisp/ox-html.el (org-html-plain-list-type): New defconst.
(org-html-begin-plain-list):
(org-html-plain-list):
(org-html-end-plain-list): Use new defconst and support attributes.
---
 lisp/ox-html.el | 37 +++++++++++++++++++++----------------
 1 file changed, 21 insertions(+), 16 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index ef8c9b546..1f3def999 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -449,6 +449,10 @@ You can use `org-html-head' and `org-html-head-extra' to add to
 this style.  If you don't want to include this default style,
 customize `org-html-head-include-default-style'.")
 
+(defconst org-html-plain-list-type
+  '(ordered "ol" unordered "ul" descriptive "dl")
+  "Plist of Org and html list types.")
+
 \f
 ;;; User Configuration Variables
 
@@ -3138,34 +3142,35 @@ the plist used as a communication channel."
 
 ;;;; Plain List
 
-;; FIXME Maybe arg1 is not needed because <li value="20"> already sets
-;; the correct value for the item counter
-(defun org-html-begin-plain-list (type &optional arg1)
+(defun org-html-begin-plain-list (type &optional attributes)
   "Insert the beginning of the HTML list depending on TYPE.
 When ARG1 is a string, use it as the start parameter for ordered
 lists."
-  (pcase type
-    (`ordered
-     (format "<ol class=\"org-ol\"%s>"
-	     (if arg1 (format " start=\"%d\"" arg1) "")))
-    (`unordered "<ul class=\"org-ul\">")
-    (`descriptive "<dl class=\"org-dl\">")))
+  (let* ((html-type (plist-get org-html-plain-list-type type))
+	 (html-class (format "org-%s" html-type)))
+    (format "<%s %s>"
+	    html-type
+	    (org-html--make-attribute-string
+	     (plist-put attributes :class
+			(org-trim
+			 (mapconcat 'identity
+				    (list html-class (plist-get attributes :class))
+				    " ")))))))
 
 (defun org-html-end-plain-list (type)
   "Insert the end of the HTML list depending on TYPE."
-  (pcase type
-    (`ordered "</ol>")
-    (`unordered "</ul>")
-    (`descriptive "</dl>")))
+  (format "</%s>" (plist-get org-html-plain-list-type type)))
 
 (defun org-html-plain-list (plain-list contents _info)
   "Transcode a PLAIN-LIST element from Org to HTML.
 CONTENTS is the contents of the list.  INFO is a plist holding
 contextual information."
-  (let ((type (org-element-property :type plain-list)))
+  (let* ((type (org-element-property :type plain-list))
+	 (attributes (org-export-read-attribute :attr_html plain-list)))
     (format "%s\n%s%s"
-	    (org-html-begin-plain-list type)
-	    contents (org-html-end-plain-list type))))
+	    (org-html-begin-plain-list type attributes)
+	    contents
+	    (org-html-end-plain-list type))))
 
 ;;;; Plain Text
 
-- 
2.11.1

Re: Feature request: lists with letters

[Nicolas Goaziou]

Hello,

Rasmus <rasmus@gmx.us> writes:

> Here's a quick attempt.  Do you want me to push it?

Thank you. Some minor comments below. Feel free to push whenever you
think this is good enough.

> +(defconst org-html-plain-list-type
> +  '(ordered "ol" unordered "ul" descriptive "dl")
> +  "Plist of Org and html list types.")

I think this is not needed.  We should merge `org-html-begin-plain-list'
and `org-html-end-plain-list' into `org-html-plain-list'. There is no
reason to split it.

As a consequence, we can compute "ol", "ul" or "dl" at the beginning of
`org-html-plain-list' and be done with it.

> +  (let* ((html-type (plist-get org-html-plain-list-type type))
> +	 (html-class (format "org-%s" html-type)))
> +    (format "<%s %s>"
> +	    html-type
> +	    (org-html--make-attribute-string
> +	     (plist-put attributes :class
> +			(org-trim
> +			 (mapconcat 'identity

#'identity

> +				    (list html-class (plist-get attributes :class))
> +				    " ")))))))
>  
>  (defun org-html-end-plain-list (type)
>    "Insert the end of the HTML list depending on TYPE."
> -  (pcase type
> -    (`ordered "</ol>")
> -    (`unordered "</ul>")
> -    (`descriptive "</dl>")))
> +  (format "</%s>" (plist-get org-html-plain-list-type type)))

See. There is no need to make this one-liner a separate function, IMO.


Regards,

-- 
Nicolas Goaziou

Re: Feature request: lists with letters

[Rasmus]

Hi,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Thank you. Some minor comments below. Feel free to push whenever you
> think this is good enough.

OK, I pushed the patch.

>> +(defconst org-html-plain-list-type
>> +  '(ordered "ol" unordered "ul" descriptive "dl")
>> +  "Plist of Org and html list types.")
>
> I think this is not needed.  We should merge `org-html-begin-plain-list'
> and `org-html-end-plain-list' into `org-html-plain-list'. There is no
> reason to split it.

The reason they were split was that the -begin- and -end- function were
used in the headline function.  I removed that dependency now.

> #'identity

I always forget the "#"!

Rasmus

-- 
9000!

Re: Feature request: lists with letters

[Nicolas Goaziou]

Hello,

Rasmus <rasmus@gmx.us> writes:

> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> Thank you. Some minor comments below. Feel free to push whenever you
>> think this is good enough.
>
> OK, I pushed the patch.

Thank you.

Regards,

-- 
Nicolas Goaziou