This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH v2 19/24] Introduce complete_command
- From: Pedro Alves <palves at redhat dot com>
- To: Tom Tromey <tom at tromey dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 4 Jun 2019 23:10:04 +0100
- Subject: Re: [PATCH v2 19/24] Introduce complete_command
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
On 6/3/19 8:28 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <email@example.com> writes:
> Pedro> This adds a completion helper routine that makes it possible for a
> Pedro> command that takes another command as argument, such as "frame apply
> Pedro> all COMMAND" as "thread apply all COMMAND", to complete on COMMAND,
> Pedro> and have the completion machinery recurse and complete COMMAND as if
> Pedro> you tried to complete "(gdb) COMMAND". I.e., we'll be able to
> Pedro> complete like this, for example:
> Pedro> * completer.c (complete_command): New.
> I think that the function should have a different name. Traditionally,
> *_command is the name of the command "*" in gdb, and there's already a
> function called complete_command. Overloading makes this not matter too
> much, but I also think it's best to reserve overloading for functions
> that are semantically similar.
Hmmm. Somehow I forgot the "complete" command. Bizarre, since the
approach here is actually stolen from the same trick that I had
applied to make the "complete" command complete command arguments
correctly a couple years ago. Eh.
The name I had chosen as following the complete_xxx pattern in the
completer.h functions -- complete_expression, complete_symbol,
complete_source_filenames, complete_files_symbols, etc.
Not sure what to call this. It ultimately call complete_line, and it's
used to complete nested commands so, maybe