Re: MI -break-info command issues

[Eli Zaretskii <eliz at gnu dot org>]

> From:  Vladimir Prus <ghost@cs.msu.su>
> Date:  Wed, 25 Jan 2006 14:11:47 +0300
> 
> >> I agree, this output has always been useless to me. I would be happy to
> >> see it go away.
> > 
> > I DON'T agree, and I think it would be a grave mistake to have this
> > output go away.  About the worst thing a program can do is have some
> > information and not reveal it.  Skipping unneeded information is easy;
> > restoring missing one is next to impossible.
> 
> Well, let's see what would be missing. The number of rows is trivial to
> restore. The number of columns -- well, given that the number of columns
> given in above output is 6, while the actual number of fields is something
> like 8, I'm not sure what "nr_cols" means at all.
> 
> Then, the column names. Any GUI can easily decide where to put each field
> and how to name the corresponding GUI item given a list of possible field
> names. I don't how it could be useful to know that gdb suggests to give
> label "Enb" to the "enabled" field. 
> 
> Then, what's "alignment"? Does gdb has a command to set preferred alignment
> for fields? If not, then alignment is just GDB's opinion about how GUI
> behave, which is not likely to be correct. The width field is completely
> redundant -- any GUI toolkit out there that can't auto-resize columns in a
> table?

All of your questions are explained in gdbint.texinfo, ui_out
functions are a piece of internals that _is_ documented, for a change.

> The extra information doesn't pertain to breakpoint itself, it's gdb opinion
> on formatting and is hardly usefull for machine interface. IMO, of course.

This output is produced by the UI-independent output functions.  So
judging its usefulness from the point of view of a GUI is taking a too
narrow view.  The advantage of ui_out routines is that whoever writes
the code defines the layout once, and then each UI gleans whatever it
needs from the results.  The programmer who wrote the code does not
need to bother which UI needs what information.  Yes, that means some
of the info will be redundant or useless for certain types of UI, but
that's by design, and I think the advantages of a single interface far
outweigh the small annoyances of having to read and discard unused
parts of the output.