Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: Pedro Alves <palves@redhat.com>
Cc: Tom Tromey <tom@tromey.com>,
	 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 13:12:00 -0000	[thread overview]
Message-ID: <87tvbsbtqr.fsf@tromey.com> (raw)
In-Reply-To: <f1b97017-9e7d-a8a2-82a5-35cf230e4bf9@redhat.com> (Pedro Alves's	message of "Thu, 11 Jul 2019 13:53:31 +0100")

>>>>> "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.

Tom


  reply	other threads:[~2019-07-11 13:12 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 [this message]
2019-07-11 15:49           ` Pedro Alves
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=87tvbsbtqr.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=philippe.waroquiers@skynet.be \
    /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