foldPositions traverses in reverse document order

[Robin Green]

At least, given this:

foldPositions(top(htmlToFillIn)\\*(p => hasLocalNameX("input")(p) || hasLocalNameX("textarea")(p))) {

    ...

}

the traversal is always in reverse document order, for me. Is this intentional?

[Chris Twiner]

Hiya,

yes its intentional, as per (at least some of the scaladoc for the
foldPosition functions):


The progress through the document is in reverse document order. This
ensures that transformations can always be safely composed, e.g. a
delete of a path won't stop changes below it. This, however, implies
the developer must also handle any accumulation in "reverse".


I realise its a little jarring, but the reason behind it is
composition. I couldn't find a satisfactory way to handle position
removal without reversing and adding a large number of unpleasant edge
cases.

Its something I may revisit though, after getting out the 0.5 M1
perhaps (should happen soon, I need to add some docs for the new
enumeratees and async parsing first).