cursors are different when walking from a child node

[lunixbochs]

@CamilleTeruel @maxbrunsfeld At least currently, according to: http://tree-sitter.github.io/tree-sitter/using-parsers#other-tree-operations

You can initialize a cursor from any node:

TSTreeCursor ts_tree_cursor_new(TSNode);

Also according to: https://github.com/tree-sitter/py-tree-sitter/blob/master/tree_sitter/binding.c#L188-L194

static PyMethodDef node_methods[] = {
  {
    .ml_name = "walk",
    .ml_meth = (PyCFunction)node_walk,
    .ml_flags = METH_NOARGS,
    .ml_doc = "walk()\n--\n\n\
               Get a tree cursor for walking the tree starting at this node.",
  },

It seems like the intent is to be able to invoke walk from any node. The value of .ml_doc seems to suggest this, as it says:

Get a tree cursor for walking the tree starting at this node.

I also encountered similar behavior as that reported by @anandsork in: #19 (comment)

Please clarify as to whether one is supposed to be able to walk from any node.

Being able to use walk from any node seems quite useful and calls to it appear to succeed here with sensible output for the following sort of code:

node = some_node.child_by_field_name("value")
cursor = node.walk()
print(cursor)
print(cursor.node)

However, a subsequent:

print(cursor.current_field_name())

returns None here even when the original node was obtained via child_by_field_name.

Is this a bug?

Originally posted by @sogaiu in #19 (comment)

I think it is not a bug.

tree-sitter/tree-sitter#567 (comment) explains how things work currently:

Yeah, this is actually the expected behavior. The cursor only "walks" within the node that it started from, and it can't go outside of it. This is possible to change, but it would add some complexity. Maybe it's worth it though, because this has confused people before.
In order to access a field name for a node, it appears necessary to create the cursor not on the node itself but on an ancestor (so, parent will work). I ran a test now and found that I could get back a non-None appropriate value via current_field_name().

In the comment referenced above you mentioned the possibility of changing how things work. I don't suppose that's still a possibility?