(1.19.1) Commands are now case-sensitive

[luizsusin]

Expected behavior

The Paper/Spigot command dispatcher should force commands to run as lower case.

Observed/Actual behavior

The command dispatcher is dispatching commands in the very same way they're inputted.

Steps/models to reproduce

1. Run any command from the in-game chat in a case-sensitive way (something like /GaMeMode should do it);
2. See the error message.

Important: Sending commands through the console will work, regardless the case pattern.

Plugin and Datapack List

It's not really relevant ATM, but I'll provide if necessary.

Paper version

git-Paper-101

Other

First of all, yes, I'm aware that Mojang possibly considers commands to be case-sensitive (as stated in this JIRA Issue).
This might also be an upstream issue (Spigot, possibly).

However, this behaviour has, for years, not been this way on Paper/Spigot.
It also doesn't really makes sense to me why two commands would be registered in different case patterns (in the same plugin or not).

For instance, /gamemode and /Gamemode should run exactly the same way, as they state the same thing (it's the same command). This problem is even worse when using short commands, like /g and /G, which can happen easily if you happen to leave your caps lock on accidentally.

Mojang has never made their server to be used with external commands, which helps explain why they actually don't care about case sensitiveness.

Although this is not really a bug, forcing commands to be lower-case seems so much like the appropriate way for the command dispatcher to work.

[Machine-Maker]

Yeah, so this is def an upstream thing. They made a significant change to command processing. I, however, am always in favor of lining up with vanilla more. This might be too big a behavior change to just say "Works as Intended" for Paper, but my first thought is to just say this is "WAI". Others will definitely chime in.

[luizsusin]

Exactly, that's my point. I'm also always in favor of lining up with vanilla, however, this is, indeed, a really big behaviour change.
The community has been used for years to not really care about the case pattern, and the error message will first make pop the doubt if the command even exists in the server, and not the case pattern.
I'd really like to see at least an option to force or not the lower-case, but I think this might need some more discussion, which is why I brought it here.

[lynxplay]

I personally agree that this change is a rather large change to the current behaviour.
While I agree that, down the line, we would wanna move closer to vanilla and also follow the same case-sensitive matching, this should be something done on our own terms, with proper time for servers to adapt.

For now, I am marking this as a input wanted 👍

[codeHusky]

IMO, there is no point in allowing commands to set aliases for different capitalizations of the same command, even if that is the current vanilla behavior. There is not a situation where, for instance, a player would want /WHISPER or /wHISPER to be different from /whisper, nor is there a reason why a moderator would want a hastily-written caps-locked /MUTE PLAYER3 to fail simply because the server is now on 1.19.1+.

There's also the potential case of a dev having camel-cased their plugin's commands in their plugin.yml with the assumption that "it doesn't matter because its case insensitive" and now having to push an update to workaround this new change to ensure a consistent user experience.

Many networks are also employing multiple different versions of Minecraft currently, so this would lead to a confusing situation where staff/players may think X command doesn't exist anymore because the command processor says "invalid command." I'd like to see someone can come up with a valid reason that all plugin-based commands should be subjected to this (rather than it being some sort of opt-in behavior).

I don't think there's any user benefit to align with Vanilla in this particular situation. I get the interest in following the philosophy of the Paper project here, but at the end of the day Paper provides a lot of QOL stuff that shouldn't be overlooked in this situation.

[electronicboy]

This isn't really much of a "Do we wanna allow plugins to register "WhIsPeR and "WHISPER", that's 100% a stupid case for case sensitivity, this is pretty much purely a "do we wanna go through into the depths of hell to forcefully lowercase command dispatching, and modify all nodes registered into briadier, incurring the behavioural and maintenance debts which that incurs"; This does have some snags on both sides, on one side, people expect commands to "just work", but, it completely screws up on the client side given that the mismatch occurs and thus borks command completion; etc

I did hit a snag on this, which creates many issues as on the API side, the API still coerces stuff to lowercase on its side, and so you end up with stupid issues due to how broken upstream command situation is; e.g. command cooldown plugins generally expect to be able to lookup what command is being executed, and this creates issues when getCommand() returns a different result to executing (i.e. we successfully lookup a command due to coercion, but fail to execute due to brig dispatcher not doing that coercion)

I'm not 100% sure if we'll go into this, I see many merits for it but it's not free from issues, part of me semi wonders if mojang would take this up on their side given that there is 0 sane reason for case sensitivity here; We are likely going to need to touch some stuff on our side for things like the permission messages, but, I'm not sure how deep we should or will go into this