Fix search substrings

[mayank1008-tech]

Closes #14569

Description

Description
This PR addresses the issue where searching for partial words (e.g., "dorf") in linked file content failed to find documents containing the full word (e.g., "Düsseldorf").

I modified LinkedFilesSearcher.java to:

Enable Leading Wildcards: Updated the Lucene query parser configuration to allow leading wildcards (parser.setAllowLeadingWildcard(true)).

Automate Wildcard Wrapping: Modified the query logic to automatically wrap search terms in asterisks (e.g., transforming query to *query*) if the user hasn't explicitly provided wildcards. This ensures that terms like "dorf" effectively search for *dorf*, enabling substring matches.

Steps to test

1. Have a PDF file Dusseldorf.pdf containing unique text (e.g., the word "Düsseldorf").
2. Create a BibTeX entry and link this PDF to it.
   Note: Ensure the file link includes the .pdf extension in the BibTeX source (e.g., file = {:Dusseldorf.pdf:PDF}) to ensure the indexer reads the content correctly.
3. In the search bar, type a substring of the word (e.g., eldorf).
4. Verify that the entry containing "Düsseldorf" appears in the search results.

Mandatory checks

• I own the copyright of the code submitted and I license it under the MIT license
• I manually tested my changes in running JabRef (always required)
• I added JUnit tests for changes (if applicable)
• I added screenshots in the PR description (if change is visible to the user)
• I described the change in CHANGELOG.md in a way that is understandable for the average user (if change is visible to the user)
• I checked the user documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request updating file(s) in https://github.com/JabRef/user-documentation/tree/main/en.

[koppor]

Please also come up with a test case covering mixed sesrch strings.

author=~*dorf AND Düssel

See https://docs.jabref.org/finding-sorting-and-cleaning-entries/search for a full syntax description

[mayank1008-tech]

@koppor Hi! I've pushed the new test case for the mixed search query (Metadata(author) + Fulltext in the file).

I made a small adjustment, the original suggestion was 'author=~*dorf', but * is a quantifier that requires a preceding character. I updated it to 'author=~.*dorf' (where . matches any character).

I also used the test data to use the actual author name ('Author Name') from thesis-example.pdf. The test is passing and confirms that the searcher correctly filters by both metadata and file content.

[subhramit]

@koppor Hi! I've pushed the new test case for the mixed search query (Metadata(author) + Fulltext in the file).

I made a small adjustment to the regex syntax in the query. The original suggestion was 'author=*dorf', but since JabRef uses Java's regex engine, * is a quantifier that requires a preceding character. I updated it to 'author=.*dorf' (where . matches any character).

I also updated the test data to use the actual author name ('Author Name') from thesis-example.pdf to make the test scenario more realistic. The test is passing and confirms that the searcher correctly filters by both metadata and file content.

Please be aware of our AI usage guidelines. You may be blocked if you keep using AI to communicate.
Ref. https://github.com/JabRef/jabref/blob/main/AI_USAGE_POLICY.md, https://github.com/JabRef/jabref/blob/main/CONTRIBUTING.md#ai-usage-policy

[LoayGhreeb]

This way makes every query a substring match, even when the query is intended to be an exact match (e.g., content == "dorf").

This logic should be handled during query parsing, where you have access to the search flags, each field, and can decide when to add the surrounding asterisks. Please take a look at the SearchQueryConversion and SearchToLuceneVisitor classes.

[LoayGhreeb]

You might only test that the search query is being parsed and converted correctly to include asterisks when needed. You can add test cases to SearchQueryLuceneConversionTest.

[LoayGhreeb]

Also, this will make the default Lucene search behave as a substring search, which will cause Lucene to scan the entire index for each search. It's better to keep the default as Lucene's standard lexical search to benefit from features like fuzzy matching, tokenization, and performance optimizations.
For substring searches on linked files, queries like content = *query* can be used.

[mayank1008-tech]

Also, this will make the default Lucene search behave as a substring search, which will cause Lucene to scan the entire index for each search. It's better to keep the default as Lucene's standard lexical search to benefit from features like fuzzy matching, tokenization, and performance optimizations. For substring searches on linked files, queries like content = *query* can be used.

@LoayGhreeb The main motive of this issue was to find the substring in the linked files. But yes if we apply wildcards to every other thing coming, will be highly unoptimal. So should i go for applying asterisk for the 'content' field only in which we have to search in the linked file only?