From: Jan Vrany <jan.vrany@fit.cvut.cz>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] MI: Add new command -complete
Date: Thu, 17 Jan 2019 21:01:00 -0000 [thread overview]
Message-ID: <4943920de5a6a09118288ec08cb328e945549f4a.camel@fit.cvut.cz> (raw)
In-Reply-To: <87imynm3ia.fsf@tromey.com>
On Thu, 2019-01-17 at 13:29 -0700, Tom Tromey wrote:
> > > > > > "Jan" == Jan Vrany <jan.vrany@fit.cvut.cz> writes:
>
> Jan> This commit adds a new '-complete' MI command which is implemented using
> Jan> CLI's 'complete'.
>
> I suspect it would be better to just write a new MI function and then
> mildly refactor complete_command so that the two commands can share most
> of their implementation.
>
> First, this would make it so we could add options to the MI command as
> needed. (Perhaps the current argument to the command ought to have a
> flag to avoid future parsing problems?
What do you mean by this? Can you give an example?
> I am not sure.)
>
> Second, it would mean that we could make changes to the CLI command
> without worrying about breaking MI compatibility.
As for changes to CLI command, I've got the impression from the code that
the format is rather strict (from use of printf_unfiltered(), for instance),
deliberately so to not break clients (Emacs is mentioned). Indeed, not really
an argument against splitting.
>
> What do you think of this?
I thought of that actually. Also, it'd make the MI interface more regular
w.r.t quoting of spaces and other special characters. But in the end I could
not find a way without duplicating enough code from the original function,
so hacked it that way.
Let me try harder :-)
>
> I looked and I see that some other MI commands are implemented directly
> by CLI commands. I am not sure but I suspect this might be a deprecated
> approach.
Yeah, there's quite a lot of them. If it is a deprecated approach,
I did not know.
>
> Jan> + bool is_mi_like = uiout->is_mi_like_p ();
>
> This could be removed by having a more explicit API.
I'm sorry, I'm not sure what do you mean here.
>
> Jan> + ui_out_emit_list completions_emitter (uiout, "completions");
> Jan> + if (result.number_matches != 0)
> Jan> + {
> Jan> + if (result.number_matches == 1)
> Jan> + {
> Jan> + if (is_mi_like)
> Jan> + uiout->field_fmt(NULL, "%s%s", arg_prefix.c_str (),
> Jan> + result.match_list[0]);
> Jan> + else
> Jan> + printf_unfiltered ("%s%s\n", arg_prefix.c_str (),
> Jan> + result.match_list[0]);
>
> Space before "(" in the field_fmt call. Unifying the cases would be
> preferable. Or another argument for separation.
>
Thanks!
Jan
next prev parent reply other threads:[~2019-01-17 21:01 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-03 22:30 Jan Vrany
2019-01-16 9:21 ` Jan Vrany
[not found] ` <87imynm3ia.fsf@tromey.com>
2019-01-17 21:01 ` Jan Vrany [this message]
2019-01-28 12:41 ` [PATCH v2 0/2] " Jan Vrany
2019-01-28 12:41 ` [PATCH v2 1/2] MI: extract command completion logic from complete_command() Jan Vrany
2019-02-27 20:41 ` Pedro Alves
[not found] ` <9ddd13d90ac5d77067f5690743149be8a2dcdd1a.camel@fit.cvut.cz>
2019-02-13 9:24 ` [PATCH v2 0/2] MI: Add new command -complete Jan Vrany
2019-02-19 7:33 ` Jan Vrany
2019-02-20 21:20 ` Tom Tromey
2019-02-21 16:05 ` Jan Vrany
2019-02-26 19:49 ` Tom Tromey
2019-02-27 10:41 ` Jan Vrany
2019-02-27 20:41 ` Pedro Alves
2019-02-28 10:18 ` Jan Vrany
2019-03-05 20:53 ` Pedro Alves
2019-03-06 15:09 ` Jan Vrany
2019-03-06 15:45 ` Eli Zaretskii
2019-03-06 16:37 ` Jan Vrany
2019-03-06 17:36 ` Eli Zaretskii
2019-03-04 14:52 ` [PATCH v3 2/2] " Jan Vrany
2019-03-04 17:35 ` Eli Zaretskii
2019-04-03 19:23 ` Pedro Alves
2019-03-04 14:52 ` [PATCH v3 0/2] " Jan Vrany
2019-03-04 14:52 ` [PATCH v3 1/2] MI: extract command completion logic from complete_command() Jan Vrany
2019-04-18 11:59 ` [PATCH v4 " Jan Vrany
2019-04-18 11:59 ` [PATCH v4 0/2] MI: Add new command -complete Jan Vrany
2019-04-18 14:59 ` [PATCH v5 2/2] " Jan Vrany
2019-04-18 15:23 ` Eli Zaretskii
2019-04-18 14:59 ` [PATCH v5 1/2] MI: extract command completion logic from complete_command() Jan Vrany
2019-04-18 14:59 ` [PATCH v5 0/2] MI: Add new command -complete Jan Vrany
2019-04-18 11:59 ` [PATCH v4 2/2] " Jan Vrany
2019-04-18 12:51 ` Eli Zaretskii
2019-04-18 14:15 ` Pedro Alves
2019-04-18 14:55 ` Jan Vrany
2019-04-18 16:14 ` Pedro Alves
2019-05-16 11:27 ` Jan Vrany
2019-05-16 17:31 ` Tom Tromey
2019-05-30 13:49 ` [PATCH v3 2/5] Use classes to represent MI Command instead of structures Jan Vrany
2019-06-18 19:38 ` Pedro Alves
2019-05-30 13:49 ` [PATCH v3 4/5] mi/python: Allow redefinition of python MI commands Jan Vrany
2019-06-18 20:03 ` Pedro Alves
2019-05-30 13:49 ` [PATCH v3 3/5] Create MI commands using python Jan Vrany
2019-06-18 19:43 ` Pedro Alves
2019-05-30 13:49 ` [PATCH v3 0/5] " Jan Vrany
2019-06-10 12:20 ` Jan Vrany
2019-05-30 13:49 ` [PATCH v3 1/5] Use std::map for MI commands in mi-cmds.c Jan Vrany
2019-05-30 14:19 ` [PATCH v3 5/5] mi/python: Add tests for python-defined MI commands Jan Vrany
2019-06-18 20:11 ` 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=4943920de5a6a09118288ec08cb328e945549f4a.camel@fit.cvut.cz \
--to=jan.vrany@fit.cvut.cz \
--cc=gdb-patches@sourceware.org \
--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