emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nick Dokos <nicholas.dokos@hp.com>
To: "Thomas S. Dye" <tsd@tsdye.com>
Cc: Frederik <freak.fred@gmail.com>,
	nicholas.dokos@hp.com, emacs-orgmode@gnu.org
Subject: Re: LaTex export: How to use `csquotes' and `\enquote{}'
Date: Thu, 07 Jul 2011 22:09:42 -0400	[thread overview]
Message-ID: <4521.1310090982@alphaville.dokosmarshall.org> (raw)
In-Reply-To: Message from tsd@tsdye.com (Thomas S. Dye) of "Thu, 07 Jul 2011 13:06:17 -1000." <m1k4bthes6.fsf@tsdye.com>

Thomas S. Dye <tsd@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.dokos@hp.com> writes:
> 
> > Responses to Frederik and Tom inline.
> >
> > Frederik <freak.fred@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 <tsd@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
> 

  reply	other threads:[~2011-07-08  2:27 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-04 16:54 LaTex export: How to use `csquotes' and `\enquote{}' Frederik
2011-07-04 23:06 ` Thomas S. Dye
2011-07-05 20:26   ` Frederik
2011-07-05 22:56     ` Thomas S. Dye
2011-07-06  6:22       ` Frederik
2011-07-06 14:48         ` Frederik
2011-07-06 16:37           ` Thomas S. Dye
2011-07-06 20:20             ` Nick Dokos
2011-07-07  8:02               ` Stefan Nobis
2011-07-07 15:10                 ` Nick Dokos
2011-07-07 17:22                   ` Stefan Nobis
2011-07-07 19:11               ` Frederik
2011-07-07 22:07                 ` Thomas S. Dye
2011-07-07 22:53                   ` Nick Dokos
2011-07-07 23:06                     ` Thomas S. Dye
2011-07-08  2:09                       ` Nick Dokos [this message]
2011-07-08  6:07                         ` Thomas S. Dye
2011-07-08  6:46                           ` Nick Dokos
2011-07-08  6:58                             ` Bastien
2011-07-08 15:49                         ` Frederik
2011-07-08 16:13                           ` Thomas S. Dye

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4521.1310090982@alphaville.dokosmarshall.org \
    --to=nicholas.dokos@hp.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=freak.fred@gmail.com \
    --cc=tsd@tsdye.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).