From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: =?UTF-8?B?UmU6IEhvdyB0byBnZXQgbnVtYmVyZWQgbGlzdHMgKDEpLCAoMiks?= =?UTF-8?B?IOKApiA/?= Date: Fri, 14 Oct 2011 14:14:23 +0200 Message-ID: <367FB6B9-C653-47C0-BBD9-02A665402353@gmail.com> References: <5133.1318533018@alphaville.americas.hpqcorp.net> <3414CE30-6774-4566-9391-D6929BDC4C87@math.ethz.ch> <7574.1318537714@alphaville.americas.hpqcorp.net> <87zkh3lsgy.fsf@gmail.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([140.186.70.92]:34203) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1REgej-0007fz-Ru for emacs-orgmode@gnu.org; Fri, 14 Oct 2011 08:14:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1REgei-00064w-EO for emacs-orgmode@gnu.org; Fri, 14 Oct 2011 08:14:29 -0400 Received: from mail-ey0-f169.google.com ([209.85.215.169]:45208) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1REgeh-00064g-P2 for emacs-orgmode@gnu.org; Fri, 14 Oct 2011 08:14:28 -0400 Received: by eye4 with SMTP id 4so1240503eye.0 for ; Fri, 14 Oct 2011 05:14:26 -0700 (PDT) In-Reply-To: <87zkh3lsgy.fsf@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Nicolas Goaziou Cc: Emacs help , nicholas.dokos@hp.com, Marius Hofert On 14.10.2011, at 13:31, Nicolas Goaziou wrote: > Hello, > > Nick Dokos writes: > >> Marius Hofert 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. That is not the only criterion. Adding new syntax elements make more ASCII sequences special. The Org markup is a heuristic set of special elements, and there is merrit in keeping it small. We already have more bullets and in particular numbered types - and so far I have not seen a compelling reason to add more. - Carsten > 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 >