emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nick Dokos <ndokos@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: org-list-allow-alphabetical LaTeX export
Date: Fri, 07 Jun 2013 01:01:18 -0400	[thread overview]
Message-ID: <871u8ems4h.fsf@pierrot.dokosmarshall.org> (raw)
In-Reply-To: 93BA1627-D7F6-4E96-9AFC-927A6F6C8C6E@gmail.com

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

Josiah Schwab <jschwab@gmail.com> writes:

>> On 6 jun. 2013, at 10:20, Michael Bach <phaebz <at> gmail.com> wrote:
>>> The LaTeX exporter does not honor the setting of org-list-allow-alphabetical.  
>
> A week or so ago I asked a similar question about the HTML export and lists.
> http://lists.gnu.org/archive/html/emacs-orgmode/2013-05/msg01324.html
> So I just wanted to toss in my 2¢.
>
> On Jun 6, 2013, at 2:17 AM, Carsten Dominik wrote:
>> Conventions about the type of bullet to be used in a document belong
>> to the typesetting side, and I rather establish a global setting for
>> a document than follow my momentary decisions when I write the
>> Org-mode version of it.  On a similar vein, we do have lists
>> starting with - and * and +, but we still let LaTeX and HTML choose
>> what to use as a bullet.  To me this feels like the right behavior.
>
> I think this argument makes sense; and to be honest, that's probably
> how I want the exporter to behave most of the time.
>
> However, there is particular use case where I find this frustrating,
> which is writing problem sets.  There I like to reference other parts
> of the problems by name.  For example,
>
> a) Do something.
> b) Use your answer in part a) to do something else.
>
> Then, if I want to export it to multiple formats (say, html and pdf),
> there is no general way to tell orgmode: "my alphabetical bullet
> choice was meaningful, please try to preserve it".  One ends up
> inserting little workarounds for each export format.  Which is not a
> big deal, but when everything else works so seamlessly it's these
> little things that stand out :)
>

I don't have anything to add to what others have said on the
cross-reference question. But I did some investigation into
alpha lists and I wanted to expand a bit on that.

I looked at your earlier question and the latex question a bit and I
have a patch that implements something like what you want. However, I'm
not advocating that org actually implement this. In fact, there are good
reasons *not* to implement it (at least not in this form).

In the patch, there is a change in the parser so that it recognizes an
ordered-alpha list (in addition to the ordered, etc. lists it was
already recognizing). Then there are minor changes to ox-html.el:
basically ordered and ordered-alpha trigger the same response from the
exporter, except in one case: the opening of an ordered-alpha list
includes the ``type="a"'' thing. NB: the patch does not address any
of the other exporters.

However, the type="a" thingie in <ol> is a bad idea: it is deprecated in
the HTML spec, so it would be foolish to go chasing after it in
org. Here's what the spec says:

#+BEGIN_QUOTE

For the OL element, possible values for the type attribute are
summarized in the table below (they are case-sensitive):

Type	Numbering style
1	arabic numbers	1, 2, 3, ...
a	lower alpha	a, b, c, ...
A	upper alpha	A, B, C, ...
i	lower roman	i, ii, iii, ...
I	upper roman	I, II, III, ...

Note that the type attribute is deprecated and list styles should be
handled through style sheets.

For example, using CSS, one may specify that the style of numbers for
list elements in a numbered list should be lowercase roman numerals. In
the excerpt below, every OL element belonging to the class "withroman"
will have roman numerals in front of its list items.

<STYLE type="text/css">
OL.withroman { list-style-type: lower-roman }
</STYLE>
<BODY>
<OL class="withroman">
<LI> Step one ...  
<LI> Step two ...
</OL>
</BODY>

#+END_QUOTE

See http://www.w3.org/TR/html4/struct/lists.html#type-values.

Even if it were not deprecated, a good implementation would require org
to be able to generate all the values, which would probably require 
YAUO (yet another user option).

What org *could* do is to generate some discriminant (the "withroman" thing
above) so that the proper CSS could be applied.  Right now, there is no
such capability I believe. It could be done with YAUO, but I, for one,
think org has too many of those: we certainly don't need more unless it
is *really* necessary.

Here's the patch if you still want it: the only use for it
as far as I'm concerned is "educational":


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Alpha lists in the html exporter --]
[-- Type: text/x-diff, Size: 1905 bytes --]

diff --git a/lisp/org-list.el b/lisp/org-list.el
index 86afe11..7a606f0 100644
--- a/lisp/org-list.el
+++ b/lisp/org-list.el
@@ -1022,7 +1022,8 @@ Possible types are `descriptive', `ordered' and `unordered'.  The
 type is determined by the first item of the list."
   (let ((first (org-list-get-list-begin item struct prevs)))
     (cond
-     ((string-match "[[:alnum:]]" (org-list-get-bullet first struct)) 'ordered)
+     ((string-match "[[:alpha:]]" (org-list-get-bullet first struct)) 'ordered-alpha)
+     ((string-match "[[:digit:]]" (org-list-get-bullet first struct)) 'ordered)
      ((org-list-get-tag first struct) 'descriptive)
      (t 'unordered))))
 
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index facd84c..b30c313 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2387,7 +2387,7 @@ contextual information."
 	(br (org-html-close-tag "br" nil info)))
     (concat
      (case type
-       (ordered
+       ((ordered ordered-alpha)
 	(let* ((counter term-counter-id)
 	       (extra (if counter (format " value=\"%s\"" counter) "")))
 	  (concat
@@ -2409,7 +2409,7 @@ contextual information."
      (unless (eq type 'descriptive) checkbox)
      contents
      (case type
-       (ordered "</li>")
+       ((ordered ordered-alpha) "</li>")
        (unordered "</li>")
        (descriptive "</dd>")))))
 
@@ -2796,13 +2796,16 @@ lists."
     (ordered
      (format "<ol class=\"org-ol\"%s>"
 	     (if arg1 (format " start=\"%d\"" arg1) "")))
+    (ordered-alpha
+     (format "<ol type=\"a\" class=\"org-ol\"%s>"
+	     (if arg1 (format " start=\"%s\"" arg1) "")))
     (unordered "<ul class=\"org-ul\">")
     (descriptive "<dl class=\"org-dl\">")))
 
 (defun org-html-end-plain-list (type)
   "Insert the end of the HTML list depending on TYPE."
   (case type
-    (ordered "</ol>")
+    ((ordered ordered-alpha) "</ol>")
     (unordered "</ul>")
     (descriptive "</dl>")))
 

[-- Attachment #3: Type: text/plain, Size: 744 bytes --]


So much for HTML.

For LaTeX, you can do alpha lists as follows (no patch needed):

--8<---------------cut here---------------start------------->8---
#+LATEX_HEADER: \usepackage{enumerate}

* Letters
#+ATTR_LATEX: :options [(a)]
a. foo
b. bar
c. baz


This is another list, and the option above does not apply to it - 
the enumerators are numbers by default:

a. foo
b. bar
c. baz

* Numbers
1. foo
2. bar
3. baz

This might look like a numbered list, but if you add an option
you can turn it into an alpha list:

#+ATTR_LATEX: :options [A]
1. foo
2. bar
3. baz
--8<---------------cut here---------------end--------------->8---

You can pass any of the options that the enumerate package allows
without org having to worry about it.

-- 
Nick

  parent reply	other threads:[~2013-06-07  5:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-06  8:20 org-list-allow-alphabetical LaTeX export Michael Bach
2013-06-06  8:52 ` Carsten Dominik
2013-06-06  9:11   ` Michael Bach
2013-06-06  9:17     ` Carsten Dominik
2013-06-06  9:27       ` Michael Bach
2013-06-06 17:39       ` Josiah Schwab
2013-06-06 19:45         ` Carsten Dominik
2013-06-06 21:20           ` Rasmus
2013-06-06 21:36             ` Josiah Schwab
2013-06-06 22:39               ` Rasmus
2013-06-06 22:49                 ` Rasmus
2013-06-07 11:12           ` Nicolas Goaziou
2013-06-07  5:01         ` Nick Dokos [this message]
2013-06-07  5:48           ` Josiah Schwab
2013-06-07 13:54             ` Nick Dokos
2013-06-06  9:23     ` Marcin Borkowski
2013-06-06  9:33       ` Michael Bach

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871u8ems4h.fsf@pierrot.dokosmarshall.org \
    --to=ndokos@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).