Implementation

This mod purely client-side, but supports custom commands, defined by other mods, datapacks or server plugins.

• Implementation
• Suggestion Filtering
• Word Splitting
• Suggestion Sorting

Implementation

To provide better completions for a command node we send two/three requests asking for suggestions to the server:

• The one Vanilla would usually send, informed
• One without the last partially typed argument, arg-blind
• Optionally, one without the last partially typed word if the last argument node consists of several words (e.g., some World Edit commands), word blind

We then rely on the server replying with all unfiltered relevant suggestions to the blind requests.

Note

Suggestions for most normal commands are known since the moment your client logs in a server and do not actually require a network request, this is only the case for some custom commands. This mod doesn't change any of that logic, it simply asks Minecraft to get the suggestions how it normally would, but twice. However, that's a little more complex to explain than simply saying it sends two requests for suggestions, which also expresses the fact that the mod will work with any kind of custom server commands.

Once the lists of suggestions arrive, in whichever order, they're combined, filtered and sorted them, according to the strategies described below, and, once sorted, we update the displayed suggestions.

In addition, since, while typing a single command, it is unlikely that the results for the blind requests will change, we may cache these requests.

Tip

The behavior of the query cache can be configured with the /smartcompletion command. The default configuration is volatile (resets whenever you start typing a fresh command), and shouldn't cause any trouble.

If the server replies with suggestions for the informed request that were not matched by our filtering on the blind lists, they will be suggested after any other matched suggestions, highlighted with a different color (dark aqua by default).

This implementation should work well with any custom commands, added by either mods or datapacks.

Suggestion Filtering

Suggestions are matched to your partially typed arguments using two different approaches:

• A smart match between segments of your query and the initials of parts of the suggestion (gr matches [g]ame[r]ule)
• A weak search for each part of your query within the suggestion, in order (lock on matches b(lock)Explosi(on)DropDecay)

A suggestion will be shown if any of these approaches matches it, but smart matches will be shown first.

Both approaches are case-insensitive.

Note

The exact implementation for the matching method can be found in the source of the MultiMatcher class, and it's described by the tests of SmartCommandCompletionTest.

Word Splitting

We split words at any non-alphabetic character, as well as at camelCase words.

In addition, if a command cannot be split in this way, we will assume it's written in flatcase (like most Minecraft commands), and attempt to split it using a list of known words.

Tip

This list of words is defined by the flatcase_splitting.json file, and can be overridden by resource packs (see wiki). By default, it contains words used by Minecraft, Forge, Fabric and WorldEdit commands, as well as a few more.

Note

The exact implementation of the word splitting algorithm can be found in the source for the SmartCommandCompletion#split and SmartCommandCompletion#splitWord methods.

Suggestion Sorting

Suggestions are sorted according to heuristics designed to fit a few use cases, which can be found in the tests.

Summarized, we use the following criteria to sort suggestions, in order:

• suggestions targeting a position closer to the cursor are shown first (/give @p chest suggests [ before minecart_chest)
• smart matches > weak matches > unexpected server suggestions ([d]o(D)aylight[C]ycle > sen(dC)ommandFeedback)
• significant matches beyond some thresholds are shown first ([app]le > [a]cacia_[p]ressure_[p]late)
• more part matches > less part matches ([d]o[I]nsomnia > [di]sableRaids)
• matches where a single query part could've matched more than one suggestion part are sorted first ([d]o(D)aylight[C]ycle > [d]oWeather[C]ycle)
• less suggestion parts > more suggestion parts ([d]o[I]nsomnia > [d]o[I]mmediateRespawn)
• earlier matched parts > later matched parts ([g]ame[m]ode > default[g]ame[m]ode)
• shorter suggestions > longer suggestions ([t]p > [t]ell)
• original order from the server (usually alphabetic) ([f]all[D]amage > [f]ire[D]amage)

Note

The exact implementation of this sorting order can be found in the source for the MultiMatch#compareTo and SmartCommandCompletion#filterAndSort methods.