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

[Nick Dokos]

Thomas S. Dye <address@hidden> wrote:

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

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