(Optionally) Supply SCTabCompletion suppliers with a list of arguments the player has already entered.

[ProjectHSI]

This is to allow the replication of number entering in commands such as tp, time set, etc.

[nomadjimbob]

Could you give me an example. I am not following the request

[ProjectHSI]

Could you give me an example. I am not following the request

in vanilla, if you enter a number in /time set, the tab completions will be the number
as well, in tp, entering a number as one of the arguments will show the number and then ~ for the remaining arguments for easy filling out

[nomadjimbob]

OK, for reference in this issue (and my own notes), while the callback would return say 'day', 'night', 'noon', the callback func should be able to see what the user has currently typed for this argument, allowing the return list to be customised. An example of the updated code (would no longer be a Supplier):

private List<String> tabCompletionCallback(String arg) {
    List<String> list = new ArrayList<>();

    try {
        Integer.parseInt(arg);
        // If arg is a number, return 'd', 's', 't'
        list.add("d");
        list.add("s");
        list.add("t");
    } catch (NumberFormatException e) {
        // If arg is not a number, return 'day', 'night', 'noon'
        list.add("day");
        list.add("night");
        list.add("noon");
    }

    return list;
}

Currently the TabCompletion code has a list of potential branches to follow and it needs to weed out which branches are still active and which are no longer. ie:

1. "create"
2. "delete" "{world}" "enabled|disabled"
3. "unload" "{world}"

It does this by iterating each branch, comparing the arg index vs the branch index and if not a match, removes the branch. When it comes to a placeholder, it calls the placeholder callback and receives a List and compares that. The above callback code would fail this match as it would never return the matching arg value (it returns d, s or t. Not the d, s or t) and the branch would be rejected.

This means that callbacks that return custom values based on the arg would always need to return the full value including the current arg string, for the branch to not be rejected.

This also does not take into account weird tab completions supported by built-in commands and not available to plugins. This includes some location based tab completions that build-in commands use, cannot be achieved using TabExecutor. I have a feeling the /time set is in the same boat here. As we return just a d, s or t, when the player tab completes the, it will remove the integer, replacing it with a character. Not a big issue, the callback would need to include the integer as part of the return list of strings.

[nomadjimbob]

We should probably change the Supplier to a Func that receives:

• The String placeholder (context on which placeholder we are processing)
• The String arg (context on which arg the player has entered)
• The List (all the args currently entered by the player)

While these would be present for TabCompletion callbacks, 1.0.0 would not fulfil at this time and would all be null. A 1.0.1 update could then fix this without the need for rewriting all the plugins to compile against a new method signature (it already exists).

The only potential problem I can see is with a command format of tp {player} {player}. The callback would not know which arg in the command we are currently talking about. Does the callback need to know about the entire arg list at all?