[StefanM]

Please have a look at the screenshot:



P? should only return packages that start with P followed by one single character.

But it also returns 2022-03-28 TP-GR

If I remember correctly, I tested this before after your changes and it did work correctly.

*P?, however, returns only P followed by one single character.

[Jiaz]

It's not a bug. I've implemented it this mode, see en.wikipedia.org/wiki/Wildcard_character

? matches exactly one character. In DOS, if the question mark is placed at the end of the word, it will also match missing (zero) trailing characters; for example, the pattern 123? will match 123 and 1234, but not 12345.

If necessary I can add advanced setting to change the ? mode

[StefanM]

Originally Posted by Jiaz

It's not a bug. I've implemented it this mode, see en.wikipedia.org/wiki/Wildcard_character


If necessary I can add advanced setting to change the ? mode

Yes, I would appreciate "Windows" mode functionality.
As far as I know, it's the same in Linux, right?

BTW:
In my first tests after your changes (your implementation of '?')
file1.?? returned file1.rm but not file1.ram
Now, this has changed. :(
It also returns file1.ram

Not as wanted/expected

[Jiaz]

Originally Posted by StefanM

Yes, I would appreciate "Windows" mode functionality.
As far as I know, it's the same in Linux, right?

That's fine for me. Easier to implement Will change it to this mode then.

Originally Posted by StefanM

BTW:
In my first tests after your changes (your implementation of '?')
file1.?? returned file1.rm but not file1.ram
Now, this has changed. :(
It also returns file1.ram

Yes, you are right, I've *fuxxxx* up the logic and broke it. But as I will remove the trailing special handling, no longer will be problem with next core update.

check again with next core update

[StefanM]

Originally Posted by Jiaz

That's fine for me. Easier to implement Will change it to this mode then.


Yes, you are right, I've *fuxxxx* up the logic and broke it. But as I will remove the trailing special handling, no longer will be problem with next core update.

check again with next core update

Not working correctly!!!

p? now returns everything, where the second last character is a p.

p? may only return strings starting with a p and having exactly 2 characters.

[Jiaz]

@StefanM: I'm sorry but working fine here, can't reproduce the issue
Filename: test.txt
yes: test.txt
yes: test.*
yes: test.???
yes: *.???
no: test.??
no: test.?

[Jiaz]

@StefanM: now I understand. wait for next core update
update will be available in next 5 mins

[StefanM]

Originally Posted by Jiaz

@StefanM: now I understand. wait for next core update
update will be available in next 5 mins

Looking good again!
But I will perform a more thorough test later, maybe tomorrow.

Now I will test a few scenarios from my prio question.
Yes, I know the last sentence doesn't belong here.......

[Search&Destroy]

I also have some Problems with Wildcard character.
I search a lot with *
If I have a package, lets call it:
This is an example Name for a Package

If I put in Search:
This*Package
it should find the Package name, but it does not anymore (it worked this way a few days ago).
I have to search for this, than it will work again:
This*Package*

Is this a bug or a feature

[StefanM]

It is a feature/correction, as * and ? now work as in any other standard search:

This*Package should only return results which start with This and end with Package

As soon as there are additional characters after Package you have to enter This*Package*.
That's the definition.

[Jiaz]

@Search&Destroy
Can you please check if there is a space or something else behind Package?
I will test myself by tomorrow

[radorn]

Originally Posted by StefanM

It is a feature/correction, as * and ? now work as in any other standard search:

This*Package should only return results which start with This and end with Package

As soon as there are additional characters after Package you have to enter This*Package*.
That's the definition.

I was going to ask about this.
So, if I understand correctly, the idea is to enforce * for any variable content instead of assuming * for incomplete ends? But why not beginnings too for consistency?
For example searching for is*package* will also match this package and, in the same way this*package* will match in this package.
Why not treat the head the same way as the tail?

[Jiaz]

@radorn: thanks for the report! could reproduce the issue and will be fixed with next core update

[radorn]

It enforces the use of asterisks in many searches where they weren't necessary before, which is not all that intuitive, but I guess it allows for more precise searches, and if it's going to be done for ends, I think it should also be done also for beginnings, for consistency and for the gains in precision.

Thank you for your work

[Jiaz]

Originally Posted by radorn

and if it's going to be done for ends, I think it should also be done also for beginnings, for consistency

That's the bug that will be fixed with next core update. As soon as ? or * is in use, the wildcard mode will be used. there was a bug where this mode switch was not correct.

Originally Posted by radorn

It enforces the use of asterisks in many searches where they weren't necessary before

Correct, I'll look forward to more user feedback on this and most likely add advanced settings to enable *old behaviour* if preferred

[StefanM]

Originally Posted by Jiaz

...I'll look forward to more user feedback on this and most likely add advanced settings to enable *old behaviour* if preferred

Pooooh!
So glad to hear that you will not remove the new behavior - which is in compliance with the official definition - once again.

[Jiaz]