Don't show deprecated commands in help
Commit Message
Just like completion doesn't show deprecated commands, I think that help
should not list them, so that we don't incite users to use them.
gdb/ChangeLog:
* cli/cli-decode.c (help_cmd_list): Do not list commands that
are deprecated.
---
gdb/cli/cli-decode.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
Comments
On 04/04/2016 09:48 PM, Simon Marchi wrote:
> Just like completion doesn't show deprecated commands, I think that help
> should not list them, so that we don't incite users to use them.
>
> gdb/ChangeLog:
>
> * cli/cli-decode.c (help_cmd_list): Do not list commands that
> are deprecated.
Seems fine to me.
This made me wonder about whether a "help deprecated" command would
be useful, so a user could clearly/quickly see which commands are
now deprecated.
Also wonder whether we should do something to "apropos". I guess it
could/should go the same way as help, not sure. At least
"apropos deprecated" shows a few hits, but then again deprecated
commands was what I wanted to find.
Thanks,
Pedro Alves
On 16-04-19 07:30 AM, Pedro Alves wrote:
> On 04/04/2016 09:48 PM, Simon Marchi wrote:
>> Just like completion doesn't show deprecated commands, I think that help
>> should not list them, so that we don't incite users to use them.
>>
>> gdb/ChangeLog:
>>
>> * cli/cli-decode.c (help_cmd_list): Do not list commands that
>> are deprecated.
>
> Seems fine to me.
Thanks, I pushed it.
> This made me wonder about whether a "help deprecated" command would
> be useful, so a user could clearly/quickly see which commands are
> now deprecated.
Yes, that would be nice.
> Also wonder whether we should do something to "apropos". I guess it
> could/should go the same way as help, not sure. At least
> "apropos deprecated" shows a few hits, but then again deprecated
> commands was what I wanted to find.
It would make sense if apropos also didn't show deprecated commands.
Those sound like relatively easy tasks, which would be perfect for new
contributors. I read this some time ago, I was wondering if we should
have something like that in gdb:
https://medium.com/@kentcdodds/first-timers-only-78281ea47455#.txao561fn
Perhaps we could have a keyword for them in BZ... WDYT?
On 04/28/2016 07:19 PM, Simon Marchi wrote:
> Those sound like relatively easy tasks, which would be perfect for new
> contributors. I read this some time ago, I was wondering if we should
> have something like that in gdb:
>
> https://medium.com/@kentcdodds/first-timers-only-78281ea47455#.txao561fn
>
> Perhaps we could have a keyword for them in BZ... WDYT?
Sounds like a good idea.
We have the https://sourceware.org/gdb/wiki/ProjectIdeas page with some
ideas, though I don't think that has managed to attract much help in practice.
Got a suggestion for a keyword? I can add it.
Thanks,
Pedro Alves
@@ -1194,13 +1194,16 @@ help_cmd_list (struct cmd_list_element *list, enum command_class theclass,
for (c = list; c; c = c->next)
{
if (c->abbrev_flag == 0
+ && !c->cmd_deprecated
&& (theclass == all_commands
|| (theclass == all_classes && c->func == NULL)
|| (theclass == c->theclass && c->func != NULL)))
{
print_help_for_command (c, prefix, recurse, stream);
}
- else if (c->abbrev_flag == 0 && recurse
+ else if (c->abbrev_flag == 0
+ && recurse
+ && !c->cmd_deprecated
&& theclass == class_user && c->prefixlist != NULL)
/* User-defined commands may be subcommands. */
help_cmd_list (*c->prefixlist, theclass, c->prefixname,