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
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=guillemets
>>
>
> 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 options?
>>
>> 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.
>>
>> (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-\\)\"" "«~")
>> ("\\(\\S-\\)\"" "~»")
>> ("\\(\\s-\\)'" "`"))
>> '(("\\(\\s-\\|[[(]\\)\"" "``")
>> ("\\(\\S-\\)\"" "''")
>> ("\\(\\s-\\|(\\)'" "`")))))
>>
>> This might provide Org-mode the flexibility needed to support csquotes,
>> but also leave open the possibility of supporting other packages, as
>> well.
>>
>
> 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
--
Thomas S. Dye
http://www.tsdye.com
