From: Frederik <freak.fred@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: LaTex export: How to use `csquotes' and `\enquote{}'
Date: Fri, 08 Jul 2011 17:49:07 +0200 [thread overview]
Message-ID: <iv78td$fst$1@dough.gmane.org> (raw)
In-Reply-To: <4521.1310090982@alphaville.dokosmarshall.org>
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
next prev parent reply other threads:[~2011-07-08 15:49 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-04 16:54 LaTex export: How to use `csquotes' and `\enquote{}' Frederik
2011-07-04 23:06 ` Thomas S. Dye
2011-07-05 20:26 ` Frederik
2011-07-05 22:56 ` Thomas S. Dye
2011-07-06 6:22 ` Frederik
2011-07-06 14:48 ` Frederik
2011-07-06 16:37 ` Thomas S. Dye
2011-07-06 20:20 ` Nick Dokos
2011-07-07 8:02 ` Stefan Nobis
2011-07-07 15:10 ` Nick Dokos
2011-07-07 17:22 ` Stefan Nobis
2011-07-07 19:11 ` Frederik
2011-07-07 22:07 ` Thomas S. Dye
2011-07-07 22:53 ` Nick Dokos
2011-07-07 23:06 ` Thomas S. Dye
2011-07-08 2:09 ` Nick Dokos
2011-07-08 6:07 ` Thomas S. Dye
2011-07-08 6:46 ` Nick Dokos
2011-07-08 6:58 ` Bastien
2011-07-08 15:49 ` Frederik [this message]
2011-07-08 16:13 ` Thomas S. Dye
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='iv78td$fst$1@dough.gmane.org' \
--to=freak.fred@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).