Re: Patch: implement new dynamic varobj spec

[nickrob@snap.net.nz (Nick Roberts)]

 > > the additional children appear.  With a string there are never any
 > > children so you would not want an expandable node.  AFAICS the only way
 > > the front end can discriminate is through the displayhint field.
 > 
 > Right, so for string you'll have numchildren=0, has_more=0, and no need to
 > make anything expandable. For vector that is initially empty, you'll have
 > the same, so it won't be expandable, but if things are pushed, -var-update
 > will report has_more=1. You can detect that, and make the item expandable
 > at this point.

OK.  In that case I misunderstood the meaning of the has_more field.  I had
assumed it was just non-zero when -var-set-update-range was restricted.

The documentation states that -var-update returns the list of variable objects
whose values have changed.  More precisely:

  Here, "changed" means that the result of `-var-evaluate-expression' before
  and after the `-var-update' is different.

That appears to no longer be true and its definition needs to be generalised
for dynamic variable objects.  Actually I wonder if it might be a good idea to
split the node on variable objects and describe normal (static?) variable
objects and dynamic ones separately.  It has become very long and that way the
user won't be overwhelmed by too much information at first reading.

-- 
Nick                                           http://www.inet.net.nz/~nickrob