From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103876 invoked by alias); 13 Jan 2019 16:49:40 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 103866 invoked by uid 89); 13 Jan 2019 16:49:39 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=D*ca, factor, hardly, personal X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 13 Jan 2019 16:49:37 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57736) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1giix6-0003Hr-89; Sun, 13 Jan 2019 11:49:36 -0500 Received: from [176.228.60.248] (port=3103 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1giix5-0006ql-SP; Sun, 13 Jan 2019 11:49:36 -0500 Date: Sun, 13 Jan 2019 16:49:00 -0000 Message-Id: <83o98kec4w.fsf@gnu.org> From: Eli Zaretskii To: Simon Marchi CC: gdb-patches@sourceware.org, palves@redhat.com In-reply-to: <5158b3d6feb794fb4db69dd3ee087286@polymtl.ca> (message from Simon Marchi on Sun, 13 Jan 2019 11:17:27 -0500) Subject: Re: [PATCH] Fix MI output for multi-location breakpoints References: <20190111001516.4761-1-simon.marchi@ericsson.com> <83lg3rhb6r.fsf@gnu.org> <7cf31d37-3931-bbac-07f2-c61f57be142c@ericsson.com> <83y37qgail.fsf@gnu.org> <10a03370-3f18-a716-eaca-5da6621d1660@ericsson.com> <83r2dgefpc.fsf@gnu.org> <5158b3d6feb794fb4db69dd3ee087286@polymtl.ca> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00316.txt.bz2 > Date: Sun, 13 Jan 2019 11:17:27 -0500 > From: Simon Marchi > Cc: Simon Marchi , 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.