Re: [O] Smart Quotes Exporting

[Nicolas Goaziou]

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