Expose node->last in the public API

[rinpatch]

Reasoning: I am currently writing Erlang bindings to use libtidy as an html decoder. In Erlang, lists are internally represented as linked lists and the C API for them allows only appending to the head of the list without reconstructing it. It's much more efficient to perform the translation to Erlang terms by walking the tree last to first and appending to the children list.

It appears that the Node struct already has a pointer to the last sibling node

tidy-html5/src/lexer.h

Line 302 in 86b52dc

Node* last;

, it just needs to be exposed in the public API. I can try sending a patch if you agree the proposal makes sense

[geoffmcl]

@rinpatch thank you for the issue...

Know nothing of erlang, aside from what I have read since this issue appeared...

You suggest you want use libtidy as an html decode... to walk the Tidy node tree... last to first... and need an accessor to the node->last member... hmmm, ok...

I guess that access to the last could be achieved by an API addition, something like -

TidyNode TIDY_CALL    tidyGetLast( TidyNode tnod )
{
  Node* nimp = tidyNodeToImpl( tnod );
  return tidyImplToNode( nimp->last );
}

But I do not think that would be sufficient to walk last to first! Maybe that would also involve accessing node->prev?

I certainly do not think the last member of the node was intended in any way to do that... although have not tested, experimented...

One thing I did read, somewhere in my travels, NOTE WELL: One key thing to note in Erlang is that variables are immutable, which means that in order for the value of the variable to change, it needs to be destroyed and recreated again.... and assume that would apply to list, whether appending, or prepending, ie inserting before head...

So, sorry, at this moment the proposal does NOT make sense...

Maybe with more information... thanks...

[geoffmcl]

@rinpatch,

PS: Not sure it is relevant, but in experimenting with tidy nodes, wrote a tidy-tree app, to collect and show the Tidy nodes, after some html is loaded and parsed... they could say be collected in a vector<node *> list, and played back in reverse... just an idea... but maybe OT & NR...

[geoffmcl]

2020/10/11
@rinpatch, no further feedback in nearly a year, no clear proposal emerging, so closing this...

Please feel free to reopen with comments, or open a new issue... thanks...