From: "Mark E. Shoulson" <mark@kli.org>
To: emacs-orgmode@gnu.org
Subject: Re: "Smart" quotes
Date: Fri, 25 May 2012 18:51:12 -0400 [thread overview]
Message-ID: <4FC00CE0.6060308@kli.org> (raw)
In-Reply-To: <87zk8w6v4q.fsf@gmail.com>
On 05/25/2012 01:14 PM, Nicolas Goaziou wrote:
> Hello,
>
> "Mark E. Shoulson"<mark@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
next prev parent reply other threads:[~2012-05-25 22:51 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-22 3:32 "Smart" quotes Mark E. Shoulson
2012-05-23 22:17 ` Nicolas Goaziou
2012-05-24 3:05 ` Mark E. Shoulson
2012-05-25 17:14 ` Nicolas Goaziou
2012-05-25 17:51 ` Jambunathan K
2012-05-25 22:51 ` Mark E. Shoulson [this message]
2012-05-26 6:48 ` Nicolas Goaziou
2012-05-29 1:30 ` Mark E. Shoulson
2012-05-29 17:57 ` Nicolas Goaziou
2012-05-30 0:51 ` Mark E. Shoulson
2012-05-31 1:50 ` (no subject) Mark Shoulson
2012-05-31 13:38 ` Nicolas Goaziou
2012-05-31 23:26 ` Smart Quotes Exporting (Was: Re: (no subject)) Mark E. Shoulson
2012-06-01 17:11 ` Smart Quotes Exporting Nicolas Goaziou
2012-06-01 22:41 ` Mark E. Shoulson
2012-06-03 3:16 ` Mark E. Shoulson
2012-06-06 2:14 ` Mark E. Shoulson
2012-06-07 19:21 ` Nicolas Goaziou
2012-06-11 1:28 ` Mark Shoulson
2012-06-12 13:21 ` Nicolas Goaziou
2012-06-15 16:20 ` Mark Shoulson
2012-06-19 9:26 ` Nicolas Goaziou
2012-08-07 23:18 ` Bastien
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=4FC00CE0.6060308@kli.org \
--to=mark@kli.org \
--cc=emacs-orgmode@gnu.org \
/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).