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

[Thomas S. Dye]

Hi Nick,

Nick Dokos <address@hidden> writes:

> 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 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 <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
http://www.tsdye.com