Hello, Mark Shoulson <m...@kli.org> 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
