MoritzR200
Comments
I can confirm that the issue is present all the way up to (and including) the latest snapshot (24w13a).
Clarification of the issue
This issue makes it impossible to use brigadiers tab-completion and the clients highlighting for any arguments that are either:
international (like city names on a non-English survival server) without explaining to users that they have to wrap the word in quotes (for no apparent reason) and then handling the user entering a space in that quoted string when you actually only wanted to accept a single word (but you had to use QUOTABLE_PHRASE instead of SINGLE_WORD because that does not support international characters (again for no apparent reason))
or contain any character not conforming to the RegEx [A-Za-z0-9\._-+] for some other reason
Resolving this issue would also make brigadier more consistent, since literals do not have to be quoted if they include international characters.
Current workarounds
The main workaround employed by all the sources I checked is (next to using quoted strings for everything, eliminating the point of SINGLE_WORD entirely and leading to frustrating user experience (since no one guesses that you have to wrap your string in quotes if you want to use non [A-Za-z0-9\._-+] characters)) to use GREEDY_PHRASE and do the tab-completion on your own (giving up all syntax highlighting in the process).
The community cares (more than 4 people)
This issue has been reported multiple times (in slightly different variations)
https://github.com/Mojang/brigadier/issues/44 (Nov 8, 2018) (fundamentally had this problem though it was avoided)
https://github.com/Mojang/brigadier/issues/103 (Nov 7, 2021)
https://github.com/Mojang/brigadier/issues/146 (Jan 28, 2024) (duplicate of https://github.com/Mojang/brigadier/issues/103 )
Multiple fixing (or alternative providing) pull requests have been opened (and not jet merged):
https://github.com/Mojang/brigadier/pull/56 (Jun 26, 2019) (also does a lot of other stuff)
https://github.com/Mojang/brigadier/pull/131 (May 6, 2023) (solves this issue only (additionally the serialization methods of the net.minecraft.commands.synchronization.brigadier.StringArgumentSerializer class have to be adjusted slightly)) (also has 16 upvotes which should effectively increase this issues votes accordingly) (my recommendation)
https://github.com/Mojang/brigadier/pull/56 (Jan 5, 2024) (server only)
Also this kind of issue tends to only be reported by a few developers even though it affects and is noticed by way more people.
Why report it here?
@tryashtar mentioned that this issue should be reported to the brigadier GitHub page, but since it was not yet officially commented there (nor any other non-Mojang issue or PR for the past 5-6 years as far as I could tell (even if they are very small bug fixes)) and it has not been commented on the Feedback page either (https://feedback.minecraft.net/hc/en-us/community/posts/8241302508941-Custom-Arguments-for-Plugin-Development), I thought I should raise awareness of it again.
Final words
I hope this issue will be resolved making highlighted international commands possible1 and brigadier more consistent (especially since it should be an fairly easy fix, considering that the brigadier side of things has already been implemented (https://github.com/Mojang/brigadier/pull/131) and only one additional class has to be changed (as far as I can tell)).
1other than the mentioned workarounds
Thanks for your time and effort! 🙂
I am sorry for not following proper procedure then. Also I failed to check for closed tickets involving this issue, which was, because I cloud not image this (in my humble opinion) obvious mismatch of designers intent and the lighting behaviour to be intentional.
I agree that the door part of this duplicates MC-82773 WAI and the Trapdors and Doors are included in MC-139435 WAI and therefore this ticket should be closed as a duplicate,
but why is this behaviour intentional? I mean the (Trap-)Doors are intentionally opaque! There are multiple other transparent (Trap-)Doors, so it clearly was a design decision to include opaque options in the game. That however means, that these (since they are opaque) should also block light. That seems only natural.
As for this being a duplicate of Duplicate of MC-139435, WAI.
It technically is, but I would still like this to be re accessed, since I do not understand, why a closed door (like in the screenshot) should not allow me to darken my room. I mean do I seriously have to use a piston door, just so that my dark room can have a door? Does not that harm creativity?
Why Hopper (Top) and Cauldron (Top) as specified in MC-139435 should not block light is also a mystery to me. I guess for the hopper you could argue, that it has a hole, but what about the cauldron?
Can confirm in 1.20.4 and 24w13a