Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Burgess <andrew.burgess@embecosm.com>
To: Keith Seitz <keiths@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v3 00/19] New completer API
Date: Fri, 07 Aug 2015 22:57:00 -0000	[thread overview]
Message-ID: <20150807225655.GA2986@embecosm.com> (raw)
In-Reply-To: <20150806191404.32159.50755.stgit@valrhona.uglyboxes.com>

* Keith Seitz <keiths@redhat.com> [2015-08-06 12:14:29 -0700]:

> Currently completer functions are not required to implement completion-
> limiting.  These functions will compute all possible completions and then
> rely on complete_line to limit the result.
> 
> The main goal of this patchset is to require completer functions to
> implement proper completion-limiting using maybe_add_completion.  This
> actually cleans up the completer API significantly and fixes at least one
> serious bug (an assertion failure, gdb/17960).
> 
> The new API requires all completions to be added to the completion
> list using maybe_add_completion:

I think that the above text is out of date w.r.t. the example below,
in the above you talk about maybe_add_completion, but in the example
below you use the add_completion wrapper.  A small detail and
unimportant detail; unless I'm missing something, in which case
... I'm confused!

> void
> my_completer_function (struct completer_data *cdata,
>                        struct cmd_list_element *cmd,
>                        const char *text, const char *word)
> {
>     while (/* there are more completions to look for */)
>     {
>       char *match = xstrdup (a_completion_match);
> 
>       if (add_completion (cdata, match, text /* or NULL */,
>                           word /* or NULL */))
>           == ADD_COMPLETION_MAX_REACHED)
> 	return;
>     }
> }

This pattern of calling add_completion and comparing to
ADD_COMPLETION_MAX_REACHED is repeated throughout the patch set.

I wonder, looking at add_completion, do users _care_ about the reason?
Of all the possible return codes from add_completion, I think we can
classify them as either "stop trying to add completions please", or
"feel free to add more completions".

Could the add_completion interface be simplified to simply return a
bool, true if more completions can be added, false if not?

Just a thought.

Thanks,
Andrew


  parent reply	other threads:[~2015-08-07 22:57 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-07  2:37 Keith Seitz
2015-08-06 19:18 ` [PATCH v3 09/19] Implement completion limiting for interpreter_completer Keith Seitz
2015-08-23  4:03   ` Doug Evans
2015-08-06 19:20 ` [PATCH v3 12/19] Implement completion limiting for sim_command_completer Keith Seitz
2015-08-23  4:11   ` Doug Evans
2015-08-06 19:58 ` [PATCH v3 19/19] Remove the vector return result from the completion API Keith Seitz
2015-08-23 18:03   ` Doug Evans
2015-08-06 19:58 ` [PATCH v3 02/19] Remove completion_tracker_t from the public " Keith Seitz
2015-08-23  1:02   ` Doug Evans
2015-08-24 16:06     ` Doug Evans
2015-08-06 19:58 ` [PATCH v3 04/19] Implement completion limiting for add_filename_to_list Keith Seitz
2015-08-23  1:07   ` Doug Evans
2015-08-06 19:58 ` [PATCH v3 06/19] Implement completion limiting for condition_completer Keith Seitz
2015-08-23  3:53   ` Doug Evans
2015-08-06 19:58 ` [PATCH v3 18/19] Use the hashtable to accumulate completion results Keith Seitz
2015-08-23 17:53   ` Doug Evans
2015-08-06 20:03 ` [PATCH v3 01/19] Add struct completer_data to the completion API Keith Seitz
2015-08-23  0:29   ` Doug Evans
2015-08-06 21:06 ` [PATCH v3 05/19] Implement completion limiting for ada_make_symbol_completion_list Keith Seitz
2015-08-23  3:47   ` Doug Evans
2015-08-06 21:06 ` [PATCH v3 17/19] Make the completion API completely opaque Keith Seitz
2015-08-23 15:14   ` Doug Evans
2015-08-06 22:03 ` [PATCH v3 13/19] Implement completion limiting for complete_on_enum Keith Seitz
2015-08-23  4:19   ` Doug Evans
2015-08-06 22:03 ` [PATCH v3 08/19] Implement completion limiting for signal_completer Keith Seitz
2015-08-23  3:59   ` Doug Evans
2015-08-06 22:03 ` [PATCH v3 11/19] Implement completion limiting for reg_or_group_completer Keith Seitz
2015-08-23  4:09   ` Doug Evans
2015-08-06 22:03 ` [PATCH v3 07/19] Implement completion limiting for filename_completer Keith Seitz
2015-08-23  3:58   ` Doug Evans
2015-08-06 22:03 ` [PATCH v3 16/19] Implement completion limiting for tui_reggroup_completer Keith Seitz
2015-08-23  4:25   ` Doug Evans
2015-08-06 22:12 ` [PATCH v3 14/19] Implement completion limiting in add_struct_fields Keith Seitz
2015-08-23  4:23   ` Doug Evans
2015-08-06 22:12 ` [PATCH v3 10/19] Implement completion limiting for cmdpy_completer Keith Seitz
2015-08-23  4:07   ` Doug Evans
2015-08-06 22:36 ` [PATCH v3 03/19] Implement completion-limiting for complete_on_cmdlist Keith Seitz
2015-08-23  1:05   ` Doug Evans
2015-08-07  2:37 ` [PATCH v3 15/19] Implement completion limiting for scmcmd_add_completion Keith Seitz
2015-08-23  4:24   ` Doug Evans
2015-08-07 22:57 ` Andrew Burgess [this message]
2015-08-08  0:04   ` [PATCH v3 00/19] New completer API Keith Seitz
2015-08-08  6:44     ` Andrew Burgess
2015-08-08 16:25       ` Keith Seitz
2015-08-22 22:25         ` Doug Evans

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=20150807225655.GA2986@embecosm.com \
    --to=andrew.burgess@embecosm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=keiths@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