Just a note that the command you implemented seems to have similar functionality to the FlagsArgument proposed by #483. Development on that is currently in progress on the dev/command-build-rewrite branch 22c2ffa.

Also, dev/argument-exceptions #476 currently provides the API for developers to manually suppress the exceptions thrown when the CommandAPI parses the ListArgument.

This latest iteration doesn't work. I tested this command:

new CommandAPICommand("test")
    .withArguments(new ListArgumentBuilder<String>("list")
        .skipListValidation(true)
        .withList("test")
         .withStringMapper()
        .buildGreedy()
    )
     .executesPlayer(info -> {
        List<String> list = (List<String>) info.args().get("list");
        info.sender().sendMessage(Component.text().content(list.toString()).build());
    })
    .register();

I then executed this command:

/test hello test police

The output I got was [test], the expected result would be [hello, test, police] if the validation is skipped.

This latest iteration doesn't work. I tested this command:

new CommandAPICommand("test")
    .withArguments(new ListArgumentBuilder<String>("list")
        .skipListValidation(true)
        .withList("test")
         .withStringMapper()
        .buildGreedy()
    )
     .executesPlayer(info -> {
        List<String> list = (List<String>) info.args().get("list");
        info.sender().sendMessage(Component.text().content(list.toString()).build());
    })
    .register();

I then executed this command:

/test hello test police

The output I got was [test], the expected result would be [hello, test, police] if the validation is skipped.

Yeah it's not the most intuitive since the list basically is only good for suggestions.
Afterwards you have to use the rawArgMap and it returns everything in one string.

            .executes(CommandExecutor { sender, args -> processCmd(sender, args) })
           # ...
            .withOptionalArguments(
                ListArgumentBuilder<String>("values")
                    .skipListValidation(true)
                    .withList { info -> buildTabSuggestions(info) }
                    .withStringMapper()
                    .buildGreedy()

           val values = args.rawArgsMap["values"]
          val args = splitStringWithQuotes(values) # split into array and treat quotes as one element

Here's how I used it https://github.com/ArcanePlugins/LevelledMobs/blob/4.0.0-dev/levelledmobs-plugin/src/main/kotlin/io/github/arcaneplugins/levelledmobs/commands/subcommands/SummonSubcommand.kt#L56

Nope, that's not how it's going to work when merged; the List returned has to contain every relevant value. As I said, it would be best to have a separate parsing method when list validation is skipped.
Also, make sure to also update the ListTextArgument constructor so this also can work with this parameter.

I'll probably just cancel this PR and wait for FlagsArgument proposed by #483 since it likely works better and is more intuitive.

I'll probably just cancel this PR and wait for FlagsArgument proposed by #483 since it likely works better and is more intuitive.

I mean, do what you want to do, but again, this, despite being a really niche feature, can be useful. It just needs a bit more attention since there are expectations when using the list.

Yeah it's not the most intuitive since the list basically is only good for suggestions.

Also, not true. The list, if validations are not skipped, provides the player or any other command executor with a list of options. The items in the suggestion list are there to tell the user the valid options.
The command sender can then choose which of these items should be used (compare the GIF in the ListArgument's documentation page, there the materials are suggested iirc).
The list that you then can get in the executor contains the chosen values. If not all values are selected, the list that provides suggestions and the list returned by the argument can be very different in size.

@stumper66
Are you still working on this? If not, it might be better to close this PR since I don't think we want PRs sitting here that are not active anymore.

Cancelling the PR