Allow for custom autocomplete suggestions

[StayBlue]

What part of Adonis is this related to?

Command

What are you suggesting?

The discussion in #1350 reminded me of this. A while back, I tried adding custom autocomplete suggestions to a command I was trying to create, only to find out that the autocomplete username suggestions are hard-baked in. It would be nice if the autocomplete suggestions could be customized somehow.

[ccuser44]

What part of Adonis is this related to?

Command

What are you suggesting?

The discussion in #1350 reminded me of this. A while back, I tried adding custom autocomplete suggestions to a command I was trying to create, only to find out that the autocomplete username suggestions are hard-baked in. It would be nice if the autocomplete suggestions could be customized somehow.

Here is how I would do it:

• If arg name is "player" it autocompletes player names
• If arg name is "brickcolour" it autocompletes brickcolour names
• If arg has an comma seperated list of options like "argname (Options: test, test5, green, blue)" then it suggests from the options list
• If arg has "argname (Refers: Variables.SOMETHING)" it pulls the autocomplete from the keys of a dictionary

---

Was also thinking of other related features to args

• If arg has "argname (Default: THEDEFAULTVALUE)" then (on the server side) if no arg was provided it would be autofilled to the default value
• If arg has "argname (Max: 50) (Min: 20)" and a number then it would be clamped to the max and min specifiers (on the server too)
• There should probably be be a way to specify either that an arg is optional or required (only one should be specified NOT BOTH AT THE SAME TIME!) Possibly to specify it as required for backwards compatibility reasons. Oh and it would only be classified as required if there is no default specifier
• An arg can have multiple subspecifiers for example "argname (Min: 50) (Default: 70) (Max: 100)"

[SuperCater]

What if we converted arguments to be a table like so (we would support the old style for backwards compatability)

Arguments = {
{
type = "user",
default = "me",
autocompleteValues = service.Players:GetPlayers()
}}

[ccuser44]

What if we converted arguments to be a table like so (we would support the old style for backwards compatability)

Arguments = {
{
type = "user",
default = "me",
autocompleteValues = service.Players:GetPlayers()
}}

That would add a lot of bloat + it would cause high memorylag and just be super clumsy to use

The new style is already used and wouldn't break anythinh

[Dimenpsyonal]

Interesting

[TheLegendarySpark]

After I realized the potential issue of memory lag, you could do something similar to autocomplete but it does not hog the client's memory. If the client's command input is focused on an argument that requires a player target, they could right click on any player then the command input autofills the target's name.