Re: [PATCH v3 6/8] parseopt: autocorrect mistyped subcommands

From: Jiamu Sun <39@barroit.sh>
Date: Mar 11, 2026, 23:26 UTC
Message-ID: <SY0P300MB0801C9B110080DA6DE9827BFCE47A@SY0P300MB0801.AUSP300.PROD.OUTLOOK.COM>
In-Reply-To: <SY0P300MB0801DA185098623A3729B9F8CE47A@SY0P300MB0801.AUSP300.PROD.OUTLOOK.COM>

On Wed, Mar 11, 2026 at 11:48:41AM +0900, Jiamu Sun wrote:

Show 6 quoted lines

> > There should be some explanation on the reason why this is very
> > different from SIMILAR_ENOUGH used in help.c for main commands,
> > especially given that the levenshtein() call here uses identical
> > weight parameters (0,2,1,3) as used by the call there.
> 
> Will add a comment to explain it.

	/* skip and count prefix matches */
	for (n = 0; n < main_cmds.cnt && !main_cmds.names[n]->len; n++)
		; /* still counting */

	if (main_cmds.cnt <= n) {
		/* prefix matches with everything? that is too ambiguous */
		best_similarity = SIMILARITY_FLOOR + 1;
	} else {
		/* count all the most similar ones */
		for (best_similarity = main_cmds.names[n++]->len;
		     (n < main_cmds.cnt &&
		      best_similarity == main_cmds.names[n]->len);
		     n++)
			; /* still counting */
	}

	if (autocorrect.mode != AUTOCORRECT_HINTONLY && n == 1 &&

If I read the code correctly, for the prefix matched case, the similar command finding in help.c skips all prefix matched strings and increases "n". Inside the "else", since that "n++", the "n" will always be greater than one, thus no correction happens, e.g., it doesn't autocorrect "commi" to "commit". Do you know if this behavior is by design or something else?