Commands registered through brigadier to the CommandDispatcher are wrapped with a VanillaCommandWrapper in the Bukkit command map (CraftServer#setVanillaCommands). Injecting description, permission, aliases etc to the VanillaCommandWrapper is trivial, but it is not possible to assign it to a plugin without VanillaCommandWrapper implementing PluginIdentifiableCommand. As VanillaCommandWrapper is final this is not possible.

I have managed to make a wrapper for VanillaCommandWrapper which implements PluginIdentifiableCommand and is injected into Bukkit's command map in place of the VanillaCommandWrapper. This does assign the command to my plugin, however Bukkit (CraftServer#syncCommands) creates a BukkitCommandWrapper around the custom VanillaCommandWrapper as it's no longer an instance of VanillaCommandWrapper. This means suggestions are not provided natively by brigadier, but they're the List<String> suggestions system that Bukkit uses. This causes lots of weird behaviour when using these commands, especially with suggestions in entity selectors.

Would it be possible to create an interface to denote vanilla commands instead of just testing for instances of VanillaCommandWrapper? My proposed solution looks like this:

package org.bukkit.command;

public interface VanillaCommand {
	public LiteralCommandNode getNode();
}

VanillaCommandWrapper then implements this interface as well as my custom wrapper.

CraftServer's syncCommands can now test for an instance of this interface instead of VanillaCommandWrapper and use the getNode method to access the LiteralNode instead of the vanillaCommand field.

This would allow my brigadier commands to forego BukkitCommandWrappers and as such tab complete completely natively while also being registered as belonging to my plugin in the help menu.

Thanks.