[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] Smart Quotes Exporting
From: |
Nicolas Goaziou |
Subject: |
Re: [O] Smart Quotes Exporting |
Date: |
Tue, 12 Jun 2012 15:21:05 +0200 |
Hello,
Mark Shoulson <address@hidden> writes:
>> ASCII exporter also handle UTF-8. So it's good to have there too.
>
> Really? I would have thought ASCII meant ASCII, as in 7-bit clean
> text.
org-e-ascii.el (as old org-ascii.el) handles ASCII, Latin1 and UTF-8
encodings.
> It looked to me like your solution would essentially boil down to "do
> string handling when there's a string, otherwise recur down and find
> the strings," which essentially means apply it to all the
> strings... and there were already functions out there applying things
> to strings, so this can just ride along with them. Here, let's look
> at your suggestion and see if we can find what I missed:
>
> ] Walk element/object/secondary-string's contents .
> ]
> ] 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.
> ]
> ] 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.
>
> So, if it's a string, use the regexps (if they can be smart enough to look at
> beginning and end of the string, which they can--though I haven't been using
> the
> :post-blank property so presumably something is amiss), and if it isn't a
> string, recur down until you get to a string... Ah, but only if it's in
> org-element-recursive-objects.
You're missing an important part: the regexps cannot be smart enough for
quotes at the beginning or the end of the string. There, you must look
outside the string. Hence:
> ] 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.
But you can only do that from the element containing the string, not
from the string itself.
> So the issue with the current state is that it
> would wind up applying to too much? (it would hit code and verbatim elements,
> for example, and that would be wrong.)
No, you are not applying it too much (verbatim elements don't contain
plain-text objects) but your function hasn't got access to enough
information to be useful.
> So it remains to find the right place in the processing to put
> a function like the one you describe. I'm trying to get a proper
> understanding of the code structure to see what you mean. Looks like
> it should be something like a transcoder, only called on
> everything...
Transcoders are type specific, so that's not an option.
> wait, called on the top-level parsed tree object, recursively doing
> its thing before(?) the transcoders of the individual objects get to
> it.
That's called a parse tree filter. That should be a possibility
indeed. The function would be applied on the parse tree and would
replace strings within elements containing plain text (that is
paragraph, verse-block and table-row types). parse tree filters are
applied very early in the export process.
Another option would be to integrate it into
`org-element-normalize-contents', but I think the previous way is
better.
> The on-screen one would still use the plain-string computation, as you said,
> since the full parse isn't available.
Yes.
> It would also need to be tweaked not to act on verbatim/comment text,
> etc.
Yes. You may want to use `org-element-at-point' and `org-element-type'
to tell if you're somewhere smart quotes are allowed (in table,
table-row, paragraph, verse-block elements).
Regards,
--
Nicolas Goaziou