LaTex export: How to use `csquotes' and `\enquote{}'

LaTex export: How to use `csquotes' and `\enquote{}'

[Frederik]

Hi there!

I just started using org-mode - what a fantastic piece of software!

Now I wonder how to make use of one of the best LaTeX-packages out 
there: `csquotes'. I figured out how to include the package in the 
header by altering the corresponding variable, but I didn't find any 
hint how to make use of the `\enquote' command provided by `csquotes'.

I don't want my quotes to be quoted like this:
	``Das ist ein Test''
but like this:
	\enquote{Das ist ein Test}

I searched the web and found some feature requests on this list 
concerning `csquotes' but the documentation and worg don't mention this 
topic - except for http://orgmode.org/worg/org-faq.html where `csquotes' 
is included in a source code listing, but there is no further explanation.

Is there a way to use `csquotes'?

Any hints would be appreciated - Thanks & regards

-- 
Frederik

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

[Thomas S. Dye]

Aloha Frederik,

Welcome to Org-mode.

One way to use \enquote in your LaTeX export is described here:

http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-10-3

[[latex:enquote][Das ist ein Test]] will export as \enquote{Das ist ein
Test}.

hth,
Tom

Frederik <freak.fred@gmail.com> writes:

> Hi there!
>
> I just started using org-mode - what a fantastic piece of software!
>
> Now I wonder how to make use of one of the best LaTeX-packages out
> there: `csquotes'. I figured out how to include the package in the
> header by altering the corresponding variable, but I didn't find any
> hint how to make use of the `\enquote' command provided by `csquotes'.
>
> I don't want my quotes to be quoted like this:
> 	``Das ist ein Test''
> but like this:
> 	\enquote{Das ist ein Test}
>
> I searched the web and found some feature requests on this list
> concerning `csquotes' but the documentation and worg don't mention
> this topic - except for http://orgmode.org/worg/org-faq.html where
> csquotes' is included in a source code listing, but there is no
> further explanation.
>
> Is there a way to use `csquotes'?
>
> Any hints would be appreciated - Thanks & regards

-- 
Thomas S. Dye
http://www.tsdye.com

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

[Frederik]

Hey Tom!

> One way to use \enquote in your LaTeX export is described here:
>
> http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-10-3
>
> [[latex:enquote][Das ist ein Test]] will export as \enquote{Das ist ein
> Test}.

Thanks for your hint. But this is a rather cumbersome way to quote 
text... It would be handy to have " directly converted to enquote - this 
should be possible, because org-mode is obviously able to distinguish 
whether to use `` or '' at the beginning and at end of a word, respectively.

Regards.

-- 
Frederik

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

[Thomas S. Dye]

Frederik <freak.fred@gmail.com> writes:

> Hey Tom!
>
>> One way to use \enquote in your LaTeX export is described here:
>>
>> http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-10-3
>>
>> [[latex:enquote][Das ist ein Test]] will export as \enquote{Das ist ein
>> Test}.
>
> Thanks for your hint. But this is a rather cumbersome way to quote
> text... It would be handy to have " directly converted to enquote -
> this should be possible, because org-mode is obviously able to
> distinguish whether to use `` or '' at the beginning and at end of a
> word, respectively.
>
> Regards.

Aloha Frederik,

It looks more cumbersome than it is in practice.  You can use C-c C-l to
add the link and depending on the length of the link type name, it can
be very close to the same number of keystrokes you'd need for
\enquote{}.

Please let me know if you're able to configure Org-mode to translate "
to \enquote{}.  That would be a worthwhile addition to either the LaTeX
export tutorial or Org Hacks on Worg.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

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

[Frederik]

Hi Tom!

> It looks more cumbersome than it is in practice.  You can use C-c C-l to
> add the link and depending on the length of the link type name, it can
> be very close to the same number of keystrokes you'd need for
> \enquote{}.

During normal LaTex editing I never type `\enquote{}'. Of course I type 
" and AucTeX automatically inserts `\enquote{' at the beginning of a 
word and `}' at the end of a word, depending on whether `csquotes' is 
loaded or not.

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...

Thanks & Regards.

-- 
Frederik

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

[Frederik]

> 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

-- 
Frederik

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

[Thomas S. Dye]

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.

All the best,
Tom
-- 
Thomas S. Dye
http://www.tsdye.com

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

[Nick Dokos]

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

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

[Stefan Nobis]

[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]

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

> 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?)

On MacOS the MacTeX distribution is quite common and in this case a
complete TeXLive (including csquotes) is installed.

On Windows MikTeX is probably the defacto standard and IIRC it
supports installing packages on demand (I'm not sure wether csquotes
is included in the basic installation, but on the other hand I would
assume that a complete installation is not uncommen).

But another suggestion:

Always use \enquote for quotations in the exported text. In the
preambel of the document either include csquotes or provide a simple
macro enquote like the very simple

  \newcommand{\enquote}[1]{``#1''}

Maybe a bit more hackery might be needed for some special cases, but
with this approach it would be quite easy to change quotations styles
later on.

BTW: IMHO babel and csquotes should be considered standard packages
for all non-US texts (and even for US texts they have some
advantages).

-- 
Until the next mail...,
Stefan.

[-- Attachment #2: Type: application/pgp-signature, Size: 454 bytes --]

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

[Nick Dokos]

Stefan Nobis <stefan-ml@snobis.de> wrote:

> Nick Dokos <nicholas.dokos@hp.com> writes:
> 
> > 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?)
> 
> On MacOS the MacTeX distribution is quite common and in this case a
> complete TeXLive (including csquotes) is installed.
> 
> On Windows MikTeX is probably the defacto standard and IIRC it
> supports installing packages on demand (I'm not sure wether csquotes
> is included in the basic installation, but on the other hand I would
> assume that a complete installation is not uncommen).
> 

OK, that's good.

> But another suggestion:
> 
> Always use \enquote for quotations in the exported text. In the
> preambel of the document either include csquotes or provide a simple
> macro enquote like the very simple
> 
>   \newcommand{\enquote}[1]{``#1''}
> 
> Maybe a bit more hackery might be needed for some special cases, but
> with this approach it would be quite easy to change quotations styles
> later on.
> 

Not too thrilled about this: the current handling for the bare-bones
default case works OK and it could be easily extended to handle the csquotes
case.

I'd worry a bit about adding the newcommand in the preamble during org
processing: what would happen if I tried to use csquotes then? Would I
get a conflict? Would I have unpredictable situations where sometimes
I'd get the bare-bones definition and sometimes the csquotes one? All of
these can be answered of course, but the point is that you can't leave
it to accident.

> BTW: IMHO babel and csquotes should be considered standard packages
> for all non-US texts (and even for US texts they have some
> advantages).
> 

Agreed.

Nick

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

[Stefan Nobis]

[-- Attachment #1: Type: text/plain, Size: 311 bytes --]

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

> I'd worry a bit about adding the newcommand in the preamble during
> org processing: what would happen if I tried to use csquotes then?

It should be either the newcommand or else use csquotes. Mixing both
would be no good idea.

--
Until the next mail...,
Stefan.

[-- Attachment #2: Type: application/pgp-signature, Size: 454 bytes --]

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

[Frederik]

Am 06.07.2011 22:20, schrieb Nick Dokos:
> 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?)
In the Windows-world MikTeX is quite common, as far as I know. I use 
MikTeX on Windows and it installs packages one includes directly from 
the net if they aren't already installed.

IMHO the csquotes package becomes more and more important. For example 
biblatex, which will become the successor of BibTeX, relies on csquotes, 
when using a language other than English.

> 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.
>

Why not use one option for babel and another for csquotes? I thought of 
something like this:

#+OPTIONS: babel:english,ngerman csquotes:autostyle,german=guillemets

Or is there any other reason why one would like to specify language options?

Sadly I don't have the skills to suggest a patch...

I definitely see Nick's point: simplicity is one of the most important 
features of org-mode. So a possible decision not to support csquotes is 
absolutely understandable.

Regards

-- 
Frederik

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

[Thomas S. Dye]

Frederik <freak.fred@gmail.com> writes:

> Am 06.07.2011 22:20, schrieb Nick Dokos:
>> 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?)
> In the Windows-world MikTeX is quite common, as far as I know. I use
> MikTeX on Windows and it installs packages one includes directly from
> the net if they aren't already installed.
>
> IMHO the csquotes package becomes more and more important. For example
> biblatex, which will become the successor of BibTeX, relies on
> csquotes, when using a language other than English.
>
>> 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.
>>
>
> Why not use one option for babel and another for csquotes? I thought
> of something like this:
>
> #+OPTIONS: babel:english,ngerman csquotes:autostyle,german=guillemets
>
> Or is there any other reason why one would like to specify language options?
>
> Sadly I don't have the skills to suggest a patch...
>
> I definitely see Nick's point: simplicity is one of the most important
> features of org-mode. So a possible decision not to support csquotes
> is absolutely understandable.
>
> Regards

Aloha all,

I'm wondering if a simpler solution than Nick's might be to replace the
lists at the end of this code snippet with a variable, say
org-export-latex-quote-mechanism.  Initially, the variable would be set
to the second list.  If the user wanted something different, then the
user would be responsible for setting the variable to the different
quoting mechanism, whether it be \enquote{ or something else.  The user
would also be responsible for making sure the LaTeX packages needed to
support the quoting mechanism were loaded and functional.

(defun org-export-latex-quotation-marks ()
  "Export quotation marks depending on language conventions."
  (let* ((lang (plist-get org-export-latex-options-plist :language))
	 (quote-rpl (if (equal lang "fr")
			'(("\\(\\s-\\)\"" "«~")
			  ("\\(\\S-\\)\"" "~»")
			  ("\\(\\s-\\)'" "`"))
		      '(("\\(\\s-\\|[[(]\\)\"" "``")
			("\\(\\S-\\)\"" "''")
			("\\(\\s-\\|(\\)'" "`")))))

This might provide Org-mode the flexibility needed to support csquotes,
but also leave open the possibility of supporting other packages, as
well.

Any thoughts?

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

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

[Nick Dokos]

Responses to Frederik and Tom inline.

Frederik <freak.fred@gmail.com> writes:

> Why not use one option for babel and another for csquotes? I thought
> of something like this:
>
> #+OPTIONS: babel:english,ngerman csquotes:autostyle,german=guillemets
>

I did suggest different options, one controlling babel and the other
controlling csquotes. The problem with the above is that it is very
LaTeX-specific: the options and their values have no meaning outside of
that. I think that we should strive to use more generic options that
would at least be usable by other export engines.

> Or is there any other reason why one would like to specify language options?
>
> Sadly I don't have the skills to suggest a patch...
>
> I definitely see Nick's point: simplicity is one of the most important
> features of org-mode. So a possible decision not to support csquotes
> is absolutely understandable.

I'll be very surprised if there is no support for csquotes within a couple
of weeks (maybe within a couple of days :-) ) The question is "what form
will it take?"


Thomas S. Dye <tsd@tsdye.com> wrote:

> I'm wondering if a simpler solution than Nick's might be to replace the
> lists at the end of this code snippet with a variable, say
> org-export-latex-quote-mechanism.  Initially, the variable would be set
> to the second list.  If the user wanted something different, then the
> user would be responsible for setting the variable to the different
> quoting mechanism, whether it be \enquote{ or something else.  The user
> would also be responsible for making sure the LaTeX packages needed to
> support the quoting mechanism were loaded and functional.
> 
> (defun org-export-latex-quotation-marks ()
>   "Export quotation marks depending on language conventions."
>   (let* ((lang (plist-get org-export-latex-options-plist :language))
> 	 (quote-rpl (if (equal lang "fr")
> 			'(("\\(\\s-\\)\"" "«~")
> 			  ("\\(\\S-\\)\"" "~»")
> 			  ("\\(\\s-\\)'" "`"))
> 		      '(("\\(\\s-\\|[[(]\\)\"" "``")
> 			("\\(\\S-\\)\"" "''")
> 			("\\(\\s-\\|(\\)'" "`")))))
> 
> This might provide Org-mode the flexibility needed to support csquotes,
> but also leave open the possibility of supporting other packages, as
> well.
> 

Maybe - this is the kind of mechanism that is used for
org-export-latex-classes for example, so there is definitely
precedent. OTOH, the lists above look like hen scratchings (or line
noise if you prefer, or -- I'll get in trouble for this -- Perl
code :-)), so it would be easy to get things wrong if you have to
cut-and-paste-and-edit which I think one would have to do to customize
it: it's OK to expect *one* developer to get it right, but it's not
OK to expect 100 users to get it right.

So it might be simpler to implement, but I'm not sure it might be
simpler to use. I've supported using existing mechanisms to implement
new behavior before and not disturbing the existing structure too much
(e.g. the revtex stuff that Sebastian Hoffert was (is?) working on).
But if it leads to e.g. an implementation that befuddles users, then
you end up with a flood of questions on the ML. So it's a balancing
act.

BTW, you mention the possibility of supporting other packages. I didn't
find anything useful in the TeX FAQ but if there are "csquotes-like"
packages that people commonly (or perhaps uncommonly) use then a survey
of their capabilities might indicate the best way to go.

Nick

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

[Thomas S. Dye]

Hi Nick,

Good point.

How about three new variables, org-export-latex-open-double-quotes,
org-export-latex-close-double-quotes, and org-export-latex-single-quote?

The regexp stuff could stay as hard code and the user would only be able
to mess up what actually ends up being exported.

All the best,
Tom
 
Nick Dokos <nicholas.dokos@hp.com> writes:

> Responses to Frederik and Tom inline.
>
> Frederik <freak.fred@gmail.com> writes:
>
>> Why not use one option for babel and another for csquotes? I thought
>> of something like this:
>>
>> #+OPTIONS: babel:english,ngerman csquotes:autostyle,german=guillemets
>>
>
> I did suggest different options, one controlling babel and the other
> controlling csquotes. The problem with the above is that it is very
> LaTeX-specific: the options and their values have no meaning outside of
> that. I think that we should strive to use more generic options that
> would at least be usable by other export engines.
>
>> Or is there any other reason why one would like to specify language options?
>>
>> Sadly I don't have the skills to suggest a patch...
>>
>> I definitely see Nick's point: simplicity is one of the most important
>> features of org-mode. So a possible decision not to support csquotes
>> is absolutely understandable.
>
> I'll be very surprised if there is no support for csquotes within a couple
> of weeks (maybe within a couple of days :-) ) The question is "what form
> will it take?"
>
>
> Thomas S. Dye <tsd@tsdye.com> wrote:
>
>> I'm wondering if a simpler solution than Nick's might be to replace the
>> lists at the end of this code snippet with a variable, say
>> org-export-latex-quote-mechanism.  Initially, the variable would be set
>> to the second list.  If the user wanted something different, then the
>> user would be responsible for setting the variable to the different
>> quoting mechanism, whether it be \enquote{ or something else.  The user
>> would also be responsible for making sure the LaTeX packages needed to
>> support the quoting mechanism were loaded and functional.
>> 
>> (defun org-export-latex-quotation-marks ()
>>   "Export quotation marks depending on language conventions."
>>   (let* ((lang (plist-get org-export-latex-options-plist :language))
>> 	 (quote-rpl (if (equal lang "fr")
>> 			'(("\\(\\s-\\)\"" "«~")
>> 			  ("\\(\\S-\\)\"" "~»")
>> 			  ("\\(\\s-\\)'" "`"))
>> 		      '(("\\(\\s-\\|[[(]\\)\"" "``")
>> 			("\\(\\S-\\)\"" "''")
>> 			("\\(\\s-\\|(\\)'" "`")))))
>> 
>> This might provide Org-mode the flexibility needed to support csquotes,
>> but also leave open the possibility of supporting other packages, as
>> well.
>> 
>
> Maybe - this is the kind of mechanism that is used for
> org-export-latex-classes for example, so there is definitely
> precedent. OTOH, the lists above look like hen scratchings (or line
> noise if you prefer, or -- I'll get in trouble for this -- Perl
> code :-)), so it would be easy to get things wrong if you have to
> cut-and-paste-and-edit which I think one would have to do to customize
> it: it's OK to expect *one* developer to get it right, but it's not
> OK to expect 100 users to get it right.
>
> So it might be simpler to implement, but I'm not sure it might be
> simpler to use. I've supported using existing mechanisms to implement
> new behavior before and not disturbing the existing structure too much
> (e.g. the revtex stuff that Sebastian Hoffert was (is?) working on).
> But if it leads to e.g. an implementation that befuddles users, then
> you end up with a flood of questions on the ML. So it's a balancing
> act.
>
> BTW, you mention the possibility of supporting other packages. I didn't
> find anything useful in the TeX FAQ but if there are "csquotes-like"
> packages that people commonly (or perhaps uncommonly) use then a survey
> of their capabilities might indicate the best way to go.
>
> Nick

-- 
Thomas S. Dye
http://www.tsdye.com

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

[Nick Dokos]

Thomas S. Dye <tsd@tsdye.com> wrote:

> Hi Nick,
> 
> Good point.
> 
> How about three new variables, org-export-latex-open-double-quotes,
> org-export-latex-close-double-quotes, and org-export-latex-single-quote?
> 
> The regexp stuff could stay as hard code and the user would only be able
> to mess up what actually ends up being exported.
> 

That's a pretty good idea: simple implementation, no extra options, set-and-forget
and it only affects the latex exporter.

Tom, you win the jackpot: you'll have the patch ready by tomorrow?

Nick

> All the best,
> Tom
> =20
> Nick Dokos <nicholas.dokos@hp.com> writes:
> 
> > Responses to Frederik and Tom inline.
> >
> > Frederik <freak.fred@gmail.com> writes:
> >
> >> Why not use one option for babel and another for csquotes? I thought
> >> of something like this:
> >>
> >> #+OPTIONS: babel:english,ngerman csquotes:autostyle,german=3Dguillemets
> >>
> >
> > I did suggest different options, one controlling babel and the other
> > controlling csquotes. The problem with the above is that it is very
> > LaTeX-specific: the options and their values have no meaning outside of
> > that. I think that we should strive to use more generic options that
> > would at least be usable by other export engines.
> >
> >> Or is there any other reason why one would like to specify language opti=
> ons?
> >>
> >> Sadly I don't have the skills to suggest a patch...
> >>
> >> I definitely see Nick's point: simplicity is one of the most important
> >> features of org-mode. So a possible decision not to support csquotes
> >> is absolutely understandable.
> >
> > I'll be very surprised if there is no support for csquotes within a couple
> > of weeks (maybe within a couple of days :-) ) The question is "what form
> > will it take?"
> >
> >
> > Thomas S. Dye <tsd@tsdye.com> wrote:
> >
> >> I'm wondering if a simpler solution than Nick's might be to replace the
> >> lists at the end of this code snippet with a variable, say
> >> org-export-latex-quote-mechanism.  Initially, the variable would be set
> >> to the second list.  If the user wanted something different, then the
> >> user would be responsible for setting the variable to the different
> >> quoting mechanism, whether it be \enquote{ or something else.  The user
> >> would also be responsible for making sure the LaTeX packages needed to
> >> support the quoting mechanism were loaded and functional.
> >>=20
> >> (defun org-export-latex-quotation-marks ()
> >>   "Export quotation marks depending on language conventions."
> >>   (let* ((lang (plist-get org-export-latex-options-plist :language))
> >> 	 (quote-rpl (if (equal lang "fr")
> >> 			'(("\\(\\s-\\)\"" "=C2=AB~")
> >> 			  ("\\(\\S-\\)\"" "~=C2=BB")
> >> 			  ("\\(\\s-\\)'" "`"))
> >> 		      '(("\\(\\s-\\|[[(]\\)\"" "``")
> >> 			("\\(\\S-\\)\"" "''")
> >> 			("\\(\\s-\\|(\\)'" "`")))))
> >>=20
> >> This might provide Org-mode the flexibility needed to support csquotes,
> >> but also leave open the possibility of supporting other packages, as
> >> well.
> >>=20
> >
> > Maybe - this is the kind of mechanism that is used for
> > org-export-latex-classes for example, so there is definitely
> > precedent. OTOH, the lists above look like hen scratchings (or line
> > noise if you prefer, or -- I'll get in trouble for this -- Perl
> > code :-)), so it would be easy to get things wrong if you have to
> > cut-and-paste-and-edit which I think one would have to do to customize
> > it: it's OK to expect *one* developer to get it right, but it's not
> > OK to expect 100 users to get it right.
> >
> > So it might be simpler to implement, but I'm not sure it might be
> > simpler to use. I've supported using existing mechanisms to implement
> > new behavior before and not disturbing the existing structure too much
> > (e.g. the revtex stuff that Sebastian Hoffert was (is?) working on).
> > But if it leads to e.g. an implementation that befuddles users, then
> > you end up with a flood of questions on the ML. So it's a balancing
> > act.
> >
> > BTW, you mention the possibility of supporting other packages. I didn't
> > find anything useful in the TeX FAQ but if there are "csquotes-like"
> > packages that people commonly (or perhaps uncommonly) use then a survey
> > of their capabilities might indicate the best way to go.
> >
> > Nick
> 
> --=20
> Thomas S. Dye
> http://www.tsdye.com
> 

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

[Thomas S. Dye]

Hi Nick,

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

> Thomas S. Dye <tsd@tsdye.com> wrote:
>
>> Hi Nick,
>> 
>> Good point.
>> 
>> How about three new variables, org-export-latex-open-double-quotes,
>> org-export-latex-close-double-quotes, and org-export-latex-single-quote?
>> 
>> The regexp stuff could stay as hard code and the user would only be able
>> to mess up what actually ends up being exported.
>> 
>
> That's a pretty good idea: simple implementation, no extra options, set-and-forget
> and it only affects the latex exporter.
>
> Tom, you win the jackpot: you'll have the patch ready by tomorrow?
>
> Nick
>

I think we're still a bit short of the jackpot, or at least I am.  I
don't understand why (equal lang "fr") requires a different regexp in
the first list.  Do you?  

Is the different regexp needed for "fr" text when using csquotes?  Or is
this difference handled by csquotes, too?

That said, "tomorrow" is a congenial deadline, so long as you're willing
to stick to it for the next few days, at least.

All the best,
Tom

>> All the best,
>> Tom
>> =20
>> Nick Dokos <nicholas.dokos@hp.com> writes:
>> 
>> > Responses to Frederik and Tom inline.
>> >
>> > Frederik <freak.fred@gmail.com> writes:
>> >
>> >> Why not use one option for babel and another for csquotes? I thought
>> >> of something like this:
>> >>
>> >> #+OPTIONS: babel:english,ngerman csquotes:autostyle,german=3Dguillemets
>> >>
>> >
>> > I did suggest different options, one controlling babel and the other
>> > controlling csquotes. The problem with the above is that it is very
>> > LaTeX-specific: the options and their values have no meaning outside of
>> > that. I think that we should strive to use more generic options that
>> > would at least be usable by other export engines.
>> >
>> >> Or is there any other reason why one would like to specify language opti=
>> ons?
>> >>
>> >> Sadly I don't have the skills to suggest a patch...
>> >>
>> >> I definitely see Nick's point: simplicity is one of the most important
>> >> features of org-mode. So a possible decision not to support csquotes
>> >> is absolutely understandable.
>> >
>> > I'll be very surprised if there is no support for csquotes within a couple
>> > of weeks (maybe within a couple of days :-) ) The question is "what form
>> > will it take?"
>> >
>> >
>> > Thomas S. Dye <tsd@tsdye.com> wrote:
>> >
>> >> I'm wondering if a simpler solution than Nick's might be to replace the
>> >> lists at the end of this code snippet with a variable, say
>> >> org-export-latex-quote-mechanism.  Initially, the variable would be set
>> >> to the second list.  If the user wanted something different, then the
>> >> user would be responsible for setting the variable to the different
>> >> quoting mechanism, whether it be \enquote{ or something else.  The user
>> >> would also be responsible for making sure the LaTeX packages needed to
>> >> support the quoting mechanism were loaded and functional.
>> >>=20
>> >> (defun org-export-latex-quotation-marks ()
>> >>   "Export quotation marks depending on language conventions."
>> >>   (let* ((lang (plist-get org-export-latex-options-plist :language))
>> >> 	 (quote-rpl (if (equal lang "fr")
>> >> 			'(("\\(\\s-\\)\"" "=C2=AB~")
>> >> 			  ("\\(\\S-\\)\"" "~=C2=BB")
>> >> 			  ("\\(\\s-\\)'" "`"))
>> >> 		      '(("\\(\\s-\\|[[(]\\)\"" "``")
>> >> 			("\\(\\S-\\)\"" "''")
>> >> 			("\\(\\s-\\|(\\)'" "`")))))
>> >>=20
>> >> This might provide Org-mode the flexibility needed to support csquotes,
>> >> but also leave open the possibility of supporting other packages, as
>> >> well.
>> >>=20
>> >
>> > Maybe - this is the kind of mechanism that is used for
>> > org-export-latex-classes for example, so there is definitely
>> > precedent. OTOH, the lists above look like hen scratchings (or line
>> > noise if you prefer, or -- I'll get in trouble for this -- Perl
>> > code :-)), so it would be easy to get things wrong if you have to
>> > cut-and-paste-and-edit which I think one would have to do to customize
>> > it: it's OK to expect *one* developer to get it right, but it's not
>> > OK to expect 100 users to get it right.
>> >
>> > So it might be simpler to implement, but I'm not sure it might be
>> > simpler to use. I've supported using existing mechanisms to implement
>> > new behavior before and not disturbing the existing structure too much
>> > (e.g. the revtex stuff that Sebastian Hoffert was (is?) working on).
>> > But if it leads to e.g. an implementation that befuddles users, then
>> > you end up with a flood of questions on the ML. So it's a balancing
>> > act.
>> >
>> > BTW, you mention the possibility of supporting other packages. I didn't
>> > find anything useful in the TeX FAQ but if there are "csquotes-like"
>> > packages that people commonly (or perhaps uncommonly) use then a survey
>> > of their capabilities might indicate the best way to go.
>> >
>> > Nick
>> 
>> --=20
>> Thomas S. Dye
>> http://www.tsdye.com
>> 
>

-- 
Thomas S. Dye
http://www.tsdye.com

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

[Nick Dokos]

Thomas S. Dye <tsd@tsdye.com> wrote:

> Hi Nick,
> 
> Nick Dokos <nicholas.dokos@hp.com> writes:
> 
> > Thomas S. Dye <tsd@tsdye.com> wrote:
> >
> >> Hi Nick,
> >> 
> >> Good point.
> >> 
> >> How about three new variables, org-export-latex-open-double-quotes,
> >> org-export-latex-close-double-quotes, and org-export-latex-single-quote?
> >> 
> >> The regexp stuff could stay as hard code and the user would only be able
> >> to mess up what actually ends up being exported.
> >> 
> >
> > That's a pretty good idea: simple implementation, no extra options, set-and-forget
> > and it only affects the latex exporter.
> >
> > Tom, you win the jackpot: you'll have the patch ready by tomorrow?
> >
> > Nick
> >
> 
> I think we're still a bit short of the jackpot, or at least I am.  I
> don't understand why (equal lang "fr") requires a different regexp in
> the first list.  Do you?  
> 
> Is the different regexp needed for "fr" text when using csquotes?  Or is
> this difference handled by csquotes, too?
> 

I believe it is just a hack  - I mentioned it in an earlier post and I think
it can safely go away: csquotes will take care of it very nicely.

> That said, "tomorrow" is a congenial deadline, so long as you're willing
> to stick to it for the next few days, at least.
> 

Sounds good: there's always tomorrow. BTW, since you are doing the hard
work here, I'll volunteer to write a section for the LaTeX tutorial (but
if you prefer to write it, I will defer).

Nick

> All the best,
> Tom
> 
> >> All the best,
> >> Tom
> >> =20
> >> Nick Dokos <nicholas.dokos@hp.com> writes:
> >> 
> >> > Responses to Frederik and Tom inline.
> >> >
> >> > Frederik <freak.fred@gmail.com> writes:
> >> >
> >> >> Why not use one option for babel and another for csquotes? I thought
> >> >> of something like this:
> >> >>
> >> >> #+OPTIONS: babel:english,ngerman csquotes:autostyle,german=3Dguillemets
> >> >>
> >> >
> >> > I did suggest different options, one controlling babel and the other
> >> > controlling csquotes. The problem with the above is that it is very
> >> > LaTeX-specific: the options and their values have no meaning outside of
> >> > that. I think that we should strive to use more generic options that
> >> > would at least be usable by other export engines.
> >> >
> >> >> Or is there any other reason why one would like to specify language opti=
> >> ons?
> >> >>
> >> >> Sadly I don't have the skills to suggest a patch...
> >> >>
> >> >> I definitely see Nick's point: simplicity is one of the most important
> >> >> features of org-mode. So a possible decision not to support csquotes
> >> >> is absolutely understandable.
> >> >
> >> > I'll be very surprised if there is no support for csquotes within a couple
> >> > of weeks (maybe within a couple of days :-) ) The question is "what form
> >> > will it take?"
> >> >
> >> >
> >> > Thomas S. Dye <tsd@tsdye.com> wrote:
> >> >
> >> >> I'm wondering if a simpler solution than Nick's might be to replace the
> >> >> lists at the end of this code snippet with a variable, say
> >> >> org-export-latex-quote-mechanism.  Initially, the variable would be set
> >> >> to the second list.  If the user wanted something different, then the
> >> >> user would be responsible for setting the variable to the different
> >> >> quoting mechanism, whether it be \enquote{ or something else.  The user
> >> >> would also be responsible for making sure the LaTeX packages needed to
> >> >> support the quoting mechanism were loaded and functional.
> >> >>=20
> >> >> (defun org-export-latex-quotation-marks ()
> >> >>   "Export quotation marks depending on language conventions."
> >> >>   (let* ((lang (plist-get org-export-latex-options-plist :language))
> >> >> 	 (quote-rpl (if (equal lang "fr")
> >> >> 			'(("\\(\\s-\\)\"" "=C2=AB~")
> >> >> 			  ("\\(\\S-\\)\"" "~=C2=BB")
> >> >> 			  ("\\(\\s-\\)'" "`"))
> >> >> 		      '(("\\(\\s-\\|[[(]\\)\"" "``")
> >> >> 			("\\(\\S-\\)\"" "''")
> >> >> 			("\\(\\s-\\|(\\)'" "`")))))
> >> >>=20
> >> >> This might provide Org-mode the flexibility needed to support csquotes,
> >> >> but also leave open the possibility of supporting other packages, as
> >> >> well.
> >> >>=20
> >> >
> >> > Maybe - this is the kind of mechanism that is used for
> >> > org-export-latex-classes for example, so there is definitely
> >> > precedent. OTOH, the lists above look like hen scratchings (or line
> >> > noise if you prefer, or -- I'll get in trouble for this -- Perl
> >> > code :-)), so it would be easy to get things wrong if you have to
> >> > cut-and-paste-and-edit which I think one would have to do to customize
> >> > it: it's OK to expect *one* developer to get it right, but it's not
> >> > OK to expect 100 users to get it right.
> >> >
> >> > So it might be simpler to implement, but I'm not sure it might be
> >> > simpler to use. I've supported using existing mechanisms to implement
> >> > new behavior before and not disturbing the existing structure too much
> >> > (e.g. the revtex stuff that Sebastian Hoffert was (is?) working on).
> >> > But if it leads to e.g. an implementation that befuddles users, then
> >> > you end up with a flood of questions on the ML. So it's a balancing
> >> > act.
> >> >
> >> > BTW, you mention the possibility of supporting other packages. I didn't
> >> > find anything useful in the TeX FAQ but if there are "csquotes-like"
> >> > packages that people commonly (or perhaps uncommonly) use then a survey
> >> > of their capabilities might indicate the best way to go.
> >> >
> >> > Nick
> >> 
> >> --=20
> >> Thomas S. Dye
> >> http://www.tsdye.com
> >> 
> >
> 
> -- 
> Thomas S. Dye
> http://www.tsdye.com
> 

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

[Bastien]

Hi Nick and Tom,

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

> Sounds good: there's always tomorrow. BTW, since you are doing the hard
> work here, I'll volunteer to write a section for the LaTeX tutorial (but
> if you prefer to write it, I will defer).

I'm following this thread and waiting for the patch -- would be nice 
to apply it before 7.6.1 (this WE), which will go to Emacs.

Good luck!

-- 
 Bastien

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

[Frederik]

Am 08.07.2011 04:09, schrieb Nick Dokos:
> Thomas S. Dye<tsd@tsdye.com>  wrote:
>
>> Hi Nick,
>>
>> Good point.
>>
>> How about three new variables, org-export-latex-open-double-quotes,
>> org-export-latex-close-double-quotes, and org-export-latex-single-quote?
>>
>> The regexp stuff could stay as hard code and the user would only be able
>> to mess up what actually ends up being exported.
>>
>
> That's a pretty good idea: simple implementation, no extra options, set-and-forget
> and it only affects the latex exporter.
>
> Tom, you win the jackpot: you'll have the patch ready by tomorrow?
>
> Nick
>

I agree with Nick - simple and clean.

What would be the purpose of the variable 
`org-export-latex-single-quote'? If you intend to support \enquote*{, 
then perhaps there should be an additional variable for the single 
closing quote (which would be `}' again...)

Then you'd have four variables:
org-export-latex-open-double-quotes
org-export-latex-close-double-quotes
org-export-latex-open-single-quote
org-export-latex-close-single-quote

But perhaps I'm misguided...

Regards.



>> All the best,
>> Tom
>> =20
>> Nick Dokos<nicholas.dokos@hp.com>  writes:
>>
>>> Responses to Frederik and Tom inline.
>>>
>>> Frederik<freak.fred@gmail.com>  writes:
>>>
>>>> Why not use one option for babel and another for csquotes? I thought
>>>> of something like this:
>>>>
>>>> #+OPTIONS: babel:english,ngerman csquotes:autostyle,german=3Dguillemets
>>>>
>>>
>>> I did suggest different options, one controlling babel and the other
>>> controlling csquotes. The problem with the above is that it is very
>>> LaTeX-specific: the options and their values have no meaning outside of
>>> that. I think that we should strive to use more generic options that
>>> would at least be usable by other export engines.
>>>
>>>> Or is there any other reason why one would like to specify language opti=
>> ons?
>>>>
>>>> Sadly I don't have the skills to suggest a patch...
>>>>
>>>> I definitely see Nick's point: simplicity is one of the most important
>>>> features of org-mode. So a possible decision not to support csquotes
>>>> is absolutely understandable.
>>>
>>> I'll be very surprised if there is no support for csquotes within a couple
>>> of weeks (maybe within a couple of days :-) ) The question is "what form
>>> will it take?"
>>>
>>>
>>> Thomas S. Dye<tsd@tsdye.com>  wrote:
>>>
>>>> I'm wondering if a simpler solution than Nick's might be to replace the
>>>> lists at the end of this code snippet with a variable, say
>>>> org-export-latex-quote-mechanism.  Initially, the variable would be set
>>>> to the second list.  If the user wanted something different, then the
>>>> user would be responsible for setting the variable to the different
>>>> quoting mechanism, whether it be \enquote{ or something else.  The user
>>>> would also be responsible for making sure the LaTeX packages needed to
>>>> support the quoting mechanism were loaded and functional.
>>>> =20
>>>> (defun org-export-latex-quotation-marks ()
>>>>    "Export quotation marks depending on language conventions."
>>>>    (let* ((lang (plist-get org-export-latex-options-plist :language))
>>>> 	 (quote-rpl (if (equal lang "fr")
>>>> 			'(("\\(\\s-\\)\"" "=C2=AB~")
>>>> 			  ("\\(\\S-\\)\"" "~=C2=BB")
>>>> 			  ("\\(\\s-\\)'" "`"))
>>>> 		      '(("\\(\\s-\\|[[(]\\)\"" "``")
>>>> 			("\\(\\S-\\)\"" "''")
>>>> 			("\\(\\s-\\|(\\)'" "`")))))
>>>> =20
>>>> This might provide Org-mode the flexibility needed to support csquotes,
>>>> but also leave open the possibility of supporting other packages, as
>>>> well.
>>>> =20
>>>
>>> Maybe - this is the kind of mechanism that is used for
>>> org-export-latex-classes for example, so there is definitely
>>> precedent. OTOH, the lists above look like hen scratchings (or line
>>> noise if you prefer, or -- I'll get in trouble for this -- Perl
>>> code :-)), so it would be easy to get things wrong if you have to
>>> cut-and-paste-and-edit which I think one would have to do to customize
>>> it: it's OK to expect *one* developer to get it right, but it's not
>>> OK to expect 100 users to get it right.
>>>
>>> So it might be simpler to implement, but I'm not sure it might be
>>> simpler to use. I've supported using existing mechanisms to implement
>>> new behavior before and not disturbing the existing structure too much
>>> (e.g. the revtex stuff that Sebastian Hoffert was (is?) working on).
>>> But if it leads to e.g. an implementation that befuddles users, then
>>> you end up with a flood of questions on the ML. So it's a balancing
>>> act.
>>>
>>> BTW, you mention the possibility of supporting other packages. I didn't
>>> find anything useful in the TeX FAQ but if there are "csquotes-like"
>>> packages that people commonly (or perhaps uncommonly) use then a survey
>>> of their capabilities might indicate the best way to go.
>>>
>>> Nick
>>
>> --=20
>> Thomas S. Dye
>> http://www.tsdye.com
>>
>
>


-- 
Frederik

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

[Thomas S. Dye]

Frederik <freak.fred@gmail.com> writes:

> Am 08.07.2011 04:09, schrieb Nick Dokos:
>> Thomas S. Dye<tsd@tsdye.com>  wrote:
>>
>>> Hi Nick,
>>>
>>> Good point.
>>>
>>> How about three new variables, org-export-latex-open-double-quotes,
>>> org-export-latex-close-double-quotes, and org-export-latex-single-quote?
>>>
>>> The regexp stuff could stay as hard code and the user would only be able
>>> to mess up what actually ends up being exported.
>>>
>>
>> That's a pretty good idea: simple implementation, no extra options, set-and-forget
>> and it only affects the latex exporter.
>>
>> Tom, you win the jackpot: you'll have the patch ready by tomorrow?
>>
>> Nick
>>
>
> I agree with Nick - simple and clean.
>
> What would be the purpose of the variable
> org-export-latex-single-quote'? If you intend to support \enquote*{,
> then perhaps there should be an additional variable for the single
> closing quote (which would be `}' again...)
>
> Then you'd have four variables:
> org-export-latex-open-double-quotes
> org-export-latex-close-double-quotes
> org-export-latex-open-single-quote
> org-export-latex-close-single-quote
>
> But perhaps I'm misguided...
>
> Regards.

Hi Frederik,

I think you're right.  I was looking at the existing code, which has
three list entries, and not thinking through to the csquotes solution.

Thanks for pointing this out.

All the best,
Tom

>
>
>
>>> All the best,
>>> Tom
>>> =20
>>> Nick Dokos<nicholas.dokos@hp.com>  writes:
>>>
>>>> Responses to Frederik and Tom inline.
>>>>
>>>> Frederik<freak.fred@gmail.com>  writes:
>>>>
>>>>> Why not use one option for babel and another for csquotes? I thought
>>>>> of something like this:
>>>>>
>>>>> #+OPTIONS: babel:english,ngerman csquotes:autostyle,german=3Dguillemets
>>>>>
>>>>
>>>> I did suggest different options, one controlling babel and the other
>>>> controlling csquotes. The problem with the above is that it is very
>>>> LaTeX-specific: the options and their values have no meaning outside of
>>>> that. I think that we should strive to use more generic options that
>>>> would at least be usable by other export engines.
>>>>
>>>>> Or is there any other reason why one would like to specify language opti=
>>> ons?
>>>>>
>>>>> Sadly I don't have the skills to suggest a patch...
>>>>>
>>>>> I definitely see Nick's point: simplicity is one of the most important
>>>>> features of org-mode. So a possible decision not to support csquotes
>>>>> is absolutely understandable.
>>>>
>>>> I'll be very surprised if there is no support for csquotes within a couple
>>>> of weeks (maybe within a couple of days :-) ) The question is "what form
>>>> will it take?"
>>>>
>>>>
>>>> Thomas S. Dye<tsd@tsdye.com>  wrote:
>>>>
>>>>> I'm wondering if a simpler solution than Nick's might be to replace the
>>>>> lists at the end of this code snippet with a variable, say
>>>>> org-export-latex-quote-mechanism.  Initially, the variable would be set
>>>>> to the second list.  If the user wanted something different, then the
>>>>> user would be responsible for setting the variable to the different
>>>>> quoting mechanism, whether it be \enquote{ or something else.  The user
>>>>> would also be responsible for making sure the LaTeX packages needed to
>>>>> support the quoting mechanism were loaded and functional.
>>>>> =20
>>>>> (defun org-export-latex-quotation-marks ()
>>>>>    "Export quotation marks depending on language conventions."
>>>>>    (let* ((lang (plist-get org-export-latex-options-plist :language))
>>>>> 	 (quote-rpl (if (equal lang "fr")
>>>>> 			'(("\\(\\s-\\)\"" "=C2=AB~")
>>>>> 			  ("\\(\\S-\\)\"" "~=C2=BB")
>>>>> 			  ("\\(\\s-\\)'" "`"))
>>>>> 		      '(("\\(\\s-\\|[[(]\\)\"" "``")
>>>>> 			("\\(\\S-\\)\"" "''")
>>>>> 			("\\(\\s-\\|(\\)'" "`")))))
>>>>> =20
>>>>> This might provide Org-mode the flexibility needed to support csquotes,
>>>>> but also leave open the possibility of supporting other packages, as
>>>>> well.
>>>>> =20
>>>>
>>>> Maybe - this is the kind of mechanism that is used for
>>>> org-export-latex-classes for example, so there is definitely
>>>> precedent. OTOH, the lists above look like hen scratchings (or line
>>>> noise if you prefer, or -- I'll get in trouble for this -- Perl
>>>> code :-)), so it would be easy to get things wrong if you have to
>>>> cut-and-paste-and-edit which I think one would have to do to customize
>>>> it: it's OK to expect *one* developer to get it right, but it's not
>>>> OK to expect 100 users to get it right.
>>>>
>>>> So it might be simpler to implement, but I'm not sure it might be
>>>> simpler to use. I've supported using existing mechanisms to implement
>>>> new behavior before and not disturbing the existing structure too much
>>>> (e.g. the revtex stuff that Sebastian Hoffert was (is?) working on).
>>>> But if it leads to e.g. an implementation that befuddles users, then
>>>> you end up with a flood of questions on the ML. So it's a balancing
>>>> act.
>>>>
>>>> BTW, you mention the possibility of supporting other packages. I didn't
>>>> find anything useful in the TeX FAQ but if there are "csquotes-like"
>>>> packages that people commonly (or perhaps uncommonly) use then a survey
>>>> of their capabilities might indicate the best way to go.
>>>>
>>>> Nick
>>>
>>> --=20
>>> Thomas S. Dye
>>> http://www.tsdye.com
>>>
>>
>>

-- 
Thomas S. Dye
http://www.tsdye.com