Re: Patch: implement new dynamic varobj spec

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> writes:

Nick> I don't know if others are already using these features but it
Nick> would seem sensible to me for frontends to _drive_ MI and not for
Nick> it to be the other way around.

Yeah; the first very round of code was really done in isolation but
since then, Vladimir has been trying things out in his GUI, and we've
had another user doing the same.

Nick> 1) The displayhint field output from -var-create as well/or
Nick> instead of from -var-list-children.  That would be useful for
Nick> determining whether an element should be expandable or not.  Types
Nick> map, list -- yes, type string -- no.  With normal variable objects
Nick> I just use num_children but this isn't sufficient for dynamic
Nick> ones.

I can add displayhint to the -var-create output quite easily.  It seems
like a good idea; I will implement it soon.

With a dynamic varobj you can tell if it has children by examining the
has_more attribute.

Nick> 2) If is_map is true, rather than:
[...]
Nick> I would prefer GDB to output:
Nick>   var1.0       = "map_element"
Nick>   var1.0.key   = key0
Nick>   var1.0.value = value0

Nick> That way the values could be displayed as a tree:

I considered this back at the start.  The problem with doing this is
that the key need not be a scalar.  It could be a struct or some other
complicated varobj with children.

Also, the current approach has a benefit because it is simple and
uniform: we can add more display hints without modifying the C code.

Tom