[Lazarus] TMask revisited

[Bart]

On Fri, Oct 15, 2021 at 1:55 AM Juha Manninen via lazarus
<lazarus at lists.lazarus-ide.org> wrote:

>
> On Thu, Oct 14, 2021 at 7:57 PM Bart via lazarus <lazarus at lists.lazarus-ide.org> wrote:
>>
>> You have changed the existing interface for both TMask and the
>> Matches(Windows)Mask(List) functions.
>> TMaskOptions has been removed.
>
>
> It can be added for compatibility.

Please do.
But, also feel free to deprecate them.

>> Noticable the ability to NOT interpret [] as a set in the mask has now
>> disappeared.
>
>
> How should a range / set [] be interpreted?

??
[az] is interpreted as either a or z by default
Diasbling use of sets would interpret this as literally [az] (4 chars).

> Now the same thing is done by passing MaskOpCodesDisableRange constant where type TMaskOpcodesSet parameter is used.
> TMaskOptions can be restored for compatibility.

OK.

>> You have sacrificed consistent and reliable behaviour for gain of speed.
>
> No Bart, that is not true. This is not only about speed. The old Mask was buggy and limited.

I agree about the limited part.
Not many bugs were filed against asks unit, and I did not encounter
them, but my locale is Ducth and the ocaasional non-ascii I happen to
have in my filenames all process correctly.

> Please run the test project testmasks.lpi. All current tests pass.
> Now checkout a revision before my Mask changes, eg. e5ed5082d and run tests again. Many errors. Notably there was no support for Unicode.

I'll have a look.


> Yes, there should be an option for backwards compatible syntax, like "[?]" . However the small changes in the syntax can be seen as improvements.
> There already is a define for converting "[z-a]" to "[a-z]".

Why a define?
Shouldn't that better be configurable at runtime?


>> José's code also catered for some odd DOS behaviour where a mask like
>>
>> 'file.txt?' actually matches with the filename 'file.txt' and a mask
>> 'file?.txt' would match 'file1234.txt' (but not 'file12345.txt').
>> That would be rather counter-intuitive to most users.
>> I did not test (it was in one of the "quirks" settings) if it behaves
>> like this by default, but that should IMHO not be the case.

I tested it now, and by default it returns fals for those cases.

> Yes it is counter-intuitive but it matches with Windows' behavior.
> You can test it on a DOS/Windows cmd prompt.

file?.txt matches file.txt and file1.txt, but not file12.txt, so ? as
last char before . is treated as no or 1 character.

> That is why it is called TMaskWindows. The normal TMask behaves more logically.
> The "quirks" prove that Jose has tested it a lot.
>
> About the speed: TMask can also be used without disk file operations. Then the speed matters.
Yes it can, but it was desigend for filemasks (see the original
parameter names).

> I will look at the compatibility issues and possible bugs tomorrow.

Thank you.

I did not study th enre code at length, but it looks quite a bit more
complicated to me than the old one.
Not sure if I will be able to contribute to it anymore.


-- 
Bart