Suggestions filtering for namespaced keys and locations when replacing suggestions works differently

[willkroboth]

CommandAPI version

9.0.4

Minecraft version

1.20.1

Are you shading the CommandAPI?

Yes

What I did

This issue was originally reported by Zoom on the CommandAPI discord. For additional context, see this thread.

Register these commands:

@Override
public void onEnable() {
    CommandAPI.onEnable();
    
    new CommandAPICommand("enchantment")
            .withArguments(new EnchantmentArgument("enchantment"))
            .executes(this::sendArg)
            .register();
    
    new CommandAPICommand("enchantmentSuggestions")
            .withArguments(
                    new EnchantmentArgument("enchantment")
                            .replaceSafeSuggestions(SafeSuggestions.suggest(
                                    Enchantment.WATER_WORKER
                            ))
            )
            .executes(this::sendArg)
            .register();
    
    new CommandAPICommand("location")
            .withArguments(new LocationArgument("location"))
            .executes(this::sendArg)
            .register();
    
    new CommandAPICommand("locationSuggestions")
            .withArguments(
                    new LocationArgument("location")
                            .replaceSafeSuggestions(SafeSuggestions.suggest(
                                    new Location(null, 0, 0, 0)
                            ))
            )
            .executes(this::sendArg)
            .register();
}

private void sendArg(CommandSender sender, CommandArguments arguments) {
    sender.sendMessage(arguments.get(0).toString());
}

What actually happened

When using the default Enchantment suggestions (/enchantment), typing aq suggests minecraft:aqua_affinity:

However, when the suggestions are replaced with just minecraft:aqua_affinity (/enchantmentsuggestions), typing aq does not suggest anything:

When using the default Location suggestions (/location), after typing the first value, the next values for the original suggestion are included:

(Trying to suggest 25.05 71.00 -8.43)

(71.00 and -8.43 are still being suggested even though 25.05 was not input)

However, when the suggestions are replaced, the suggestion is only kept if the first value was exactly what was suggested:

(Trying to suggest 0.0 0.0 0.0)

(Suggestions continue, 0.0 == 0.0)

(No suggestions are given, 10 != 0)

(No suggestions are given, "0" != "0.0")

Similar things happen for Location2D, and other arguments that input a namespaced key.

What should have happened

The vanilla behavior is excepted to happen.

Typing /enchantmentsuggestions aq is expected to suggest minecraft:aqua_affinity.

Typing /locationsuggestions 10 is expected to suggest 10 0.0 0.0.

Server logs and CommandAPI config

No response

Other

When ArgumentSuggestions suggests each String, it uses this shouldSuggest method to decide if each suggestion should be added:

https://github.com/JorelAli/CommandAPI/blob/c64e3d7a3afc9de9232b464f4006fedc15cea8d1/commandapi-core/src/main/java/dev/jorel/commandapi/arguments/ArgumentSuggestions.java#L283-L285

This is just a simple startsWith check, which makes sense most of the time. If the suggestions are ArgumentSuggestions.strings("alpha", "beta", "bear"), and the input is be, only the suggestions that start with the input should be suggested: ["beta", "bear"].

However, when Vanilla suggests world locations and resource locations, it uses special logic in net.minecraft.commands.SharedSuggestionProvider. This uses slightly more logic than just startsWith to produce the behavior seen when the CommandAPI does not replace the suggestions.

Instead of relying on ArgumentSuggestions#shouldSuggest, Arguments that use locations or namespaced keys could probably hook into SharedSuggestionProvider's logic.