Helgef wrote:]
The regex options ...) aren't part of the regex pattern, they are parsed and put aside, and correspond to certain option flags, which are bitwised combined to one option number, which is a pretty standard way of specify options for a function in many programming languages. For guis I think it would be reasonable to remove a lot of string options in favor of bit-wise combinations when defining styles for the guis. Methods and properties could set other options. (I'm thinking aloud, rather than making any definite claims on how things should be)

I don't think that using bitwise combinations in a language that doesn't have constants is a good idea.
Also RegExMatch is it's own thing from an external language. I have a few complains about it, however RegEx options are not needlessly complex when compared to jeeswgs inStr options.

- @Helgef: You're right that using leading characters (before the first ')') in RegExMatch, is AHK specific, however, 'm' is a standard part of RegEx:
pcresyntax specificationhttp://www.pcre.org/original/doc/html/pcresyntax.html(?m) multiline
- Returning an object would be OK, I would add an 'o' option to allow this.
- I currently use JEE_MX (if var in: exact match), JEE_MC (if var contains), JEE_StrMatch (all-purpose match function for other situations).
- I don't mind using a separate function, StrMatch, or amending InStr. However, I would probably end up discarding InStr entirely, because I like to be able to switch quickly from one needle to two needles.

- @nnnik: Ultimately, any points about autocomplete are irrelevant, autocomplete exists to save time, but changing one letter in a parameter, saves more time. Any functions suggested would be usable with autocomplete, just like any other function.
- Re. any potential concerns about readability in the options parameter, the main fix is to recommend using capital letters, as demonstrated below. But note: the readability issue applies to all sorts of functions e.g. MsgBox, InputBox, Sort, Loop, GUI functions/methods.
- 'I leave things out I consider common sense'. This is a dangerous and generally unwise thing to do in almost any industry. Not just regarding safety, it's a classic way to waste time, as it emerges that you shouldn't have left out the things you did. Also, who defines what is or isn't 'common sense'.
- You are welcome to comment on macro and micro layers, but please make your comments more specific. Also, remember, comments in the forum are for the benefit of everyone, not just me, so its better to express your points fully, than it is to hint at something but withhold information.
- Re. who or what is a programmer, or what they should know. I've produced some console and GUI apps in C++, I wouldn't recommend you to assume specific knowledge that all programmers know.
- Your point about checking the function name versus checking the parameter letter is a fair one. The solution is StrContains/StrExact for most purposes, and possibly StrStarts/StrEnds, and StrMatch for less common situations. Either way parameters for specifying the delimiter/case sensitivity/numeric comparison would still be necessary.
- Fundamentally it saves time, if you think through how people, not just me, will interpret your points, and aim for clarity and completeness. This is not meant to be unkind, but I generally find your posts to be the least clear on the forum, and when I translate posts from German to English, I still find your translated posts less clear than other people's translated posts. I have since found out though, that this is not because you are bad at expressing yourself, it is that you keep assuming that people know things and you keep omitting important details.
- I would be interested in your criticisms of RegEx.
- You said that my notation was more complicated than RegEx. In fact, I take this as a compliment. I did think that having roughly 10 options gave you something similar in scope to RegEx, but this is a good thing, I wanted an all-purpose string function, but that unlike RegEx, handled strings literally. The options are pretty straightforward though, similar to those of the Sort function.
- Generally when considering functions I look for very simple functions, that people are unlikely to object to, 'is this function the standard function that most people would produce'. For an all-purpose StrMatch function, similar to the Sort function, you have to be a bit creative, and offer a complete and novel package. I was quite prepared to hear objections to it, and/or amend my proposals accordingly. What is clear is that the issues I'm trying to address are important, and need to be addressed.

One thing that feedback has definitely helped me to see is:
- The benefits of being able to distinguish contains/in based on the function name, rather than having to check the parameter for X (or no X) each time.
- And as a result of this, having very short function names would be a consideration for such commonly used functions, I use MX and MC (match exact/match contains).