From: Pedro Alves <palves@redhat.com>
To: Tom Tromey <tom@tromey.com>
Cc: Philippe Waroquiers <philippe.waroquiers@skynet.be>,
gdb-patches@sourceware.org
Subject: Re: [RFA] Make first and last lines of 'command help documentation' consistent.
Date: Thu, 11 Jul 2019 15:49:00 -0000 [thread overview]
Message-ID: <5ec89c6f-57fe-248a-42ad-ca05f0686411@redhat.com> (raw)
In-Reply-To: <87tvbsbtqr.fsf@tromey.com>
On 7/11/19 2:12 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
>
> Pedro> On 7/11/19 1:22 PM, Tom Tromey wrote:
>>>>>>>> "Philippe" == Philippe Waroquiers <philippe.waroquiers@skynet.be> writes:
>>>
>>>>> I think this can't be an assertion, because user commands could hit it,
>>>>> and that seems too harsh; but could it be a unit test? That might be
>>>>> better than printing something magic, especially since IIUC the user can
>>>>> end up seeing this stuff.
>>>
> Philippe> Effectively, the user can end up seeing this, but only if the GDB test
> Philippe> was not run and/or was not fixed.
>>>
>>> Or if there is any command written in Python or Guile that has a newline
>>> at the end of its help text. These commands can be supplied any number
>>> of ways.
>
> Pedro> Could this be a warning at command-registration-time instead? That
> Pedro> way you would see if as soon as the command is registered. And it'd
> Pedro> be hard to introduce a regression with build-in commands since
> Pedro> everyone would start seeing a warning.
>
> Where I was coming from is that this is a pretty minor cosmetic issue;
> and while it makes sense for gdb to follow this rule, it isn't worth it
> for 3rd party commands. So, we should test gdb itself to avoid problems
> here, but ignore problems coming from elsewhere.
>
> I don't feel super strongly about it.
I agree that it's not desirable to include the extra markup in the
help output of 3rd party commands. That seems too harsh since it shows
up on every invocation and is certainly distracting for the user.
I kind of assumed that the markup also catches bad uses of the '.',
which affects proper integration with "apropos". If it's just for
the end line, then it's less of a deal.
My view was that that a warning is much less invasive than changing the
help text, since a warning would show (usually) at gdb startup when some
script is loaded, where users already get some text they need to
scroll over.
We could also make it a gdb_assert in the add_cmd functions,
and then make the python layer strip away any trailing whitespace.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2019-07-11 15:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-16 19:58 Philippe Waroquiers
2019-07-05 20:04 ` PING " Philippe Waroquiers
2019-07-10 17:02 ` Tom Tromey
2019-07-10 22:31 ` Philippe Waroquiers
2019-07-11 12:22 ` Tom Tromey
2019-07-11 12:53 ` Pedro Alves
2019-07-11 13:12 ` Tom Tromey
2019-07-11 15:49 ` Pedro Alves [this message]
2019-07-11 15:51 ` Pedro Alves
2019-07-11 15:58 ` Tom Tromey
2019-07-11 15:44 ` Pedro Alves
2019-07-11 13:49 ` Pedro Alves
2019-07-29 21:27 ` Philippe Waroquiers
2019-07-11 14:18 ` Pedro Alves
2019-07-11 15:39 ` Pedro Alves
2019-07-11 15:43 ` Pedro Alves
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=5ec89c6f-57fe-248a-42ad-ca05f0686411@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=philippe.waroquiers@skynet.be \
--cc=tom@tromey.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