From: Nick Roberts <nickrob@snap.net.nz>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: MI: type prefixes for values
Date: Tue, 21 Mar 2006 10:22:00 -0000 [thread overview]
Message-ID: <17435.29362.640036.97752@kahikatea.snap.net.nz> (raw)
In-Reply-To: <20060318013113.GA28374@nevyn.them.org>
> > Unlike Volodya's change, its not a change in the MI protocol but one of
> > presentation, so I would put it mi2 -i.e the curent default mi (recall that
> > -i=mi sets mi_version to 2).
I thought that Volodya was also adding a type field.
> I don't think it makes a difference - it could confuse consumers of MI2
> anyway - that's all I'm worried about.
I think it means its generally less likely to make a difference. In Emacs, I
just take the value of the field amd insert it in the appropriate window at
the appropriate place. Thats why the type currently gets duplicated in the
locals window. Removing the type prefix just removes that duplication, I
don't have to make any changes to the lisp code in Emacs. Adding a field,
however, might break my parser if I'm not expecting it.
However, perhaps you're thinking specifically of Eclipse.
...
> > Since there are likely to be many more changes to MI, I suggest that when
> > we start making changes for mi3 only, the default remains at mi2. This
> > will allow a period of development for mi3 during which changes can be
> > made more freely. It could then be made the default level after it has
> > stabilised.
>
> Yes, this is already how we document -i=mi to work. It's the last
> finalized version of the protocol.
But there have been many changes to mi2, notably adding the fullname field
in several places, since it became the default level. I'm just suggesting
that we don't have mi4, mi5, mi6 etc because it gets too complicated.
--
Nick http://www.inet.net.nz/~nickrob
next prev parent reply other threads:[~2006-03-18 2:40 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <dt43qh$sns$1@sea.gmane.org>
2006-03-13 2:44 ` Nick Roberts
2006-03-17 19:32 ` Vladimir Prus
2006-03-17 19:41 ` Daniel Jacobowitz
2006-03-21 14:58 ` Vladimir Prus
2006-03-24 4:30 ` Daniel Jacobowitz
2006-03-24 9:46 ` Vladimir Prus
2006-03-24 21:02 ` Daniel Jacobowitz
2006-04-06 8:42 ` Vladimir Prus
2006-04-28 6:32 ` Vladimir Prus
2006-05-05 19:25 ` Daniel Jacobowitz
2006-05-06 9:59 ` Nick Roberts
2006-05-15 16:57 ` Daniel Jacobowitz
2006-05-16 6:10 ` Nick Roberts
2007-02-03 5:31 ` MI: type prefixes for values [PATCH] Nick Roberts
2007-02-04 14:16 ` Daniel Jacobowitz
2007-02-04 21:46 ` Nick Roberts
2006-03-17 22:25 ` MI: type prefixes for values Daniel Jacobowitz
2006-03-18 18:39 ` Nick Roberts
2006-03-20 6:50 ` Daniel Jacobowitz
2006-03-21 10:22 ` Nick Roberts [this message]
2006-03-24 4:25 ` Daniel Jacobowitz
2006-03-24 5:26 ` Nick Roberts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=17435.29362.640036.97752@kahikatea.snap.net.nz \
--to=nickrob@snap.net.nz \
--cc=drow@false.org \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox