Bad search term lists every scanned object

[AntonyD]

Since the dot is included now in the descriptions by Ghisler, it no longer suggests to apply to all search modes.

And how does this proposal intersect with mine? In my opinion, this is a description of completely different parts of the process and reference.
Have you walked at my steps in checking? Got the same results? And can you understand them?

Without the dot, TC looks whether the text is present anywhere in the name, while with the dot it splits the search string into tokens and then tries to match them

And how does this coincide with my test?
If the phrase | FILE"NAME.EXT | divided into such components: | NAME | + | EXT | and discarded everything up to the symbol |"|,
then why did the result of the search with the names containing ONLY the sum of these components?
And not just these components in parts.
Those. In fact, these objects should have been found:
D:\--only files--\name
D:\--only files--\name.ext
[D:\==only folders==\name]
[D:\==only folders==\name.ext]

because there are millions of saved searches, where some of them would be broken by such a change.

And if you know HOW the processing logic will suddenly change - then you can create a dialog to transition from the incorrect
saved search patterns to the new, refined ones. Where you just specify what you need to delete/add/replace, if such actions
are needed. And no one will get an unexpected "gift" - everything will be done in plain sight.

[white]

Have you walked at my steps in checking? Got the same results? And can you understand them?

Yes . I wrote the wiki page for Search, so I understand very well. Do you understand the search modes?

If the phrase | FILE"NAME.EXT | divided into such components: | NAME | + | EXT | and discarded everything up to the symbol |"|,
then why did the result of the search with the names containing ONLY the sum of these components?
And not just these components in parts.
Those. In fact, these objects should have been found:
D:\--only files--\name
D:\--only files--\name.ext
[D:\==only folders==\name]
[D:\==only folders==\name.ext]

The different search modes have a different syntax and behave differently. If you know this, it makes no sense to expect them to behave the same way.

because there are millions of saved searches, where some of them would be broken by such a change.

And if you know HOW the processing logic will suddenly change - then you can create a dialog to transition from the incorrect
saved search patterns to the new, refined ones. Where you just specify what you need to delete/add/replace, if such actions
are needed. And no one will get an unexpected "gift" - everything will be done in plain sight.

Your suggestion seems to go in the direction of having 1 consistent search mode, independent of the contents of the search text. This goes far beyond this bug report and has more consequences than the situation you describe. If this is what you are suggesting, I suggest to start a new thread in the Suggestions forum.

[AntonyD]

If under the words "Search mode" we assume the ability to use internal engine for searching and|or external:

Code: Select all

Search text does NOT start with "ev:" or "ed:"

or

Code: Select all

it DOES start with these prefixes or plus it can starts with ">"

=> So yes - these modes are different modes;)
But if we suddenly MUST take into account the only one difference in the line by one char: 'dot' - then it's obviously a bug.
The 'dot' could be a part of regexp or ESC-sequences - and that's OK. Also it could be a simply part of a file object's full name.
Also it is trivial and understandable. BUT the phrase: "the dot it splits the search string into tokens" - obviously breaks my mind.

It is very strange that this can only be regarded as a suggestion for discussion, and not a fix for a long-term bug.

[white]

But if we suddenly MUST take into account the only one difference in the line by one char: 'dot' - then it's obviously a bug.

As explained on the wiki page, it is by design that the occurrence of a dot, wildcard or backslash, changes the search mode. If you want to call that a bug, that's fine by me. I certainly agree that it is not a user friendly design. That's why I created the wiki page, to make it at least clearer.

It is very strange that this can only be regarded as a suggestion for discussion, and not a fix for a long-term bug.

I did not say that. I made a suggestion, nothing more. It does however go far beyond the issue reported by the topic starter, which has been fixed. So I suggest to create a new thread if you want changes, either as a bug report or as a suggestion. This too is only a suggestion.

[AntonyD]

At a minimum, we need to wait here for a more detailed explanation from the author - how it happened
and WHAT he initially wanted to achieve with this "focus".

[ghisler(Author)]

Sorry, I don't understand what you mean with "focus", so I don't know what you want explained.

I'm moving this thread to the suggestions forum now, because it's about improving the search syntax.

Moderator message from: ghisler(Author) » 2025-02-07, 09:32 UTC

Moved to suggestions

[AntonyD]

We ask you to give more understanding about why, at all, there was a need to cut the symbol 'dot' from the string (search for:) and cut-off something before and after it. And also pay attention and explain - why this explanation given your earlier does not work on its logic during real-time verification.
I am talking about obtained results given at my post viewtopic.php?p=468187#p468187
starting from the phrase "And how does this coincide with my test?"

"focus" - it was by mistake not completely translated RU-word with meaning "To do something that you never expect and most often it gives the wrong results that you did not expect by the end."