Solve relative baseline problem by converting/renaming labels

lehrblogger commented 8 years ago

Do not merge this yet. I'm not quite done, but wanted to make the PR now and get feedback sooner rather than later. It might be a bit easier to look commit-by-commit.

The general idea, as described in https://github.com/rosulek/gmail-tickler/issues/6#issuecomment-173088998, is to use the script's runtime as the baseline and convert/rename all tickler labels so that they fully specify the intended timestamp.

A few things still to do:

[x] More efficient application/removal of labels. This might be a bit tricky, but the script probably should not be removing and re-applying the same labels to every non-untickled thread every time it runs. (I hit the quota yesterday afternoon, possibly because of testing, but it would still be better to have some room to breath. I suspect the Gmail API calls are the slowest part.)
[ ] Add configuration options for the format of the absolute timestamp labels.
[ ] Maybe improve handling of ambiguous cases when the script runs very close to the interpreted time of a non-absolute label, possibly using the FUDGE_FACTOR and/or considering these cases as errors.
[ ] Consider how this interacts with email-based tickling. Should this whole strategy be optional?
[ ] Update the readme.

lehrblogger commented 8 years ago

The last commit there seems to have fixed the issues I was having with the quota. There's still more consolidation of Gmail API calls that could be done if necessary, but this is a good start.

lehrblogger commented 8 years ago

I've been using this for a few weeks now and it's been wonderful, to the point where I think I'm now happier with the Tickler than I was with Mailbox. @rosulek, any comments on the above or my implementation before I return to the remaining todos?

rosulek commented 8 years ago

That is great to hear. Honestly I haven't had a good chance to look over your changes thoroughly.

I did look briefly though, and did have at least one thought. It would be cool if these "script-generated" labels were sorting-friendly, perhaps something along the lines of tickler/YYYY/mm/dd/hhmm. That way it would be easy to identify the emails you've tickled to a particular month, for example. Perhaps the "user-generated" labels and "script-generated" labels could have different namespaces (like tickler/tomorrow vs tickler/internal/2016/05/26/0800). Just thinking out loud here.

lehrblogger commented 8 years ago

Thanks for the suggestion. I can make the script-generated labels sorting-friendly by default, but there is perhaps a tradeoff between sortability and legibility – in most cases, the year is the least interesting part of the date.

Using a separate namespace is an interesting idea too. Right now the branch converts user-generated labels into script-generated labels every time it runs, so at any given moment all of the labels are likely to be script-generated. Emails can, after all, have multiple labels, so perhaps there could be additional convenience-only, script-generated labels in a separate namespace that were optimized for legibility, perhaps without years? But I'm not sure that's worth the clutter/complexity.

I did notice an off-by-one bug at the end of March in which tickled emails were getting scheduled for the beginning of May rather than the beginning of April. Just making a note here to investigate when I have a chance.

lehrblogger commented 8 years ago

I noticed the off-by-one bug again at the end of May. I think what happened is that I had a couple of labels for times in June, but on June 1st, they got changed to the corresponding day/time in the next month, July.

I've also been experimenting with Gmail filters that automatically apply the tickler/7am to a thread every time a matching email shows up in the inbox, since sometimes I'm on noisy threads that I want to ignore completely until a certain time of day. To facilitate this I hope to make the script a bit smarter about conflict detection, so that multiple time/date reasons are permitted if they specify the same timestamp. Then a shorthand label such as tickler/7am would not conflict with a fully-specified label such as tickler/2016/06/08/0700 if the shorthand label was processed at 8am on June 7th.

I have a bit more travel coming up, but then hopefully can wrap this up...

lehrblogger commented 7 years ago

I'm going to close this PR since @rosulek has already finished his implementation over in https://github.com/rosulek/gmail-tickler/issues/6.

rosulek / gmail-tickler

Solve relative baseline problem by converting/renaming labels #14