On 05/25/2012 01:14 PM, Nicolas Goaziou wrote:
Hello,
"Mark E. Shoulson"<m...@kli.org> writes:
Hm. I like the idea, but it raises some questions for me. It would
be particularly good if this could share code/custom variables with
the pieces of the (new) exporter that make smart quotes on export.
That way we could be sure that what it looks like onscreen would also
be what it looked like when exported.
I could be interesting, but keep in mind that no matter how "smart" your
quotes are, they will fail in some situations. So, it will have to be
optional for export, independently on their in-buffer status.
The OPTIONS keyword may be used, with q:t and q:nil items.
"Smart" quotes absolutely have to be optional, and probably disabled by
default. They're going to fail sometimes, so they should only be there
when you ask for them. Smart-quotes-for-export and
smart-quotes-onscreen need to be settable independently, yes.
Smart-quotes-for-export needs to be settable per-file/per-buffer, with
OPTIONS or something. Smart-quotes-onscreen doesn't have to be
buffer-local, though it might be a good idea. Using q:t or maybe ":t in
options seems perfectly good for setting exporting smart quotes. It
still would be good if onscreen and export could share code.
Looking at contrib/lisp/org-e-latex.el at an upcoming exporter for
such things, I see a variable org-e-latex-quotes, which has nice
language-aware parts... but misses an important point. Each language
gets to define one regexp for opening quotes, one for closing quotes,
and one for single quotes. But don't we want to talk about (at least)
two levels of quotes, see your own reference[fn:1]?
Probably. But that's going to be somewhat harder.
Single quotes would be for inner, second-level quotes (if we're using
double straight quotes according to (American) English usage, I would
guess we'd be using single straight quotes the same way). That works
okay for English, where a single apostrophe not part of a grouping
construct is going to be interpreted as a "close" single quote and
look right for an apostrophe.
The regexp may be able to tell level 1 from level 2 quotes.
Do you mean that the author would use the same characters for both first
and second level quotes, and the regexp would be smart enough to
distinguish which level each was at? I don't think that's possible, and
you probably don't either. What I meant, and you probably did as well,
was that if we use apostrophes for second-level quotes, a regexp can be
smart enough to tell the difference between a second-level quote and a
non-quote apostrophe....
It might not work so good in French where apostrophes are also used,
There are no spaces around apostrophes, so they shouldn't be caught by
the regexp.
which is what you say here. They *should* be caught by a regexp, but
not the same one; they need to be smartified also, just not necessarily
treated the same as second-level quotes.
but also single guillemets for inner-level quotes.
What are single guillemets? I don't think there is such thing in French.
You're right; the Wikipedia page says that French uses quote-marks or
the same double-chevrons for inner quotes. I thought it used \lsaquo
and \rsaquo, « like ‹ this › ». Looks like it does in Swiss typography
for various languages, according to the page. Danish also uses the
single-chevrons (pointing the other direction), and Azerbaijani and
Basque, etc... Whatever. What I meant was, if people are going to be
writing using straight ascii quotes and expect them to be changed into
language-appropriate quotes, they're going to want something like
"this is a 'quote', and that's all you need to know."
becoming, for instance
«this is a ‹quote›, and that’s all you need to know.»
that is, it should be possible to use the single quotes for inner
quotes, which would mean more than just opening/closing/single in the
org-e-latex-quotes (and analogous variables in other exporters). Being
able to determine when you need ‹› and when ’ might be a little
uncertain, but it isn't hard to make a regexp that can make a decent
guess at it.
Should/can we consider extending this for the new exporters?
I think it would be a good addition to the export mechanism, if you want
to give it a try.
I'd love to get org more export-friendly. I'll see what I can
understand of the (new) export code.
(I'm looking forward to HTML and ODT exporters that can do smart
quotes; the straight quotes are really the main jarring things about
using Org as a lightweight markup and exporting into something
fancier)
A function, provided in org-export, could help changing dumb quotes into
smart quotes in plain text. Then, it would be easier for back-ends to
provide the feature, if they wanted to.
That sounds like a possibility, might make for good generic handling,
only one bit of code to treat everything consistently... yeah, I didn't
like the idea at first, I'm starting to like it more. I'll think on it too.
~mark
