On Friday 05 January 2007 00:48, Eli Zaretskii wrote:
> > From: Vladimir Prus <ghost@cs.msu.su>
> > Date: Thu, 04 Jan 2007 21:23:00 +0300
> > 
> > Here's the final patch.
> 
> Thanks.  I have a few comments and suggestions.
> 
> > -When returning the actual values of the objects, this facility allows
> > -for the individual selection of the display format used in the result
> > -creation.  It can be chosen among: binary, decimal, hexadecimal, octal
> > -and natural.  Natural refers to a default format automatically
> > -chosen based on the variable type (like decimal for an @code{int}, hex
> > -for pointers, etc.).
> 
> This fragment was removed, but the new text doesn't mention this
> feature at all.  Was the old text plain wrong (i.e. there's no such
> feature)?  If the feature does exist, I think it should be mentioned.

I did remove it because detailed explanation about display format are too
detailed for the introduction -- it's not a core functionality. The new doc mention
that display format can be changed, and I've just added more docs to
-var-set-format and -var-evaluate-expression so that essential parts of the
above paragraphs are not lost.

> 
> > +Variable object is MI interface to work with expressions.
> 
> Perhaps it's an interface to work with named expressions, because I
> believe you don't need anything to work with just expressions, do you?

Although you can use -data-evaluate-expression, using varobj is the recommended
way. I don't think "named expressions" is the key here -- if MI was an interface
in any object oriented language, you would not need varobj name at all. But since MI
is pipe interface, you need some opaque token instead of object reference in a 
programming language. So no fundamentally named expression are involved.
How about:

	Variable object is the recommended MI interface to work with expressions.

> >                     Child variable objects can children themself,
> > +util we reach leaf variable objects of built-in types. ^^^^^^^^
>    ^^^^
> Typos, and also something's wrong with this sentence in general.

Changed to:


	Child variable objects can themself have children,
	util we reach leaf variable objects of built-in types.

Revised patch attached -- hopefully better this time.

- Volodya