From: Tom Tromey <tromey@redhat.com>
To: Sergio Durigan Junior <sergiodj@redhat.com>
Cc: GDB Patches <gdb-patches@sourceware.org>,
Phil Muldoon <pmuldoon@redhat.com>
Subject: Re: [PATCH] PR python/16699: GDB Python command completion with overriden complete vs. completer class
Date: Tue, 20 May 2014 19:12:00 -0000 [thread overview]
Message-ID: <87y4xwqn71.fsf@fleche.redhat.com> (raw)
In-Reply-To: <m361ln20e8.fsf@redhat.com> (Sergio Durigan Junior's message of "Fri, 02 May 2014 21:04:15 -0300")
>>>>> "Sergio" == Sergio Durigan Junior <sergiodj@redhat.com> writes:
Sergio> Unfortunately I couldn't come up with a good way to do that. readline
Sergio> messes with the text/word being parsed while it is parsing them, so it
Sergio> is hard to restart the parsing because we may not have the full context
Sergio> in all situations. Or at least that's what I found.
I looked through the readline docs here.
Ok, I see now, the completion API is irredeemably wacky.
Sergio> But I fixed my patch according to your comment above, and I think now it
Sergio> is right. What I did is simple: instead of providing dummy arguments to
Sergio> the completer, I am now passing the real arguments. As far as I have
Sergio> tested, it works.
Cute.
Sergio> What do you think? Is it too hacky?
Someday we will invent a hackiness metric to let us know for sure.
"M(h) is greater than 0.98! Patch rejected by the robot."
Seriously, at first I thought this was probably a bad idea.
And it is a little weird, since first it word-breaks some random way,
then redoes the breaking later.
Is there a way to call the Python function just once and store the
results in the non-enum-return case? Since otherwise it seems that
every completion request requires two calls to a
possibly-expensive-though-we-hope-not completer.
Anyway I'm ok-enough with it I suppose.
Sergio> +void
Sergio> +set_cmd_completer_handle_brkchars (struct cmd_list_element *cmd,
Sergio> + void (*completer_handle_brkchars) (struct cmd_list_element *self,
Sergio> + const char *text,
Sergio> + const char *word))
Sergio> +{
Sergio> + cmd->completer_handle_brkchars = completer_handle_brkchars; /* Ok. */
I think the "Ok" comment usually is there as a note to the ARI.
However, does ARI actually check this line?
If not -> no comment needed.
Sergio> +/* Set the completer_handle_brkchars callback. */
Sergio> +
Sergio> +extern void set_cmd_completer_handle_brkchars (struct cmd_list_element *,
Sergio> + void (*f)
Sergio> + (struct cmd_list_element *,
Sergio> + const char *,
Sergio> + const char *));
I think the "f" argument should have type "completer_ftype *" rather
than being spelled out.
Sergio> +static void
Sergio> +cmdpy_completer_handle_brkchars (struct cmd_list_element *command,
Sergio> + const char *text, const char *word)
Sergio> +{
Sergio> + cmdpy_object *obj = (cmdpy_object *) get_cmd_context (command);
Sergio> + PyObject *textobj, *wordobj, *resultobj = NULL;
Sergio> + /* const char dummy_text[] = "dummytext";
Sergio> + const char dummy_word[] = "dummyword"; */
No need for the commented-out bits.
Sergio> +# This one should always pass.
Sergio> +send_gdb "completefileinit ${testdir_complete}\t"
Sergio> +gdb_test_multiple "" "completefileinit completion" {
Sergio> + -re "^completefileinit ${testdir_regex}$" {
Sergio> + pass "completefileinit completion"
Sergio> + }
FWIW I generally find it simpler to test the "complete" command rather
than the send_gdb dance.
Either way is ok though.
Tom
next prev parent reply other threads:[~2014-05-20 19:12 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-12 22:49 Sergio Durigan Junior
2014-03-22 2:54 ` Sergio Durigan Junior
2014-04-04 20:41 ` Sergio Durigan Junior
2014-04-10 16:27 ` Tom Tromey
2014-05-03 0:04 ` Sergio Durigan Junior
2014-05-20 19:12 ` Tom Tromey [this message]
2014-05-21 2:09 ` Sergio Durigan Junior
2014-05-21 7:48 ` Doug Evans
2014-07-01 0:59 ` Sergio Durigan Junior
2014-07-08 15:32 ` Jan Kratochvil
2014-07-08 18:17 ` Jan Kratochvil
2014-07-08 20:30 ` Sergio Durigan Junior
2014-08-19 23:02 ` Sergio Durigan Junior
2014-09-02 16:31 ` Sergio Durigan Junior
2014-09-03 4:03 ` Doug Evans
2014-09-03 20:36 ` Sergio Durigan Junior
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=87y4xwqn71.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=pmuldoon@redhat.com \
--cc=sergiodj@redhat.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