fix(that-than): catch 'less/fewer [adj] that' periphrastic comparison typos#3786
Open
yakubka wants to merge 1 commit into
Open
fix(that-than): catch 'less/fewer [adj] that' periphrastic comparison typos#3786yakubka wants to merge 1 commit into
yakubka wants to merge 1 commit into
Conversation
… typos
Added a second SequenceExpr branch to ThatThan that matches
'less' or 'fewer' followed by a plain (positive) adjective, then 'that',
then any word except 'way'. This catches patterns like:
'way less common that mp3' -> 'way less common than mp3'
'less reliable that the previous one' -> 'less reliable than the previous one'
'fewer errors that expected' -> 'fewer errors than expected'
The original linter only handled comparative adjectives (words ending -er
like 'smaller', 'faster') preceding 'that'. Periphrastic comparisons using
'less'/'fewer' + plain adjective were missed.
'more [adj] that [...]' is deliberately excluded because it frequently
introduces a correct subordinate clause ('more clear that users need to...'),
making it too noisy to flag without deeper grammatical analysis.
match_to_lint now derives the 'that' token index from toks.len() instead
of hardcoding 2, supporting the 5-token (adj that word) and 7-token
(less adj that word) patterns.
Fixes Automattic#3736.
Co-authored-by: IbrokhimN <ibragimnurullayev@gmail.com>
Collaborator
"Fewer [adjective]" is not grammatical. "Fewer" can be used before a plural noun. You surely meant "less/more" here? |
hippietrail
requested changes
Jul 8, 2026
hippietrail
left a comment
hippietrail
left a comment
Collaborator
There was a problem hiding this comment.
You surely mean "less <adj>" and "more <adj>" and not "fewer <adj>"?
| // "that" should be "than". "more [adj] that" is excluded because it | ||
| // frequently introduces a correct subordinate clause ("more clear that | ||
| // users need to..."). | ||
| let periphrastic_that_nextword = SequenceExpr::word_set(&["less", "fewer"]) |
Collaborator
There was a problem hiding this comment.
This is "fewer correct" than you think it might be (-;
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #3736.
The ThatThan linter currently catches comparative adjective forms like "smaller that", "faster that", "longer that" by matching tokens where TokenKind::is_comparative_adjective precedes "that". It does not catch periphrastic comparisons of the form "less/fewer [positive adjective] that [...]", so "way less common that mp3" passes through unflagged.
This PR adds a second branch to the SequenceExpr that matches "less" or "fewer" followed by a positive adjective, then "that", then any word except "way". The match_to_lint function now derives the "that" token index from toks.len() to support both the 5-token pattern (adj ws that ws word) and the new 7-token pattern (less ws adj ws that ws word).
"more [adj] that" is excluded intentionally. "more [adj] that [clause]" frequently introduces a correct subordinate clause ("more clear that users need to...", "more explicit that those files are..."), so flagging it would produce too many false positives without deeper grammatical analysis. The existing test cases dont_flag_more_explicit_that and dont_flag_more_clear_that still pass.
Three new tests cover the added pattern. The remaining existing tests are unchanged.
Yokubjon Nurullaev identified the gap in the periphrastic branch, wrote the SequenceExpr and updated match_to_lint to handle the variable token index.
IbrokhimN reviewed the "more" exclusion decision, proposed the dont_flag tests that guard against subordinate clause false positives, and added the fix_fewer_errors_that test case.