Re: [O] Feature request: lists with letters
Hello, Rasmuswrites: > Nicolas Goaziou 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
Re: [O] Feature request: lists with letters
Hi, Nicolas Goaziouwrites: > 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: [O] Feature request: lists with letters
Hello, Rasmuswrites: > 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 "") > -(`unordered "") > -(`descriptive ""))) > + (format "" (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: [O] Feature request: lists with letters
Nicolas Goaziouwrites: > Hello, > > Rasmus 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 >From 0760016f2b100f4050e16f5682eca305178f3494 Mon Sep 17 00:00:00 2001 From: Rasmus 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.") + ;;; User Configuration Variables @@ -3138,34 +3142,35 @@ the plist used as a communication channel." Plain List -;; FIXME Maybe arg1 is not needed because already sets -;; the correct value for the item counter -(defun org-html-begin-plain-list (type arg1) +(defun org-html-begin-plain-list (type 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 "" - (if arg1 (format " start=\"%d\"" arg1) ""))) -(`unordered "") -(`descriptive ""))) + (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 "") -(`unordered "") -(`descriptive ""))) + (format "" (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: [O] Feature request: lists with letters
Hello, Rasmuswrites: > 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: [O] Feature request: lists with letters
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 <> 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: [O] Feature request: lists with letters
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 signature.asc Description: PGP signature
Re: [O] Feature request: lists with letters
Hello, Titus von der Malsburgwrites: > On 2017-02-09 Thu 09:29, Rasmus wrote: >> Titus von der Malsburg 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: [O] Feature request: lists with letters
On 2017-02-09 Thu 09:29, Rasmus wrote: > Titus von der Malsburgwrites: > >> 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 signature.asc Description: PGP signature
Re: [O] Feature request: lists with letters
Titus von der Malsburgwrites: > 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: [O] Feature request: lists with letters
On 2017-02-06 Mon 15:34, Rasmus wrote: > Titus von der Malsburgwrites: > >> 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. <> 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: ol {list-style-type: lower-latin;} > #+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 signature.asc Description: PGP signature
Re: [O] Feature request: lists with letters
Titus von der Malsburgwrites: > 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. <> 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: ol {list-style-type: lower-latin;} #+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: [O] Feature request: lists with letters
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: [O] Feature request: lists with letters
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. <> 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 signature.asc Description: PGP signature
Re: [O] Feature request: lists with letters
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. <> 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 signature.asc Description: PGP signature
Re: [O] Feature request: lists with letters
Eric Abrahamsen wrote: >> Titus von der Malsburg 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 and to and . >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 signature.asc Description: PGP signature
Re: [O] Feature request: lists with letters
Nicolas Goaziouwrites: > Hello, > > Titus von der Malsburg 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: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] Feature request: lists with letters
Nicolas Goaziouwrites: > Titus von der Malsburg 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 and to and . 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: [O] Feature request: lists with letters
Titus von der Malsburgwrites: > 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: [O] Feature request: lists with letters
On 2017-02-02 Thu 19:57, Nicolas Goaziou wrote: > Hello, > > Titus von der Malsburgwrites: > >> 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 Goaziou0x80A93738 -- 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 signature.asc Description: PGP signature
Re: [O] Feature request: lists with letters
Hello, Titus von der Malsburgwrites: > 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 Goaziou0x80A93738
Re: [O] Feature request: lists with letters
On 2017-02-02 Thu 17:55, Nicolas Goaziou wrote: > Hello, > > Titus von der Malsburgwrites: > >> 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 signature.asc Description: PGP signature
Re: [O] Feature request: lists with letters
Hello, Titus von der Malsburgwrites: > 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
[O] Feature request: lists with letters
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