Fuzzy/camel-case completion matching

[stalep]

Summary

Add fuzzy and camel-case matching to tab completion so users don't need to type exact prefixes.

Description

Camel Case Matching

Match abbreviated camel case patterns against completion candidates:

• gCI matches getCursorIndex
• NPE matches NullPointerException
• sH matches setHandler, showHelp

Fuzzy Matching

Tolerate minor typos in completion input:

• comit matches commit (missing letter)
• stauts matches status (transposed letters)

Implementation Notes

The fuzzy matching library added in aesh-readline (issue #180) provides the scoring infrastructure. This issue is about integrating it into the completion pipeline:

1. When exact prefix matching finds no candidates, fall back to fuzzy matching
2. Score and rank fuzzy matches
3. Camel case matching can use the existing BONUS_CAMEL_123 scoring from the fuzzy matcher

Priority

Medium — nice productivity improvement for power users.

[stalep]

Implementation Plan

After analysis, here is how this could be implemented. Keeping this for future reference.

Scope: Interactive terminal only

Fuzzy/camel-case completion should only apply in interactive terminal mode (ReadlineConsole), not in shell completion scripts:

• Interactive terminal: aesh controls the full completion pipeline end-to-end, so fuzzy candidates can be presented directly. This is where fuzzy matching has the most value.
• Dynamic shell scripts (--aesh-complete): The shell (bash/zsh/fish) re-filters returned candidates with its own prefix matching, so fuzzy results would be discarded anyway. No change needed.
• Static shell scripts (--aesh-completion): Candidate lists are baked in, shell does prefix matching. No change needed.

This avoids any sentinel-based workarounds in shell script templates.

Prerequisite: Move fuzzy library to readline-api

The fuzzy matching code (org.aesh.readline.fuzzy package — FuzzyAlgo, FuzzyScorer, FuzzyScheme, FuzzyResult, CharClass) currently lives in the readline module. However, some consumers (e.g., jbang) depend only on aesh + readline-api, not the full readline module.

The fuzzy code has no dependency on readline internals — it operates on int[] code points and only references Parser.fromCodePoints() from terminal-utils (which readline-api already depends on). Moving it to readline-api makes it available to all consumers without adding a new dependency.

Steps:

1. Move org.aesh.readline.fuzzy package from readline to readline-api module
2. Release aesh-readline 3.13
3. Bump aesh's readline dependency to 3.13

Design: Fallback strategy

Fuzzy matching is a fallback when prefix matching produces no results. Existing behavior is preserved exactly — users who type exact prefixes get the same experience:

candidates = prefixMatch(input)
if candidates.isEmpty() and input.length() >= minFuzzyLength:
    candidates = fuzzyMatch(input, allCandidates)
    sort by score descending

A minimum input length (2 characters) prevents single-character typos from producing too many low-quality matches.

Camel-case matching

Already supported by FuzzyAlgo via BONUS_CAMEL_123 scoring. No special handling needed — gCI matching getCursorIndex works because each uppercase letter gets a camelCase transition bonus.

Integration points (4 locations)

1. Option name completion — ProcessedCommand.findPossibleLongNamesWithDash() and findPossibleBareLongNamesWithDash(): when prefix matching returns empty, fuzzy-match against all available option names (~10 lines each)

2. Command name completion — MutableCommandRegistryImpl.completeCommandName(): when no command startsWith the typed text, fuzzy-match against all registered command names (~10 lines)

3. Subcommand name completion — AeshCommandLineCompletionParser.doProcessGroupCommand(): same fallback pattern for child command names within a group (~10 lines)

4. Option value completion — Deferred. Option values are domain-specific (file paths, enums, custom lists). Fuzzy matching here would require either wrapping all completers or individual opt-in.

New code

• FuzzyCompletionMatcher utility class (~80 lines): thin adapter between aesh's TerminalString candidates and FuzzyScorer. Uses FuzzyScheme.DEFAULT (good for option/command names with camelCase and dash boundaries), case-insensitive.
• Configuration: SettingsBuilder.fuzzyCompletion(true/false) (default: true)

Estimated scope

~270 lines total (80 utility + 40 integration + 150 tests), plus the readline-api module move as prerequisite.

Risk

Low — fuzzy matching is fallback-only, no startup cost, no per-option overhead, fully backward compatible. All existing completion tests pass unchanged.