Search with special character "?" breaks search logic #3462

Activity

1. github-actions commented on Oct 4, 2026

   

   github-actionsbot

   on Oct 4, 2026 – with GitHub Actions

   More actions

   This issue has been automatically marked as stale because it has not had
   any activity in over 2 years.

   If this issue is still relevant:

   • Please test on a current version of this package.
   • Add a comment with your findings

   If no activity occurs in the next 30 days, this issue will be
   automatically closed. Issues can be reopened if needed.
2. github-actions

   added

   stale

   on Oct 4, 2026
3. E-Thang commented on Oct 5, 2026

   

   E-Thang

   on Oct 5, 2026

   Last edited by E-Thang

   Author

   More actions

   This is still relevant in Nemo 6.6.3 (Mint 22.3 Cinnamon). The behavior is slightly better now though. I had Google Gemini prepare a better problem statement and test cases.

   Test Environment & File List
   Files/Directories: A, B, C, AB, BA, BCA, AAA, AAAA, D, AA, BB, CC, BAB, CBAC
   Settings: Case insensitive search mode, regex match disabled, containing filter empty.
   (Note: I have tested this against both files and directories, and the behavior is identical for both, as expected.)

   The Core Issue Identified

   • Nemo usually performs implicit substring matching (typing A acts like *A*). However, if a wildcard (? or *) is used anywhere in a space-separated token, Nemo drops the implicit substring matching for that specific token and treats it as an exact, anchored glob match.
   • Should ? and * even be parsed as a wildcard search? They are valid characters in file names.

   Verification Test Cases

   Search Term	Expected (If substring behavior was consistent)	Actual Result	Developer Note
   A	A, AB, BA, BCA, AAA, AAAA, AA, BAB, CBAC	Matches Expected	Baseline: Implicit *A* substring matching works.
   A B	AB, BA, BCA, BAB, CBAC	Matches Expected	Baseline: Space acts as a logical AND (*A* AND *B*).
   A?	AB, AA, AAA, AAAA, BAB, CBAC	AA, AB	BUG: Token is anchored as ^A.$ (exactly 2 chars). Implicit asterisks are incorrectly dropped.
   *A?*	AB, AA, AAA, AAAA, BAB, CBAC	Matches Expected	Manually adding the asterisks restores the expected substring behavior.
   A B?	BA, BCA, BAB, CBAC	BA only	BUG: Evaluated as "Contains A" AND "Is exactly two chars starting with B". Fails to match the others because Token 2 loses substring behavior.
   A *B?*	BA, BCA, BAB, CBAC	Matches Expected	Manually adding asterisks fully restores substring behavior for Token 2.
   ?	All files	A, B, C, D	BUG: Evaluated as "Filename is exactly 1 character long". It should act as "Contains at least 1 character" to match normal substring behavior.
   *?*	All files	Matches Expected	Manually adding asterisks fully restores substring behavior for a standalone wildcard.
   A ?	A, AB, BA, BCA, AAA, AAAA, AA, BAB, CBAC	A only	BUG: Token 2 (?) drops its implicit asterisks. The search effectively becomes "Contains A" AND "Is exactly 1 char long", which only leaves A.
   ?A?	BAB, AAA, AAAA, CBAC	BAB, AAA	BUG: Evaluated as exactly 3 characters. Fails to match longer strings because the token is anchored.

   Expected Resolution

   • When Regex is disabled, wildcards should not disable Nemo's implicit substring behavior. A search for A? should be parsed under the hood as *A?* so it behaves consistently with normal text searches. This may be achieved via modification of the core search algorithm or via preprocessing of the search terms (Find a ? and blindly append asterisks to that token)
   • Document expected ? and * search behavior
   • If ? and * wildcards are expected, then provide a way to disable that parsing.