Loop Files should support an array of FilePattern

[iseahound]

Code: Select all

#Requires AutoHotkey v2.0

loop files, ["*.ahk", "*.txt"]
   msgbox a_loopfilename

You could also just make the comma a special character:

Code: Select all

#Requires AutoHotkey v2.0

loop files, "*.ahk, *.txt"
   msgbox a_loopfilename

but if FilePattern refers to a Windows FilePattern, then the former would be more appropriate.

I should probably mention here that the primary motivation is to support the Loop Files [FilePattern1, FilePattern2] else clause. Yes, I can have a sequence of Loop Files, but that would kind of defeat the purpose of the new loop-else construct in v2.

[lexikos]

"*.ahk, *.txt" is a valid file pattern that would match (for example) a file named "a.ahk, b.txt". Pipe (|) is reserved by the system, so would be more appropriate, but v2 already moved away from this convention. I see no reason to do it this way vs. an array.

The system doesn't support anything like this.

My first thought of how to implement is to iterate over all files and manually match each pattern against each filename. (This is hypothetically also how I would implement regex file patterns.) However, I don't see this working since there's no base directory to apply to all elements, and each element could have a different directory.

So instead, the file loop would effectively just iterate over the array and behave as though there was one Loop Files for each element. I would say to just use a nested loop, but you make a good point about loop-else.

A while ago, I decided that the loops should all eventually be consolidated into for by implementing various enumerators (ideally with optimizations to objects and strings to mitigate the overhead). Enumerators can be "composed" with other enumerators or predicate functions. The problem is that recursive file loops are... recursive. Converting the current implementation to be purely iterative will be more work than I was willing to put in for v2.0, especially given that I had recently (in 2019) done a lot of work on it to enable long paths.

When I do work on this, I intend to allow for more advanced file patterns, such as "a\b*\c*", which can be implemented by separate enumeration of b* and c*. I think that even implementing this in script (without building intermediate arrays of filenames) would be relatively simple if there was a file enumerator.