Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'

[Nick Dokos]

Thomas S. Dye <address@hidden> wrote:

> Frederik <address@hidden> 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