From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Mark E. Shoulson" Subject: Re: "Smart" quotes Date: Fri, 25 May 2012 18:51:12 -0400 Message-ID: <4FC00CE0.6060308@kli.org> References: <4FBB08CA.5060705@kli.org> <87d35u8rvk.fsf@gmail.com> <4FBDA56E.5030901@kli.org> <87zk8w6v4q.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:56032) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SY3Lp-0004fh-If for emacs-orgmode@gnu.org; Fri, 25 May 2012 18:51:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SY3Ln-0002kl-DR for emacs-orgmode@gnu.org; Fri, 25 May 2012 18:51:17 -0400 Received: from pi.meson.org ([96.56.207.26]:47252) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1SY3Ln-0002kW-8s for emacs-orgmode@gnu.org; Fri, 25 May 2012 18:51:15 -0400 In-Reply-To: <87zk8w6v4q.fsf@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org On 05/25/2012 01:14 PM, Nicolas Goaziou wrote: > Hello, > > "Mark E. Shoulson" 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