From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: LaTex export: How to use `csquotes' and `\enquote{}' Date: Wed, 06 Jul 2011 16:20:47 -0400 Message-ID: <6663.1309983647@alphaville.americas.hpqcorp.net> References: Reply-To: nicholas.dokos@hp.com Return-path: Received: from eggs.gnu.org ([140.186.70.92]:44006) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QeYaa-0008Ah-5a for emacs-orgmode@gnu.org; Wed, 06 Jul 2011 16:20:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QeYaY-0001nL-2p for emacs-orgmode@gnu.org; Wed, 06 Jul 2011 16:20:51 -0400 Received: from g5t0006.atlanta.hp.com ([15.192.0.43]:31785) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QeYaX-0001n1-Sy for emacs-orgmode@gnu.org; Wed, 06 Jul 2011 16:20:49 -0400 In-Reply-To: Message from tsd@tsdye.com (Thomas S. Dye) of "Wed, 06 Jul 2011 06:37:48 -1000." 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: "Thomas S. Dye" Cc: Frederik , nicholas.dokos@hp.com, emacs-orgmode@gnu.org Thomas S. Dye wrote: > Frederik writes: > > >> Apparently someone tried a simple hack: > >> http://osdir.com/ml/emacs-orgmode-gnu/2010-01/msg00681.html > >> > >> When I find the time I will try this... > > > > I've tried the hack and for me this works pretty well. It's static but > > this doesn't really matter as I always stick to `csquotes' > > > > I think it shouldn't be too difficult to implement a new > > variable/switch whether the standard behaviour or the one provided by > > the hack is going to be used. One would only have to insert an > > additional if-clause in the defun the hack alters. > > > > Regards > > Yes, please do suggest a patch to support csquotes. I've been using > LaTeX to write the American dialect of English, so haven't had a need > for the package. As it happens, I spent some time yesterday editing by > hand an article that requires quotations in the British dialect of > English. IIUC, csquotes would have done this work for me with the > change of a single option. > > Perhaps others on the list with experience using the LaTeX babel package > can chime in here. > > Thanks for an interesting set of ideas. > The problem is the usual exponential growth of possibilities and how you manage them: if you read the babel manual and the csquotes manual and all the options that you can have, your head starts spinning (well, *my* head starts spinning). I tend to think of all the possibilities and despair over covering them all, whereas org-mode tends to make simplifying assumptions that will cover >90% of the cases (if the simplifying assumptions are good ones). I think we need such an assumption here. Here are some points to keep in mind while working on a patch: o csquotes.sty is part of the texlive-latex-extra package on Ubuntu (and probably something similar on other Linux distros and possibly MacOS X - hunoz about Windoz?) o because of the above, usage of csquotes has to be optional, default to "no". o there is hackish special treatment of french quotes in org-export-latex-quotation-marks: that could be folded into the more general treatment that the patch would provide at the cost of possible backward incompatibility for some org files. o it's currently not possible to specify a language in an +OPTIONS line in an org file: you can only set it through lisp. That should probably be changed. o org-mode specifies languages using the two-letter country abbreviation and does not worry about dialects/sublanguages. o the (LaTeX) babel package and csquotes have their own (different) conventions for specifying languages and dialects. In some cases, a single language can have multiple options for how to quote things. The proposal below explicitly does *not* deal with these complications. My initial reaction to how one would use csquotes was to use the +OPTIONS line, something like this: #+OPTIONS: enquote:t language:fr The language option would trigger the inclusion of the babel package with the (correct) language option (e.g. "en" -> "english", "de" -> "ngerman", "fr" -> "french", etc.) The enquote part would trigger 1) the inclusion of the csquotes package (and since you specify it explicitly, it is your responsibility to make sure that it be installed on your system) and 2) the translation of "foo" to \enquote{foo}. Without it, "foo" goes to ``foo'' no matter what the language is set to. IOW, here is the spec that I'm proposing (using "fr" as a non-"en" language which also uses a different quotation style: guillemets rather than quotes): | OPTIONS | org-export-default-language | \usepackage[options]{package} | "foo" -> | comments | |-----------------------+-----------------------------+------------------------------------+---------------+------------------------| | | en | | ``foo'' | ok | | | fr | [french]{babel} | ``foo'' | quotes, not guillemets | | enquote:t | en | [babel]{csquotes} | \enquote{foo} | ok | | enquote:t | fr | [french]{babel}, [babel]{csquotes} | \enquote{foo} | ok | | enquote:t language:fr | ANY | [french]{babel}, [babel]{csquotes} | \enquote{foo} | ok | In the last case, the language specified in the +OPTIONS line is operative, no matter what the default language is. In the second case, we have a backward incompatibility: it does not do the right thing for a default setting of "fr", but french speakers could restore proper behavior by installing the csquotes package and customizing the (proposed) org-export-latex-with-enquote variable, corresponding to the enquote option, to t: that would provide the same output as the hack does today. The advantage is that any other language (as long as it is supported by babel and csquotes) can deal with the problem in exactly the same way. Does this seem reasonable? It's probably too latex-specific and I'm not sure whether other exporters could do something reasonable with the information provided (in particular, the "enquote" name for the option is bad, so if somebody has a better idea, speak up). Does it cover a large majority of use-cases? Are there common cases that it does not cover? In particular, it does not cover multiple languages in an org file (but afaict, this is the case today as well). Note that I am not proposing to do the patch: I just wanted to make sure that whoever does the patch has a reasonable spec to work against and that the patch can be measured against something concrete. Nick