From mboxrd@z Thu Jan 1 00:00:00 1970 From: tsd@tsdye.com (Thomas S. Dye) Subject: Re: LaTex export: How to use `csquotes' and `\enquote{}' Date: Thu, 07 Jul 2011 13:06:17 -1000 Message-ID: References: <6663.1309983647@alphaville.americas.hpqcorp.net> <6920.1310079233@alphaville.americas.hpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([140.186.70.92]:42633) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QexeO-0001Pq-0T for emacs-orgmode@gnu.org; Thu, 07 Jul 2011 19:06:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QexeK-0008HE-2r for emacs-orgmode@gnu.org; Thu, 07 Jul 2011 19:06:27 -0400 Received: from oproxy8-pub.bluehost.com ([69.89.22.20]:56798) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1QexeJ-0008Gk-SO for emacs-orgmode@gnu.org; Thu, 07 Jul 2011 19:06:24 -0400 In-Reply-To: <6920.1310079233@alphaville.americas.hpqcorp.net> (Nick Dokos's message of "Thu, 07 Jul 2011 18:53:53 -0400") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: nicholas.dokos@hp.com Cc: Frederik , emacs-orgmode@gnu.org 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. All the best, Tom =20 Nick Dokos writes: > Responses to Frederik and Tom inline. > > Frederik 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 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