Support alternate commands for invoking regex

[elight]

Given that regular expressions are frequently referred to as one of "regexp" and "regex", suggest allowing either usage to evoke the appropriate filter such that both of the below work:

description regex matches /foo/
description regexp matches /foo/

This is a UX/DX affordance to minimize errors and frustration on the part of, at least, this user.

[claremacrae]

Good idea.

To anyone reading this, a pull request would be very welcome.

[Cito]

It would be also nice if the order of keywords could be switched:

description matches regex /foo/

This is much easier to read and more similar to how you would say it in natural language.

[Cito]

In #1153 we found that we should discuss the following possible changes a bit more before implementing (some) of them:

1. Allowing regexp instead of regex
2. Allowing to write matches regex instead of regex matches
3. Making the regex clause optional, i.e. allowing just matches instead of regexp matches
4. If we agree to allow multiple variants of the syntax for backward compatibility and giving users freedom to write queries in a way that sound more intuitive for them, we should define one variant as the "default syntax" that is used in the documenation, examples and quick ref. The variants would then be tested and only mentioned once in the detailed docs.
5. Currently, the part between regex matches and the regular expression in slashes is ignored by the parser, you can put any words in there. Should we be more strict here and make it an error if you put anything there?

Please voice your opinions.

Personally, I tend to allow all the variants, but make a simple "matches" the default syntax. My thought is that by putting the regex in slashes it is also sufficiently clear that this is not ordinary text but a regex. Regarding point 5, I would make the parser more strict and consider it an error if anything except whitespace is between the keywords and the regular expression.

I also tried to look at how others name it. PostgreSQL uses ~ as operator. MySQL uses REGEXP as operator (not REGEXP MATCHES or MATCHES). MongoDB uses $regex: /.../. PostgreSQL and CouchDB also use the function name regexp_match(es) which is very similar to our syntax, but we use it as operator, not as function. Oracle uses regexp_like. The Redis SCAN command has a MATCH pattern clause, but with glob patterns. SQL also has the SIMILAR TO operator, but this is used with special SQL style regular expressions, not with the common POSIX ones. IBM RBD uses matches. Perl uses =~. JavaScript has the string.match(pattern) syntax, and RegExp as object name for regular expression patterns. So OP is right, REGEXP seems to be even more common than REGEX. Some languages like Python also name it just RE.

[elight]

While I personally love the idea of `description matches /<pattern> /`, this risks breaking any users who already has a legitimate use for / in their tasks. Otherwise, I support your other points. 

On September 18, 2022, Vipercat ***@***.***> wrote: In #1153 <https://github.com/obsidian-tasks-group/obsidian- tasks/pull/1153> we found that we should discuss the following possible changes a bit more before implementing (some) of them: 1. Allowing regexp instead of regex 2. Allowing to write matches regex instead of regex matches 3. Making the regex clause optional, i.e. allowing just matches instead of regexp matches 4. If we agree to allow multiple variants of the syntax for backward compatibility and giving users freedom to write queries in a way that sound more intuitive for them, we should define one variant as the "default syntax" that is used in the documenation, examples and quick ref. The variants would then be tested and only mentioned once in the detailed docs. 5. Currently, the part between regex matches and the regular expression in slashes is ignored by the parser, you can put any words in there. Should we be more strict here and make it an error if you put anything there? Please voice your opinions. Personally, I tend to allow all the variants, but make a simple "matches" the default syntax. My thought is that by putting the regex in slashes it is also sufficiently clear that this is not ordinary text but a regex. Regarding point 5, I would make the parser more strict and consider it an error if anything except whitespace is between the keywords and the regular expression. I also tried to look at how others name it. PostgreSQL uses ~ as operator. MySQL uses REGEXP as operator (not REGEXP MATCHES or MATCHES). MongoDB uses $regex: /.../. PostgreSQL and CouchDB also use the function name regexp_match(es) which is very similar to our syntax, but we use it as operator, not as function. Oracle uses regexp_like. The Redis SCAN command has a MATCH pattern clause, but with glob patterns. SQL also has the SIMILAR TO operator, but this is used with special SQL style regular expressions, not with the common POSIX ones. IBM RBD uses matches. Perl uses =~. JavaScript has the string.match(pattern) syntax, and RegExp as object name for regular expression patterns. So OP is right, REGEXP seems to be even more common than REGEX. Some languages like Python also name it just RE.

— Reply to this email directly, view it on GitHub <https://github.com/obsidian-tasks-group/obsidian- tasks/discussions/1143#discussioncomment-3674571>, or unsubscribe <https://github.com/notifications/unsubscribe- auth/AAACPADUB2MRMMGBXJNJUKTV64QIJANCNFSM6AAAAAAQMSS2FA>. You are receiving this because you authored the thread.Message ID: <obsidian-tasks-group/obsidian-tasks/repo- ***@***.***>

[Cito]

While I personally love the idea of description matches /<pattern> /, this risks breaking any users who already has a legitimate use for / in their tasks.

Hm, I don't see how this would be different from description regex matches /<pattern>/ which is the current syntax. Note that normal filters (not using regex) use the syntax description includes <string>. So matches would suffice to discern from the normal usage. Of course if you use a regex, you need to escape the slash. These two would be equivalent and would both work:

description includes someday/maybe
description matches /someday\/maybe/

[elight]

Brain fart. You're right.

On September 18, 2022, Vipercat ***@***.***> wrote: > While I personally love the idea of description matches /<pattern> > /, this risks breaking any users who already has a legitimate use > for / in their tasks. > Hm, I don't see how this would be different from description regex matches /<pattern>/ which is the current syntax. Note that normal filters (not using regex) use the syntax description includes <string>. So matches would suffice to discern from the normal usage. Of course if you use a regex, you need to escape the slash. These two would be equivalent and would both work: description includes someday/maybe description matches /someday\/maybe/

— Reply to this email directly, view it on GitHub <https://github.com/obsidian-tasks-group/obsidian- tasks/discussions/1143#discussioncomment-3675467>, or unsubscribe <https://github.com/notifications/unsubscribe- auth/AAACPAHP7IGXIYEU3LJMI23V65HBHANCNFSM6AAAAAAQMSS2FA>. You are receiving this because you authored the thread.Message ID: <obsidian-tasks-group/obsidian-tasks/repo- ***@***.***>