Thanks. It might be moot if I decide to go the DLL route. If anyone knows more about the above, please let me know.
PCRE is under the BSD license; I can't see any problems [including it in a GPL project] as long as you include the copyright notices. Then again, I am not a lawyer and these guys see things we mortals simply do not see.
Ah ha! I'd forgotten about the library/linking permission. That's a great option to have in case it's not legal to directly include the source code inside a GPL project.
I believe there is no problem to link a library under a modified BSD licence (or any other GPL-compatible licence) to a GPL program. For example, the Hypermail program mentioned in the PCRE home page is GPL.
I'd forgotten about that! I've added a link up top to Regular expressions: a wrapper around the PCRE DLL. I intend to study it to find out how close it is to a complete solution (maybe all I have to do is convert your approach to C code ).
I would like to have my own "pure" AHK wrapper to be mentioned in the first article, thank you.
Great. If you have any more details about compiling the DLL that way -- or maybe even a ready-made, optimized DLL and/or LIB -- please let me know.
A point of interest: PCRE (the only one, by Phil Hazel) has shrunk in size between 6.4 and 6.5, because of optimization of a big Unicode table. And actually we can compile this library without any Unicode (UTF-8 ) support, since AHK doesn't support it anyway. Thus getting a smaller size and a small speed increase.
I do try minimize the number of parameters, or at least move seldom used parameters to the end of the parameter list so that they can be optional. Another way is to sneak in new parameters by combining them (like you mention below).
...lacks a important parameter, that PCRE supports: offset in the string.
Good idea (especially the options merging). You can tell from the GUI commands that I like having a combined options parameter (though it has its drawbacks).
Perhaps we could add a function (or constant to overwrite) to set the options for the next calls.
Perhaps we can integrate offset to options, and either add a parameter to RegExReplace to indicate the number of changes ("A" for all) or integrate this to options too.
I really appreciate how detailed that is. I think it will be a great help.
I started to rewrite my PCRE wrapper more in the AHK spirit, avoiding to separate compilation phase, but I can try to advance it to show what I would like for syntax, on the lines of my signature:
result := RegExMatch(bigString, regex[, offset, options])
result := RegExReplace(bigString, regex, replaceExpr[, offset, options])
result := RegExSplit(bigString, regex[, options])
The prefix can be shortened or omitted. It probably needs helper functions to access the results (at least for Match).
Did that in hurry, needs more thinking for a friendly interface.
I think that would require either a new SetTitleMatchMode or something like IfWinExist ahk_regex. Your // idea is also a possibility.
I saw from time to time requests to support REs in IfWinActive and related commands. Better than SetTitleMatchMode...
I feel that users will wonder why everywhere there is a WinTitle or WinText or exclude variants, REs are not allowed. Not that I will use this feature very often, but I guess such questions are pending...
I believe that regular expressions should be pervasive in AutoHotkey, exactly like expressions are now!
In other words, everywhere a match can be done against a string, it should be possible to do it against a regular expression...
Perhaps the easiest way to do this is to create a special operator, like %(A_Space) (ie. like MsgBox % GetData(x)).
For consistency with other languages, it could be / or // (because we often write /[a-b]+/ and such). Of course, a better choice can be made, for readability, intelligibility and compatibility.
Ambitious yet attractive. However, it might help to create a more complete/interesting list of where this proposed RegEx extension would be used -- such as WinTitle, WinText, some functions/commands that you mention below. As it stand now, the benefit vs. cost doesn't seem compelling.
This is the way to go. This is the true power. About the n00bs and performance, I think you worry too much. 8)
Now that I think about it, I'm leaning away from retrofitting old commands to support RegEx. For one thing, it would be a lot of coding, at least in some cases. For another, spending time extending commands would be a waste if some of them will someday be better expressed/popular as a function (StringReplace might be one example of this). Finally, users of RegEx tend to have a technical background and thus might generally prefer functions instead of commands.
If not using the special operator, the commands remain unchanged.
[color=green]StringSplit a, line, // [:;]
Both syntaxes and ways can pacifically coexist.
The only drawback is that the doc. will grow again. ;-)
For now, I tend to agree with this. But more discussion is welcome.
For what you and everyone have said, I think there should at least be an alternate version of AutoHotkeySC.bin that contains built-in RegEx (if it's not too much work).
I'd prefer not to have to deal with a separate DLL for distribution purposes (that's a vote for including it by default in AHK and a compiled script if needed).
Although not very readable, its brevity is admirable and probably addictive to veterans. However, given AHK's current emphasis on readability, perhaps something longer yet intuitive would be better.
The closer a replace operation is to
... the easier it will be to use.
Thank you all for sharing your ideas and experience. Please post more ideas as they occur to you.