Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Thomas S. Dye t...@tsdye.com wrote:
Hi Nick,
Nick Dokos nicholas.do...@hp.com writes:
Thomas S. Dye t...@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.do...@hp.com writes:
Responses to Frederik and Tom inline.
Frederik freak.f...@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 t...@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
Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Hi Nick and Tom, Nick Dokos nicholas.do...@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: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Am 08.07.2011 04:09, schrieb Nick Dokos:
Thomas S. Dyet...@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 Dokosnicholas.do...@hp.com writes:
Responses to Frederik and Tom inline.
Frederikfreak.f...@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. Dyet...@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: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Frederik freak.f...@gmail.com writes:
Am 08.07.2011 04:09, schrieb Nick Dokos:
Thomas S. Dyet...@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 Dokosnicholas.do...@hp.com writes:
Responses to Frederik and Tom inline.
Frederikfreak.f...@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. Dyet...@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: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Nick Dokos nicholas.do...@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.
pgpd6PAdYP6OT.pgp
Description: PGP signature
Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Stefan Nobis stefan...@snobis.de wrote:
Nick Dokos nicholas.do...@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: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Nick Dokos nicholas.do...@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. pgpoRt8r2jkK9.pgp Description: PGP signature
Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
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 cover90% 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: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Frederik freak.f...@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 cover90% 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: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Responses to Frederik and Tom inline.
Frederik freak.f...@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 t...@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: [O] LaTex export: How to use `csquotes' and `\enquote{}'
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.do...@hp.com writes:
Responses to Frederik and Tom inline.
Frederik freak.f...@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 t...@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: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Thomas S. Dye t...@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.do...@hp.com writes:
Responses to Frederik and Tom inline.
Frederik freak.f...@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 t...@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: [O] LaTex export: How to use `csquotes' and `\enquote{}'
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: [O] LaTex export: How to use `csquotes' and `\enquote{}'
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: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Frederik freak.f...@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: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Thomas S. Dye t...@tsdye.com wrote:
Frederik freak.f...@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
Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
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: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Frederik freak.f...@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
[O] LaTex export: How to use `csquotes' and `\enquote{}'
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: [O] LaTex export: How to use `csquotes' and `\enquote{}'
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.f...@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
