[PATCH] Fix MI output for multi-location breakpoints

[Eli Zaretskii]

> Date: Sun, 13 Jan 2019 11:17:27 -0500
> From: Simon Marchi <simon.marchi@polymtl.ca>
> Cc: Simon Marchi <simon.marchi@ericsson.com>, gdb-patches@sourceware.org,
>         palves@redhat.com
> 
> > Doing this for every single feature is indeed overkill.  But changes
> > in the version of MI are rare and backward-incompatible, so they are a
> > different story, IMO.
> 
> Just adding a new MI version is not a backward-incompatible change.  
> Adding MI3 does not change anything for you if you use MI2.  What is 
> backward-incompatible may be which version of MI is selected if you use 
> "--interpreter=mi" (without an explicit version).  Is it what we are 
> trying to document here, which version of the interpreter you end up 
> with if you use "--interpreter=mi"?  Or we are trying to document the 
> possible arguments to pass to "--interpreter"?

We are trying to do both.

> For the former, wouldn't it be clear to say that you end up with the 
> latest stable release of the MI interpreter (and cross-reference to the 
> table)?

It's a different issue.  Saying that you get the latest stable release
says nothing about the version of MI supported by older GDB versions.

> For the latter, a cross-reference to the table gives would point you to 
> the relevant info, without overloading this section as the number of MI 
> releases grow.

Well, a single sentence is hardly an overload.  And I already
explained why I don't think a cross-reference here will do: many
people read this section as a man page, when they want to read about
GDB invocation.

> >> > I'm okay with adding a detailed table elsewhere, but I don't think
> >> > it's a good idea to remove the above information from the description
> >> > of the -mi command-line switch.
> >> 
> >> Would a cross-reference to the table be good enough?
> > 
> > Not in this particular case, no.
> 
> Can you expand on why?

See above.  My personal experience with simple information which I
need to find by following links is that it's only justified when the
description is long enough.  This is not such a case.

> I really don't expect that many users to come to the manual often to
> know about MI versions.  Only a handful of people care about that
> (people who implement frontends), and they will surely dig much more
> in the manual (especially the GDB/MI section) to achieve what they
> want to do.

I don't think the number of people who need some information is a
factor we should consider in such cases.  We should instead try to see
this from the POV of a single reader who does need it.

> > Which is the third place?  I thought we have it only in two places.
> > The detailed table could come instead of that second place we have
> > now, not in addition to it.  But let's wait with that decision until
> > we actually see the proposed change for that table.
> 
> 1. In "@node Mode Options"
> 2. In "@node Interpreters"
> 3. In the hypothetical table of MI versions.

We don't need to consider hypothetical issues.  When it becomes real,
we can discuss whether it will replace what's currently in
"Interpreters" or be an addition.

> But anyhow, I can live with the "used by" formulation if you and Tom 
> think it's clear enough.  For MI2, however, we won't list all versions, 
> since there are too many.  Could we switch them both to ranges for 
> consistency?

Fine with me (but I don't think we must be consistent in these
matters).

Thanks.