From: Nick Dokos <nicholas.dokos@hp.com>
To: "Thomas S. Dye" <tsd@tsdye.com>
Cc: Frederik <freak.fred@gmail.com>,
nicholas.dokos@hp.com, emacs-orgmode@gnu.org
Subject: Re: LaTex export: How to use `csquotes' and `\enquote{}'
Date: Wed, 06 Jul 2011 16:20:47 -0400 [thread overview]
Message-ID: <6663.1309983647@alphaville.americas.hpqcorp.net> (raw)
In-Reply-To: Message from tsd@tsdye.com (Thomas S. Dye) of "Wed, 06 Jul 2011 06:37:48 -1000." <m1pqlnicv7.fsf@tsdye.com>
Thomas S. Dye <tsd@tsdye.com> wrote:
> Frederik <freak.fred@gmail.com> 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
next prev parent reply other threads:[~2011-07-06 20:20 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-04 16:54 LaTex export: How to use `csquotes' and `\enquote{}' Frederik
2011-07-04 23:06 ` Thomas S. Dye
2011-07-05 20:26 ` Frederik
2011-07-05 22:56 ` Thomas S. Dye
2011-07-06 6:22 ` Frederik
2011-07-06 14:48 ` Frederik
2011-07-06 16:37 ` Thomas S. Dye
2011-07-06 20:20 ` Nick Dokos [this message]
2011-07-07 8:02 ` Stefan Nobis
2011-07-07 15:10 ` Nick Dokos
2011-07-07 17:22 ` Stefan Nobis
2011-07-07 19:11 ` Frederik
2011-07-07 22:07 ` Thomas S. Dye
2011-07-07 22:53 ` Nick Dokos
2011-07-07 23:06 ` Thomas S. Dye
2011-07-08 2:09 ` Nick Dokos
2011-07-08 6:07 ` Thomas S. Dye
2011-07-08 6:46 ` Nick Dokos
2011-07-08 6:58 ` Bastien
2011-07-08 15:49 ` Frederik
2011-07-08 16:13 ` Thomas S. Dye
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=6663.1309983647@alphaville.americas.hpqcorp.net \
--to=nicholas.dokos@hp.com \
--cc=emacs-orgmode@gnu.org \
--cc=freak.fred@gmail.com \
--cc=tsd@tsdye.com \
/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).