Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Frederik writes: > Am 08.07.2011 04:09, schrieb Nick Dokos: >> Thomas S. Dye 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 agree with Nick - simple and clean. > > What would be the purpose of the variable > org-export-latex-single-quote'? If you intend to support \enquote*{, > then perhaps there should be an additional variable for the single > closing quote (which would be `}' again...) > > Then you'd have four variables: > org-export-latex-open-double-quotes > org-export-latex-close-double-quotes > org-export-latex-open-single-quote > org-export-latex-close-single-quote > > But perhaps I'm misguided... > > Regards. Hi Frederik, I think you're right. I was looking at the existing code, which has three list entries, and not thinking through to the csquotes solution. Thanks for pointing this out. All the best, Tom > > > >>> 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 support
Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Am 08.07.2011 04:09, schrieb Nick Dokos: Thomas S. Dye 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 agree with Nick - simple and clean. What would be the purpose of the variable `org-export-latex-single-quote'? If you intend to support \enquote*{, then perhaps there should be an additional variable for the single closing quote (which would be `}' again...) Then you'd have four variables: org-export-latex-open-double-quotes org-export-latex-close-double-quotes org-export-latex-open-single-quote org-export-latex-close-single-quote But perhaps I'm misguided... Regards. 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 -- Frederik
Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Hi Nick and Tom, Nick Dokos writes: > 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). I'm following this thread and waiting for the patch -- would be nice to apply it before 7.6.1 (this WE), which will go to Emacs. Good luck! -- Bastien
Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Thomas S. Dye wrote: > Hi Nick, > > Nick Dokos writes: > > > Thomas S. Dye 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 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 structur
Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Hi Nick, Nick Dokos writes: > Thomas S. Dye 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 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 >> > -- Thomas S. Dye http://www.tsdye.
Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Thomas S. Dye 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 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 >
Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
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 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=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 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
Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
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=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 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
Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Frederik writes: > Am 06.07.2011 22:20, schrieb Nick Dokos: >> The problem is the usual exponential growth of possibilities and how you >> manage them: if you read the babel manual and the csquotes manual and all >> the options that you can have, your head starts spinning (well, *my* head >> starts spinning). I tend to think of all the possibilities and despair >> over covering them all, whereas org-mode tends to make simplifying >> assumptions that will cover>90% of the cases (if the simplifying >> assumptions are good ones). I think we need such an assumption here. >> >> Here are some points to keep in mind while working on a patch: >> >> o csquotes.sty is part of the texlive-latex-extra package on Ubuntu (and >>probably something similar on other Linux distros and possibly MacOS X - >>hunoz about Windoz?) > In the Windows-world MikTeX is quite common, as far as I know. I use > MikTeX on Windows and it installs packages one includes directly from > the net if they aren't already installed. > > IMHO the csquotes package becomes more and more important. For example > biblatex, which will become the successor of BibTeX, relies on > csquotes, when using a language other than English. > >> o the (LaTeX) babel package and csquotes have their own (different) >>conventions for specifying languages and dialects. In some cases, a >>single language can have multiple options for how to quote things. >>The proposal below explicitly does *not* deal with these complications. >> >> My initial reaction to how one would use csquotes was to use the +OPTIONS >> line, something like this: >> >> #+OPTIONS: enquote:t language:fr >> >> The language option would trigger the inclusion of the babel package with >> the (correct) language option (e.g. "en" -> "english", "de" -> "ngerman", >> "fr" -> "french", etc.) >> >> The enquote part would trigger 1) the inclusion of the csquotes package (and >> since you specify it explicitly, it is your responsibility to make sure >> that it be installed on your system) and 2) the translation of "foo" to >> \enquote{foo}. Without it, "foo" goes to ``foo'' no matter what the language >> is set to. >> > > 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 > > 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. > > Regards Aloha all, 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. Any thoughts? All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Am 06.07.2011 22:20, schrieb Nick Dokos: The problem is the usual exponential growth of possibilities and how you manage them: if you read the babel manual and the csquotes manual and all the options that you can have, your head starts spinning (well, *my* head starts spinning). I tend to think of all the possibilities and despair over covering them all, whereas org-mode tends to make simplifying assumptions that will cover>90% of the cases (if the simplifying assumptions are good ones). I think we need such an assumption here. Here are some points to keep in mind while working on a patch: o csquotes.sty is part of the texlive-latex-extra package on Ubuntu (and probably something similar on other Linux distros and possibly MacOS X - hunoz about Windoz?) In the Windows-world MikTeX is quite common, as far as I know. I use MikTeX on Windows and it installs packages one includes directly from the net if they aren't already installed. IMHO the csquotes package becomes more and more important. For example biblatex, which will become the successor of BibTeX, relies on csquotes, when using a language other than English. o the (LaTeX) babel package and csquotes have their own (different) conventions for specifying languages and dialects. In some cases, a single language can have multiple options for how to quote things. The proposal below explicitly does *not* deal with these complications. My initial reaction to how one would use csquotes was to use the +OPTIONS line, something like this: #+OPTIONS: enquote:t language:fr The language option would trigger the inclusion of the babel package with the (correct) language option (e.g. "en" -> "english", "de" -> "ngerman", "fr" -> "french", etc.) The enquote part would trigger 1) the inclusion of the csquotes package (and since you specify it explicitly, it is your responsibility to make sure that it be installed on your system) and 2) the translation of "foo" to \enquote{foo}. Without it, "foo" goes to ``foo'' no matter what the language is set to. 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 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. Regards -- Frederik
Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Nick Dokos writes: > I'd worry a bit about adding the newcommand in the preamble during > org processing: what would happen if I tried to use csquotes then? It should be either the newcommand or else use csquotes. Mixing both would be no good idea. -- Until the next mail..., Stefan. pgpoRt8r2jkK9.pgp Description: PGP signature
Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Stefan Nobis wrote: > Nick Dokos writes: > > > Here are some points to keep in mind while working on a patch: > > > o csquotes.sty is part of the texlive-latex-extra package on Ubuntu > > (and probably something similar on other Linux distros and > > possibly MacOS X - hunoz about Windoz?) > > On MacOS the MacTeX distribution is quite common and in this case a > complete TeXLive (including csquotes) is installed. > > On Windows MikTeX is probably the defacto standard and IIRC it > supports installing packages on demand (I'm not sure wether csquotes > is included in the basic installation, but on the other hand I would > assume that a complete installation is not uncommen). > OK, that's good. > But another suggestion: > > Always use \enquote for quotations in the exported text. In the > preambel of the document either include csquotes or provide a simple > macro enquote like the very simple > > \newcommand{\enquote}[1]{``#1''} > > Maybe a bit more hackery might be needed for some special cases, but > with this approach it would be quite easy to change quotations styles > later on. > Not too thrilled about this: the current handling for the bare-bones default case works OK and it could be easily extended to handle the csquotes case. I'd worry a bit about adding the newcommand in the preamble during org processing: what would happen if I tried to use csquotes then? Would I get a conflict? Would I have unpredictable situations where sometimes I'd get the bare-bones definition and sometimes the csquotes one? All of these can be answered of course, but the point is that you can't leave it to accident. > BTW: IMHO babel and csquotes should be considered standard packages > for all non-US texts (and even for US texts they have some > advantages). > Agreed. Nick
Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Nick Dokos writes: > Here are some points to keep in mind while working on a patch: > o csquotes.sty is part of the texlive-latex-extra package on Ubuntu > (and probably something similar on other Linux distros and > possibly MacOS X - hunoz about Windoz?) On MacOS the MacTeX distribution is quite common and in this case a complete TeXLive (including csquotes) is installed. On Windows MikTeX is probably the defacto standard and IIRC it supports installing packages on demand (I'm not sure wether csquotes is included in the basic installation, but on the other hand I would assume that a complete installation is not uncommen). But another suggestion: Always use \enquote for quotations in the exported text. In the preambel of the document either include csquotes or provide a simple macro enquote like the very simple \newcommand{\enquote}[1]{``#1''} Maybe a bit more hackery might be needed for some special cases, but with this approach it would be quite easy to change quotations styles later on. BTW: IMHO babel and csquotes should be considered standard packages for all non-US texts (and even for US texts they have some advantages). -- Until the next mail..., Stefan. pgpd6PAdYP6OT.pgp Description: PGP signature
Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Thomas S. Dye wrote: > Frederik writes: > > >> Apparently someone tried a simple hack: > >> http://osdir.com/ml/emacs-orgmode-gnu/2010-01/msg00681.html > >> > >> When I find the time I will try this... > > > > I've tried the hack and for me this works pretty well. It's static but > > this doesn't really matter as I always stick to `csquotes' > > > > I think it shouldn't be too difficult to implement a new > > variable/switch whether the standard behaviour or the one provided by > > the hack is going to be used. One would only have to insert an > > additional if-clause in the defun the hack alters. > > > > Regards > > Yes, please do suggest a patch to support csquotes. I've been using > LaTeX to write the American dialect of English, so haven't had a need > for the package. As it happens, I spent some time yesterday editing by > hand an article that requires quotations in the British dialect of > English. IIUC, csquotes would have done this work for me with the > change of a single option. > > Perhaps others on the list with experience using the LaTeX babel package > can chime in here. > > Thanks for an interesting set of ideas. > The problem is the usual exponential growth of possibilities and how you manage them: if you read the babel manual and the csquotes manual and all the options that you can have, your head starts spinning (well, *my* head starts spinning). I tend to think of all the possibilities and despair over covering them all, whereas org-mode tends to make simplifying assumptions that will cover >90% of the cases (if the simplifying assumptions are good ones). I think we need such an assumption here. Here are some points to keep in mind while working on a patch: o csquotes.sty is part of the texlive-latex-extra package on Ubuntu (and probably something similar on other Linux distros and possibly MacOS X - hunoz about Windoz?) o because of the above, usage of csquotes has to be optional, default to "no". o there is hackish special treatment of french quotes in org-export-latex-quotation-marks: that could be folded into the more general treatment that the patch would provide at the cost of possible backward incompatibility for some org files. o it's currently not possible to specify a language in an +OPTIONS line in an org file: you can only set it through lisp. That should probably be changed. o org-mode specifies languages using the two-letter country abbreviation and does not worry about dialects/sublanguages. o the (LaTeX) babel package and csquotes have their own (different) conventions for specifying languages and dialects. In some cases, a single language can have multiple options for how to quote things. The proposal below explicitly does *not* deal with these complications. My initial reaction to how one would use csquotes was to use the +OPTIONS line, something like this: #+OPTIONS: enquote:t language:fr The language option would trigger the inclusion of the babel package with the (correct) language option (e.g. "en" -> "english", "de" -> "ngerman", "fr" -> "french", etc.) The enquote part would trigger 1) the inclusion of the csquotes package (and since you specify it explicitly, it is your responsibility to make sure that it be installed on your system) and 2) the translation of "foo" to \enquote{foo}. Without it, "foo" goes to ``foo'' no matter what the language is set to. IOW, here is the spec that I'm proposing (using "fr" as a non-"en" language which also uses a different quotation style: guillemets rather than quotes): | OPTIONS | org-export-default-language | \usepackage[options]{package} | "foo" -> | comments | |---+-++---+| | | en | | ``foo'' | ok | | | fr | [french]{babel} | ``foo'' | quotes, not guillemets | | enquote:t | en | [babel]{csquotes} | \enquote{foo} | ok | | enquote:t | fr | [french]{babel}, [babel]{csquotes} | \enquote{foo} | ok | | enquote:t language:fr | ANY | [french]{babel}, [babel]{csquotes} | \enquote{foo} | ok | In the last case, the language specified in the +OPTIONS line is operative, no matter what the default language is. In the second case, we have a backward incompatibility: it does not do the right thing for a default setting of "fr", but french speakers could restore proper behavior by installing the csquotes package and customizing the (proposed) org-export-latex-with-enquote variable, corresponding to the enquote option, to t: that would provide the same output as the hack does today.
Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Frederik writes: >> Apparently someone tried a simple hack: >> http://osdir.com/ml/emacs-orgmode-gnu/2010-01/msg00681.html >> >> When I find the time I will try this... > > I've tried the hack and for me this works pretty well. It's static but > this doesn't really matter as I always stick to `csquotes' > > I think it shouldn't be too difficult to implement a new > variable/switch whether the standard behaviour or the one provided by > the hack is going to be used. One would only have to insert an > additional if-clause in the defun the hack alters. > > Regards Yes, please do suggest a patch to support csquotes. I've been using LaTeX to write the American dialect of English, so haven't had a need for the package. As it happens, I spent some time yesterday editing by hand an article that requires quotations in the British dialect of English. IIUC, csquotes would have done this work for me with the change of a single option. Perhaps others on the list with experience using the LaTeX babel package can chime in here. Thanks for an interesting set of ideas. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Apparently someone tried a simple hack: http://osdir.com/ml/emacs-orgmode-gnu/2010-01/msg00681.html When I find the time I will try this... I've tried the hack and for me this works pretty well. It's static but this doesn't really matter as I always stick to `csquotes' I think it shouldn't be too difficult to implement a new variable/switch whether the standard behaviour or the one provided by the hack is going to be used. One would only have to insert an additional if-clause in the defun the hack alters. Regards -- Frederik
Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Hi Tom! It looks more cumbersome than it is in practice. You can use C-c C-l to add the link and depending on the length of the link type name, it can be very close to the same number of keystrokes you'd need for \enquote{}. During normal LaTex editing I never type `\enquote{}'. Of course I type " and AucTeX automatically inserts `\enquote{' at the beginning of a word and `}' at the end of a word, depending on whether `csquotes' is loaded or not. Apparently someone tried a simple hack: http://osdir.com/ml/emacs-orgmode-gnu/2010-01/msg00681.html When I find the time I will try this... Thanks & Regards. -- Frederik
Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Frederik writes: > Hey Tom! > >> One way to use \enquote in your LaTeX export is described here: >> >> http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-10-3 >> >> [[latex:enquote][Das ist ein Test]] will export as \enquote{Das ist ein >> Test}. > > Thanks for your hint. But this is a rather cumbersome way to quote > text... It would be handy to have " directly converted to enquote - > this should be possible, because org-mode is obviously able to > distinguish whether to use `` or '' at the beginning and at end of a > word, respectively. > > Regards. Aloha Frederik, It looks more cumbersome than it is in practice. You can use C-c C-l to add the link and depending on the length of the link type name, it can be very close to the same number of keystrokes you'd need for \enquote{}. Please let me know if you're able to configure Org-mode to translate " to \enquote{}. That would be a worthwhile addition to either the LaTeX export tutorial or Org Hacks on Worg. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Hey Tom! One way to use \enquote in your LaTeX export is described here: http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-10-3 [[latex:enquote][Das ist ein Test]] will export as \enquote{Das ist ein Test}. Thanks for your hint. But this is a rather cumbersome way to quote text... It would be handy to have " directly converted to enquote - this should be possible, because org-mode is obviously able to distinguish whether to use `` or '' at the beginning and at end of a word, respectively. Regards. -- Frederik
Re: [O] LaTex export: How to use `csquotes' and `\enquote{}'
Aloha Frederik, Welcome to Org-mode. One way to use \enquote in your LaTeX export is described here: http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-10-3 [[latex:enquote][Das ist ein Test]] will export as \enquote{Das ist ein Test}. hth, Tom Frederik writes: > Hi there! > > I just started using org-mode - what a fantastic piece of software! > > Now I wonder how to make use of one of the best LaTeX-packages out > there: `csquotes'. I figured out how to include the package in the > header by altering the corresponding variable, but I didn't find any > hint how to make use of the `\enquote' command provided by `csquotes'. > > I don't want my quotes to be quoted like this: > ``Das ist ein Test'' > but like this: > \enquote{Das ist ein Test} > > I searched the web and found some feature requests on this list > concerning `csquotes' but the documentation and worg don't mention > this topic - except for http://orgmode.org/worg/org-faq.html where > csquotes' is included in a source code listing, but there is no > further explanation. > > Is there a way to use `csquotes'? > > Any hints would be appreciated - Thanks & regards -- Thomas S. Dye http://www.tsdye.com
[O] LaTex export: How to use `csquotes' and `\enquote{}'
Hi there! I just started using org-mode - what a fantastic piece of software! Now I wonder how to make use of one of the best LaTeX-packages out there: `csquotes'. I figured out how to include the package in the header by altering the corresponding variable, but I didn't find any hint how to make use of the `\enquote' command provided by `csquotes'. I don't want my quotes to be quoted like this: ``Das ist ein Test'' but like this: \enquote{Das ist ein Test} I searched the web and found some feature requests on this list concerning `csquotes' but the documentation and worg don't mention this topic - except for http://orgmode.org/worg/org-faq.html where `csquotes' is included in a source code listing, but there is no further explanation. Is there a way to use `csquotes'? Any hints would be appreciated - Thanks & regards -- Frederik