Re: [PATCH 5/5] gdb/python: document GDB/MI commands in Python

[Eli Zaretskii <eliz@gnu.org>]

> From: Jan Vrany <jan.vrany@labware.com>
> Cc: Eli Zaretskii <eliz@gnu.org>
> Date: Tue, 18 Jan 2022 12:34:00 +0000
> 
> > You've added a second copy of the last two index entries, without any
> > qualifier.  This will cause makeinfo to generate index entries
> > "commands in python" and "commands is python<2>", without giving the
> > reader any clue what is the difference between these two instances.
> > 
> > It is much better to qualify each instance with some unique
> > qualifier.  Here, I'd use ", CLI" and ", GDB/MI" as the qualifiers.
> 
> I see. However I'm not sure what do you mean by "qualifiers". 
> In new version (which I'll submit  once I get review on
> other patches in this series) I changed index entries to 
> 
> @node CLI Commands In Python
> @subsubsection CLI Commands In Python
> 
> @cindex commands in python @subentry CLI
> @cindex python commands @subentry CLI

@subentry is a very new feature, so I'd prefer not to use it yet, as
that would force everyone who builds GDB to upgrade.

Something much simpler, like this, will do:

  @cindex commands in python, in CLI
  @cindex commands in python, in GDB/MI

> > > +You can implement new @sc{GDB/MI} (@pxref{GDB/MI}) commands in Python.
> > 
> > Same comment as for the NEWS entry.  With a possibly similar solution.
> 
> This phrasing with "new" (both here and in NEWS) was taken from entries
> for CLI commands. For NEWS, I have changed it as you suggested, it's better.
> 
> But for manual it makes less sense to me. Wording "It is now possible to add GDB/MI 
> commands implemented in Python." sounds to me as to suggest this is some
> new feature.

Yes, of course: you need to drop the "now" part in the manual.  It is
only appropriate in NEWS.  But the rest reads well here.  What
problems do you have with

  It is possible to add GDB/MI commands implemented in Python.