Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: Philippe Waroquiers <philippe.waroquiers@skynet.be>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA 3/4] Update tests following changes to "help" and "apropos"
Date: Fri, 31 May 2019 20:34:00 -0000	[thread overview]
Message-ID: <871s0epdmy.fsf@tromey.com> (raw)
In-Reply-To: <20190531131903.21203-4-philippe.waroquiers@skynet.be> (Philippe	Waroquiers's message of "Fri, 31 May 2019 15:19:02 +0200")

>>>>> "Philippe" == Philippe Waroquiers <philippe.waroquiers@skynet.be> writes:

Philippe> Factorizes the testing of the help output, by having a single place
Philippe> that defines the common help trailer and/or prefix messages.

Philippe> -test_class_help "aliases" {"Aliases of other commands\.\[\r\n\]+"}
Philippe> +test_class_help "aliases" {"Aliases of other commands\.\[\r\n\]+"} {}

Wow, test_class_help is ugly!

Or more precisely, help_test_raw is pretty bad, following the "args"
convention that is confusing:

    proc help_test_raw { gdb_command expected_lines args } {
        set message $gdb_command
        if [llength $args]>0 then {
            set message [lindex $args 0]
        } 

It seems like it would be way better to just have an optional argument
there.

Anyway, could the new argument to test_class_help be optional?  Then
some of the changes, like the one above, would not be needed.  It could
also change from using args to using an optional final param:

    proc test_class_help {command_class expected_initial_lines {list_of_commands {}} {test_name {}}} {

Then at the end instead of eval it could just make a direct call:

-    eval [list help_test_raw "help ${command_class}" $l_entire_body] $args
+    help_test_raw "help ${command_class}" $l_entire_body $test_name

To make this work, the help_test_raw change would have to be made.

Philippe> +# Like test_class_help but specialised to test "help user-defined".
Philippe> +proc test_user_defined_class_help { list_of_commands args } {
Philippe> +    test_class_help "user-defined" {
Philippe> +	"User-defined commands\.[\r\n]+"
Philippe> +	"The commands in this class are those defined by the user\.[\r\n]+"
Philippe> +	"Use the \"define\" command to define a command\.[\r\n]+"
Philippe> +    } $list_of_commands [list $args]
Philippe> +    # Unclear why, but if [list $args] is rather $args, the above is tested
Philippe> +    # but gives no PASS message (but gives a FAIL message if it fails) ???

With those changes you could make an optional name parameter here,
and then remove the [list] and the comment.

Tom


  reply	other threads:[~2019-05-31 20:34 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-31 13:19 [RFA 0/4] Improve "show style", use style in " Philippe Waroquiers
2019-05-31 13:19 ` [RFA 1/4] Add highlight style, title style, fputs_highlighted. Improve 'show style' Philippe Waroquiers
2019-05-31 20:10   ` Tom Tromey
2019-06-01  8:47     ` Philippe Waroquiers
2019-06-03 14:21       ` Tom Tromey
2019-05-31 13:19 ` [RFA 3/4] Update tests following changes to "help" and "apropos" Philippe Waroquiers
2019-05-31 20:34   ` Tom Tromey [this message]
2019-05-31 13:19 ` [RFA 2/4] Improve usability and/or readibility of help and apropos output Philippe Waroquiers
2019-05-31 20:22   ` Tom Tromey
2019-05-31 13:19 ` [RFA 4/4] Document in NEWS and gdb.texinfo the "help", "apropos" and "show style" changes Philippe Waroquiers
2019-05-31 13:46   ` Eli Zaretskii
2019-05-31 20:35 ` [RFA 0/4] Improve "show style", use style in "help" and "apropos" Tom Tromey
2019-06-18 13:09 ` Pedro Alves
2019-06-18 16:04   ` Tom Tromey
2019-06-18 20:11   ` Philippe Waroquiers
2019-06-18 20:46     ` Tom Tromey
2019-06-18 20:53       ` Philippe Waroquiers
2019-06-18 20:58         ` Philippe Waroquiers
2019-06-18 22:40           ` Pedro Alves
2019-06-19  0:25             ` Philippe Waroquiers
2019-06-19 19:44               ` Tom Tromey
2019-06-19 19:26             ` Tom Tromey
2019-06-19 22:56               ` Pedro Alves
2019-06-20 14:21                 ` Tom Tromey

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=871s0epdmy.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=gdb-patches@sourceware.org \
    --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