Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose node->last in the public API #844

Closed
rinpatch opened this issue Oct 22, 2019 · 3 comments
Closed

Expose node->last in the public API #844

rinpatch opened this issue Oct 22, 2019 · 3 comments

Comments

@rinpatch
Copy link

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

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
Copy link
Contributor

@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
Copy link
Contributor

@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
Copy link
Contributor

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants