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 >