Feature request: Display URL to test the new rules

[izidormatusov]

My use case: I get an email or two that I would like to create a filter for. I update my configuration and run gmailctl diff / gmailctl apply, getting an output like this:

$ gmailctl diff
Filters:
--- Current
+++ TO BE APPLIED
@@ -1 +1,6 @@
+* Criteria:
+    from: noreply+spam@acme.com
+  Actions:
+    archive
+    apply label: n

Then I want to go and confirm that the new filter will match the emails. I love to test things, especially when the rule is complicated or includes special things like + in the email.

Testing involves copying the criteria into gmail search bar. It's bothersome if the rule is complicated (ANDs / ORs) and I need to partially rewrite the query, beating the purpose of testing in the first place.

Feature request: I would appreciate if the diff for each rule that is modified included gmail search link / direct search query for gmail. Such output is present already in the gmailctl debug output.

(I don't like using gmailctl debug for this purpose as it prints all rules out of which I need to find the new one).

The output could like:

--- Current
+++ TO BE APPLIED
@@ -1 +1,6 @@
+# Search: from:noreply+spam@acme.com
+# URL: https://mail.google.com/mail/u/0/#search/from%3Anoreply%2Bspam%40acme.com
+* Criteria:
+    from: noreply+spam@acme.com
+  Actions:
+    archive
+    apply label: n

When the filter would be modified, the output could look like this:

$ gmailctl diff
Filters:
--- Current
+++ TO BE APPLIED
@@ -1,6 +1,6 @@
 # Search: from:noreply+spam@acme.com
 # URL: https://mail.google.com/mail/u/0/#search/from%3Anoreply%2Bspam%40acme.com
 * Criteria:
     from: noreply+borgcron@google.com
   Actions:
     archive
-    apply label: n
+    apply label: nnn

I would be okay if the feature would be enabled only when a flag is present, something like --debug perhaps?

[mbrt]

Hi @izidormatusov, I think the idea makes sense. Just to make sure, you mention testing changes, but have you seen the built-in testing support? Tests run automatically during every change, so they should in theory be a better alternative to manual testing.

In terms of implementation, adding a comment on top of each filter is not easy, because the display is a unified diff. Adding the comment in both previous and next version of the filter would result in what you propose. However, this could also be cut out from the output with long filters when the criteria doesn't change (which I don't think is desirable). Also, when the criteria itself changes, you'd get a diff in the URL, which I'm not sure is very readable:

--- Current
+++ TO BE APPLIED
@@ -1,6 +1,6 @@
-# Search: from:noreply+foo@acme.com
-# URL: https://mail.google.com/mail/u/0/#search/from%3Anoreply%2Bfoo%40acme.com
+# Search: from:noreply+spam@acme.com
+# URL: https://mail.google.com/mail/u/0/#search/from%3Anoreply%2Bspam%40acme.com
 * Criteria:
-    from: noreply+foo@acme.com
+    from: noreply+spam@acme.com
   Actions:
     archive
-    apply label: n
+    apply label: nnn

Thoughts?

[izidormatusov]

Hi @mbrt , cool I didn't know about the built-in testing feature. If I understand it correctly, it is more like unit-testing: verify that the following actions would be applied on the email. I can see how that would be very useful to verify that the multiple rules are not fighting with each other (e.g. make sure that this email never gets archived).

However, that does not address my need. Sometimes I get the filter wrong (e.g. wondering why cron notifications are not matched by corn filter) or rely on more advanced features of gmail's search (e.g. does nobody@acme.com also match nobody+spam@acme.com?). If I verify the query once, I'm pretty certain that it works.

I see that the implementation is done line-wise, not character wise so the diff is unlikely to be split within the URL. I don't think the long lines are problem with regards the split: diff library should not hide part of the line if it is too long. Terminal should wrap the line and clicking on the link should work.

I agree, if the criteria is complicated (more than 5 lines, which is the current context for the diff), the search link would not be included. I personally care only about the search only when I modify the criteria. I would not test the filter search if I just apply the actions.

I see two possible implementations:

1. Print the search / url for added and removed filters. If the criteria changes, search/url is guaranteed to be changed as well and included in the diff.

2. Print the search / url for added filters only. This would display search / url even if the criteria is not modified and the diff is not cluttered by the old search / url info.

   I personally do not need the old search / url info but I can see how it can be useful when comparing the results of the old and the new query.

Sending #409 with an initial implementation