[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas S. Dye
Subject: Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Date: Fri, 08 Jul 2011 06:13:59 -1000

Frederik <address@hidden> writes:

> Am 08.07.2011 04:09, schrieb Nick Dokos:
>> Thomas S. Dye<address@hidden>  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,

>>> All the best,
>>> Tom
>>> =20
>>> Nick Dokos<address@hidden>  writes:
>>>> Responses to Frederik and Tom inline.
>>>> Frederik<address@hidden>  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<address@hidden>  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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]