From: "Mark E. Shoulson" <mark@kli.org>
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Smart Quotes Exporting
Date: Fri, 01 Jun 2012 18:41:56 -0400 [thread overview]
Message-ID: <4FC94534.8000309@kli.org> (raw)
In-Reply-To: <878vg72bzy.fsf@gmail.com>
On 06/01/2012 01:11 PM, Nicolas Goaziou wrote:
> Hello,
>
> "Mark E. Shoulson"<mark@kli.org> writes:
>
>> Oh, certainly; they're all a disaster. I think I said that in the
>> writeup at the top. This is just proof of concept, nothing is in the
>> right place, nothing is properly documented. They have to be
>> defcustoms, there needs to be a good :type in the defcustom as well as
>> a proper docstring. You'll get no argument from me about the lack (or
>> inaccuracy) of docstrings and such. I hadn't gotten that far yet.
>> I said the patch was only if you wanted to tinker with the development
>> as this progresses.
> No worries, I was just making some comments before forgetting about
> them.
Ah, ok. Good! Thanks.
>>> +(defun org-e-latex--quotation-marks (text info)
>>> + (org-export-quotation-marks text info org-e-latex-quote-replacements))
>>> + ;; (mapc (lambda(l)
>>> + ;; (let ((start 0))
>>> + ;; (while (setq start (string-match (car l) text start))
>>> + ;; (let ((new-quote (concat (match-string 1 text) (cdr l))))
>>> + ;; (setq text (replace-match new-quote t t text))))))
>>> + ;; (cdr (or (assoc (plist-get info :language) org-e-latex-quotes)
>>> + ;; ;; Falls back on English.
>>> + ;; (assoc "en" org-e-latex-quotes))))
>>> + ;; text)
>>> Use directly `org-e-latex-quote-replacements' in code then.
>> Not sure I understand this comment.
> Since `org-e-latex--quotation-marks' just calls
> `org-export-quotation-marks', you can remove completely the former from
> "org-export.el" and use the latter instead.
Well, that was done on purpose, and maybe the reason will make sense.
As I see it, each exporter should be able to have its own smartifier
function, and the export engine should make no assumptions about that:
just call the individual exporter's function. On the other hand, many
(but perhaps not all!) of the exporters may find themselves using
essentially the same code just with different replacement strings. So I
thought that "general-purpose" should be in org-export.el, just for the
convenience of exporters should they choose to make use of it. So, many
of the exporters' smartifier functions will really just be calls to the
more general-purpose function.
Does that make sense?
>> So... there's the filter-parse-tree-functions hook gets applied within
>> the parse tree... so a back-end can add a function to that list which
>> looks over the parse-tree and watches for these border cases (and also
>> the ones within ordinary strings). Looks like it's going to be tough
>> to work in any flexibility to define further per-language or
>> per-backend cleverness to handle anything beyond the "canonical set"
>> of open-double, close-double, open-single, close-single, and mid-word.
>>
>> To be sure, anything we do will most assuredly fail even on some
>> fairly reasonable input, in which case the users are pretty much on
>> their own and will have to do things the hard way. And I could use
>> that as the answer here, that, "well, it'll work only within
>> plain-text strings" (and I might possibly still have to use that
>> answer), but I would rather include the situations you bring up in the
>> supported set and not throw up my hands at it. So, yes, will look at
>> that.
> Actually it isn't very hard to handle this problem. But it will be
> different than the fontification used in an Org buffer.
Yes, the fontification on-screen is different, and uses a rather
different function--but if I can help it, the same regexps! So things
work the same everywhere.
I also started thinking a little about what you write below, how we can
inspect the characters just after or before quotes at the very beginning
or end of each chunk. It would be nice if it could all be encapsulated
neatly in the regexp(s).
> As a first approximation, I can imagine a function accepting an element,
> an object or a secondary string and returning an equivalent element,
> object or secondary string, with its quotes "smartified". The algorithm
> could go like this:
>
> Walk element/object/secondary-string's contents .
Need it be element/object/secondary-string? At the bottom level it's
always about strings; the higher levels don't affect the processing of
each string in isolation. Do we need to intercept it at the element
level or just wait to grab things in the plain-text filter, since we
have access at that point too?
(Might also be that my understanding of the process and the nature of
elements is faulty or limited. Will have to see what works.)
>
> 1. When a string is encountered:
>
> 1. If it has a quote as its first or last position, check for
> objects before or after the string to guess its status. An
> object never starts with a white space, but you may have to
> check :post-blank property in order to know if previous object
> had white spaces at its end.
Hmm, this may in fact answer my question above: you need to be able to
get at the object level to test the post-blank. I'll experiment.
> 2. For each quote everywhere else in the string, your regexp can
> handle it fine.
>
> 2. When an object belonging to `org-element-recursive-objects' is
> encountered, apply the function to this object.
>
> 3. Accumulate returned strings or objects.
>
> Use accumulated data as the contents of the new object to return (i.e.
> just add the type and the same properties at the beginning of this list
> if it was an object or an element, return it as-is if that was
> a secondary string).
>
> On the elements side, only paragraphs, verse-blocks and table-rows can
> directly contain quotes. Also, headline, inlinetask item and
> footnote-reference have secondary strings containing quotes.
I also haven't yet worked in smarts (especially in the on-screen
fontifier) for things like not fontifying inside comments or verbatim
strings, etc. That'll come in time.
> I'm not sure yet where and how to install such a function, but I will
> think about it when it is implemented.
Uuum... Maybe org-export-filter-parse-tree-functions?
~mark
next prev parent reply other threads:[~2012-06-01 22:42 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
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 [this message]
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=4FC94534.8000309@kli.org \
--to=mark@kli.org \
--cc=emacs-orgmode@gnu.org \
--cc=n.goaziou@gmail.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).