Re: How to get numbered lists (1), (2), … ?

[Nicolas Goaziou <n.goaziou@gmail.com>]

Hello,

Nick Dokos <nicholas.dokos@hp.com> writes:

> Marius Hofert <marius.hofert@math.ethz.ch> wrote:
>
>
>> What do you mean by "better solution"? As far as I can tell, your
>> approach is precisely what Suvayu pointed to.
>
> No: what Suvayu pointed to can be done with the standard latex exporter,
> so it would not require changes to org-list-generic-to-latex. Just add
> something like this at the top of your org file:
>
> #+LATEX: \renewcommand{\theenumi}{(\arabic{enumi})}
>
> It's better in that it is simpler. There are drawbacks however: the
> above produces lists like this:
>
> (1). foo
> (2). bar
>
> with a period after the closing paren.
>
>> Using your approach, of course much more is possible, please look at
>> the create "enumitem" package with all its customizations.
>> 
>
> That is true: which one is "better" depends on one's requirements (both
> the desired output and how much pain one is willing to suffer in order
> to get there).
>
>> But this approach is a no-go for me (at least at the moment) mainly
>> due to the following reasons (please let me know if I'm wrong, I'm a
>> total newbie to org-mode):
>
>> 1) I have about 40 lists in one file. Having to put in special LaTeX
>> commands is not an option (maybe on only has to type it in once, but
>> then it can easily get overseen, e.g., when you move lists around and
>> the one containing the LaTeX commands is not the first one in the
>> document anymore)
>
> That's no problem: the LATEX_HEADER line goes in once at the top
> of the org file. You can move lists around at will.
>
>> 2) org-mode is basically a "better" text-mode. I don't want to have
>> LaTeX code in there if I print it as a .txt file.
>> 
>> Is there a solution without having to put #+LATEX_HEADER:
>> \usepackage{enumerate} before each list? Can this be set anywhere in
>> the preferences?
>> 
>
> You can customize the latex preamble that org adds to latex files to do
> that. The disadvantage is that you get the modified preamble always.
> See the org-export-latex-packages-alist variable for one way to do that.
>
>> But I assume that I still have to put in lists in org-mode like this:
>> 1.,2.,... or 1),2),... and can't put them in like this (1),(2),...?
>
> Correct: that would require changes to org-list.el I think - but Nicolas
> will have to say the final word on this. All the solutions so far work
> by modifying the latex output only, not the way you enter the list into
> the org file.

- On the Org part:

  I have nothing against (1) as item bullets, as it doesn't interfere
  with any existing Org syntax. I just think it shouldn't be available
  by default (much like alphabetical ordered lists).

  The implementation isn't hard /per se/ (at least less changes are
  required than implementing, for example, roman numbered lists), but
  I also think there should be some cleanup with regards to item
  bullets. So far, there is `org-plain-list-ordered-item-terminator' and
  `org-alphabetical-lists' to tweak them. We should avoid adding a third
  one.

  What about letting go those two variables and create
  `org-list-bullet-types', which would be a list of strings like:

           '("-" "+" "*" "1." "1)" "(1)" "a." "a)" "A)" "A.")

  It would be hard-coded but every bullet type could be opt-in or
  opt-out via customize. The default value should be as short as
  possible like '("-" "+" "*" "1." "a.").

  I can work it out in a few days if we agree.

- On the LaTeX part:

  Most of the time, it's better to let LaTeX choose its bullets than
  enforcing code produced to mimic Org buffer. In other words, a "(1)"
  bullet should only mean "enumerate item" instead of "enumerate item
  like (1)".

  Though, in the past months, I have been working on a overhaul of the
  whole export system (as a part of a bigger project). If I ever finish
  it, and if it ever hits Org core, the LaTeX back-end should make it
  easier to use "inparaenum" and "paraitem" packages directly from Org
  syntax (via #+attr_latex header).

  For now, I think solutions offered in this thread are sufficient, if
  not practical.


Regards,

-- 
Nicolas Goaziou