Command tab completion

[0ffz]

Somehow scan the entire command tree on startup to learn about the arguments being used. This is mainly useful for autocomplete.

We may need some files to provide descriptions for different languages, so it might be okay to force people to define tab completion information there, but this seems way more annoying for the end user.

[Derongan]

I'll take a crack at this. Fair warning- I think I will end up rewriting a large amount of the command processing if I get into this...

[Norazan]

Yeah, Offz and I talked about this probably requiring a rewrite of the command processor to a more standard OO pattern so go for it 👍

[0ffz]

Yeah you could try but I have a specific idea in mind for the big rewrite, I'll outline it here at least:

Basically in the DSL run things on an abstract Command class which lets you add subcommands, actions, etc... but has no idea of a sender. We can still access the sender within actions, but the idea is we can't run those actions with just the Command class.

Then we have two implementations of Command, ExecutableCommand and some sort of CommandStructureAnalyzer (dunno of a good name right now). We can create instances of the two, then apply the same init function in the DSL on both.

The structure analyzer gets instantiated, and has its own implementations for subcommands, arguments, etc.. which allow it to run through the entire structure and save them for later retrieval for tab completion.

The ExecutableCommand will function similarly to our current commands. It takes a sender and arguments, and walks through the entire tree once executed.

Some extra info on why I like evaluating from scratch when executing commands

We get a nice linear way of thinking about how the command runs. For instance, if a command fails, we stop its execution right there, or whatever arguments are within your scope will be required to pass. In general, I found that running through the command from scratch when we execute it makes things much simpler to think about in the backend.

Plus, I don't think it's possible to implement arguments the way we do right now since the thisClass reference in the getValue function for the argument delegates returns null when we're accessing it in a lambda. We NEED a unique action reference to know what arguments were sent. If you store those outside the action, you get concurrency issues where two players run the same command and are trying to access the same arguments, but have passed different ones to the command. It's easier to show the issue in code, but hopefully that gives you a bit of an idea.

[Derongan]

Seeing as you have a lot of thought into this, I'm going to take a step back.

[0ffz]

Closing to write an updated issue now that PaperMC is introducing a new Command API