Implement Sponge help command

[zml2008]

Sponge commands have metadata available that vanilla commands do not. To accommodate this, we should create our own help command that presents the metadata about every registered command.

Additionally, this help command should list:

• all registered permissions (upcoming permissions registry, commands api setPermission method
• default permissions? (maybe this should be handled by a permissions plugin)
• commands by plugin (so a page for each plugin listing its commands)

Commands that cannot be accessed by a user should be hidden if possible.
The output of this command should be paginated (because some of these things could get pretty long) --- see #547

[boformer]

/help

Displays list of root commands + shortDescription the source is permitted to use.

/help [subcommand]

Displays command info:

• help text
• usage string
• aliases
• subcommands (like root command list)

There should also be a way for plugins to display the command info page (e.g. when a Dispatcher was called without arguments).

[ST-DDT]

There should also be a way for plugins to display the command info page (e.g. when a Dispatcher was called without arguments).

If i get your idea right we have basically 3 choices how to achieve this:

1. We recreate to get the entire command line so we could virtually call /help <entire command>
2. We submit a reference of the parent command callable/dispatcher to the call command and could then forward to parent.showHelp(<current command/this>, <current params>)
3. A new interface CommandHelpFormatter that can be obtained from the GameRegistry or something similar

public interface CommandHelpFormatter {

    void display(CommandSource source, CommandCallable command);

}

Which returns the details available in the CommandCallable.
(This can be achieved with a static method in the HelpCommand as well HelpCommand.showHelp(CommandSource source, CommandCallable command) although i don't like the limitations of the static nature.)

Comment on 1) Is quite simple, but you would probably parse the command line twice and you have issues if the command hierachy does not implement CommandDispatcher.
Comment on 2) The current command API uses a totally different approach (which is simple to use but very inflexible).
Comment on 3) Probably the best (if we don't rework the command API), because it always has the same layout, always works, the command can decide which CommandCallable's help should be shown.

But there are two more general issues with the getHelp() method.

1. It does not support pagination
2. It requires CommandDispatchers in places where you just want to show some more details about a single given parameter. (to reduce the overhead of showing all information)

Example:
Usage: /bigItemCommand <Item> <amount> <definition>
BigItemCommand cannot be implemented as CommandDispatcher.
User writes: /help bigItemCommand definition
Plugin answers:

Spawns Items:
Usage: /bigItemCommand <Item> <amount> <definition>
Description:
Comand to spawn Items ... long text ... blub....
Parameters:
Item: The Item Id to spawn/give, can be one of LONG List....
Notice: BLACK_WOOL would be WOOL with some data definitions....
Amount: The size of the stack. Must be between 1 and 64. The amount is automatically trimmed to the max supported stack size of this item.
Definition: JSON structure to set some variables/ data values to the given item.
Supported definition keys: Color, FireworkEffect.......
Notice: The keys are case sensitive.
Permissions:
item.type.* => Allows all ids
item.type.wood = > Allows only wood
[Some more permissions....]
----------------
CoolItem Command by IAmTheAuthor

The only part the user was interested in was the part with the definition:

Definition: JSON structure to set some variables/ data values to the given item.
Supported definition keys: Color, FireworkEffect.......
Notice: The keys are case sensitive.

Maybe a interface like

public interface HelpingCommandCallable extends CommandCallable {
    public showHelp(CommandSource source, String arguments, List<String> parents);
}

would help allowing a more detailed/flexible help where necessary.

[boformer]

@ST-DDT I would prefer option 3, with a CommandHelpService. To make it even better:

Option 4: The plugin can append a "DisplayCommandHelp" object to the CommandResult.
The CommandHelpService listens for the CommandEvent (Order.POST) and checks if a command requested a help display.

• I think a help command with pages for every argument goes too far.
• The help command should not display permissions (right now there is no way to get them).
• A command help page should look like this:

Usage: /{alias} {cmd.getUsage}
{cmd.getHelp.........................
.....................................
....................................}

The help text should have ~3 lines. Plugin devs can embed a link to a detailed description.

If the command is a dispatcher:

Subcommands:
/{alias} - {subcmd.getShortDescription}
/{alias} - {subcmd.getShortDescription}
/{alias} - {subcmd.getShortDescription}

If user has permission sponge.help.aliaslist:

Aliases: /{alias1}, /{alias2}, /{alias3}
...

[JBYoshi]

This is implemented already. #744

[Zidane]

Closing this as it needs to be re-made on SpongeCommon if still necessary.