Snoozing a message in gnus?

[Rainer M Krug]

Hi

some mail clients (add on for notmuch [1] or Mailbox [2]) have an
interesting feature, namely snoozing messages, i.e. removing them
temporarily from the inbox and having them returned after / at a certain time.

This would make scheduling to deal with emails much easier.

I was wondering - is there something similar possible in GNUS?

Thanks,

Rainer


Footnotes:
[1] https://github.com/dschoepe/notmuch-snooze

[2] http://www.mailboxapp.com/about

[Eric Abrahamsen]

Post by Rainer M Krug
Hi
some mail clients (add on for notmuch [1] or Mailbox [2]) have an
interesting feature, namely snoozing messages, i.e. removing them
temporarily from the inbox and having them returned after / at a certain time.
This would make scheduling to deal with emails much easier.
I was wondering - is there something similar possible in GNUS?

I would just capture the message to an Org TODO, and then schedule the
TODO for some time in the future. Instant snooze!

[Ted Zlatanov]

Post by Rainer M Krug
some mail clients (add on for notmuch [1] or Mailbox [2]) have an
interesting feature, namely snoozing messages, i.e. removing them
temporarily from the inbox and having them returned after / at a certain time.
This would make scheduling to deal with emails much easier.
I was wondering - is there something similar possible in GNUS?

EA> I would just capture the message to an Org TODO, and then schedule the
EA> TODO for some time in the future. Instant snooze!

That's pretty cool. I want to offer that the Gnus registry could also
store this information, for those that don't use Org.

Ted

[Eric Abrahamsen]

Post by Ted Zlatanov

Post by Rainer M Krug
some mail clients (add on for notmuch [1] or Mailbox [2]) have an
interesting feature, namely snoozing messages, i.e. removing them
temporarily from the inbox and having them returned after / at a certain time.
This would make scheduling to deal with emails much easier.
I was wondering - is there something similar possible in GNUS?

EA> I would just capture the message to an Org TODO, and then schedule the
EA> TODO for some time in the future. Instant snooze!
That's pretty cool. I want to offer that the Gnus registry could also
store this information, for those that don't use Org.

FWIW, this is where I'm planning to take Gnorb[1]. Right now it store
correspondences between messages and Org TODOs using the registry, and
includes a dummy Gnus server for doing nnir searches. I'm planning on
fleshing out that server so that it has real groups: each group would
hold (virtual copies of) the messages associated with a certain Org
TODO. Each group would be created using the information stored in the
registry.

That way you could refresh these groups as you pleased, and see what
needed to be done for each TODO, or refresh the whole server and see
everything. Once I got to that point, it would be possible to make it
work even for people who aren't using Org: the "todo" information could
be solely stored in the registry.

Anyway, that's where that's headed.

Eric

[1]: https://github.com/girzel/gnorb

[Rainer M Krug]

Post by Eric Abrahamsen

Post by Rainer M Krug
Hi
some mail clients (add on for notmuch [1] or Mailbox [2]) have an
interesting feature, namely snoozing messages, i.e. removing them
temporarily from the inbox and having them returned after / at a certain time.
This would make scheduling to deal with emails much easier.
I was wondering - is there something similar possible in GNUS?

I would just capture the message to an Org TODO, and then schedule the
TODO for some time in the future. Instant snooze!

This is true - but then I have to check my TODO list regularly...

If the email would disappear from the inbox and reappear at a scheduled
time, I would more likely realize it.

Cheers,

Rainer

[Tassilo Horn]

Post by Rainer M Krug
some mail clients (add on for notmuch [1] or Mailbox [2]) have an
interesting feature, namely snoozing messages, i.e. removing them
temporarily from the inbox and having them returned after / at a certain time.
This would make scheduling to deal with emails much easier.
I was wondering - is there something similar possible in GNUS?

I don't think there is. But it shouldn't be too hard to implement
something like that, e.g., simply by marking snoozed articles as dormant
immediately (so that they won't be expired in the meantime), and then as
unread + ticked when the "wakeup time" has arrived.

BTW, I'm looking for something similar. I'd like to have a global group
that collects all articles I've ticked no matter which select method. I
tried a virtual group with the regex "^.*$" and group parameter (display
. [tick]), but that's not exactly what I want:

- It still contains all hundreds of unread messages (and gazillions of
read ones) because the `display' parameter is only limiting in the
summary buffer. That is, when I want to enter it, I'm queried how
many articles out of the existing millions I want to view. Even if
there is no unread article at all, I'm queried. At least in that
case I had expected to get quick access to all my ticked articles.

- It's dead slow. When exiting that group, it'll trigger expiry in
all contained groups which is just, well, all my groups.

Bye,
Tassilo

[Xavier Maillard]

Post by Tassilo Horn

Post by Rainer M Krug
some mail clients (add on for notmuch [1] or Mailbox [2]) have an
interesting feature, namely snoozing messages, i.e. removing them
temporarily from the inbox and having them returned after / at a certain time.
This would make scheduling to deal with emails much easier.
I was wondering - is there something similar possible in GNUS?

I don't think there is. But it shouldn't be too hard to implement
something like that, e.g., simply by marking snoozed articles as dormant
immediately (so that they won't be expired in the meantime), and then as
unread + ticked when the "wakeup time" has arrived.

I really like this approach ! Dead simple !

Xavier

[Trevor Murphy]

Post by Tassilo Horn
I don't think there is. But it shouldn't be too hard to
implement something like that, e.g., simply by marking snoozed
articles as dormant immediately (so that they won't be expired
in the meantime), and then as unread + ticked when the "wakeup
time" has arrived.

+1

Something similar's been on my "someday / maybe" project list for
a while now. On the off chance I have some free time this
weekend, a question for the list:

Is there an idiomatic way to implement this? I'm thinking of
writing two functions:
- first marks the article as dormant and adds a header like
X-Snooze-Until
- second goes in `gnus-select-group-hook' and maybe marks the
article unread + ticked if the header date is past

Thoughts?

[Peter Münster]

Post by Rainer M Krug
but then I have to check my TODO list regularly...

Or the org-notify.el package notifies you, when something is to do...

[Ted Zlatanov]

On Fri, 07 Nov 2014 10:37:05 -0500 Trevor Murphy <***@gmail.com> wrote:

TM> Is there an idiomatic way to implement this? I'm thinking of writing
TM> two functions:
TM> - first marks the article as dormant and adds a header like
TM> X-Snooze-Until
TM> - second goes in `gnus-select-group-hook' and maybe marks the article
TM> unread + ticked if the header date is past

You can't add a header to most backends, especially IMAP, because they
don't support article editing. The gnus-registry is pretty much the only
way inside Gnus (or you can use Org, as suggested) to add new metadata
like that. The rest seems OK.

Ted

[Adam Sjøgren]

Post by Ted Zlatanov
You can't add a header to most backends, especially IMAP, because they
don't support article editing.

How do you define "most"?

Isn't nnimap and the special ones (nnvirtual, nnir, nnmairix) the only
ones that don't?

nnmbox, nnbabyl, nnmh, nnmaildir, nnfolder, and nnml all do, right?


Nit picking, as ever,

Adam

[Rainer M Krug]

First of all, it is great to get this discussion on this topic.

Post by Adam Sjøgren

Post by Ted Zlatanov
You can't add a header to most backends, especially IMAP, because they
don't support article editing.

Snoozing should work on all (probably except nntp as it is read only?)
backends. But what about the approach which Mailbox is using,
i.e. moving the messages from the inbox into another folder (called "Later"?), and storing
metadata (which folder the message is from, when it is due, ...) in the
registry? The querying of the registry could be timed (every x minutes),
and when due, the message could be moved back to it's original location.

The advantage of this approach is that snoozed messages can also be
checked from other mail programs (I am thinking about an imap backend
for gmail), although only with missing information on due dates / times.

Cheers,

Rainer

Post by Adam Sjøgren
How do you define "most"?
Isn't nnimap and the special ones (nnvirtual, nnir, nnmairix) the only
ones that don't?
nnmbox, nnbabyl, nnmh, nnmaildir, nnfolder, and nnml all do, right?
Nit picking, as ever,
Adam

[Dan Christensen]

Post by Rainer M Krug
Snoozing should work on all (probably except nntp as it is read only?)
backends. But what about the approach which Mailbox is using,
i.e. moving the messages from the inbox into another folder (called "Later"?), and storing
metadata (which folder the message is from, when it is due, ...) in the
registry? The querying of the registry could be timed (every x minutes),
and when due, the message could be moved back to it's original location.
The advantage of this approach is that snoozed messages can also be
checked from other mail programs (I am thinking about an imap backend
for gmail), although only with missing information on due dates / times.

I like this idea, at least as an option, precisely so that the messages
would also appear "snoozed" when viewed with other IMAP clients (like
cell phones).

I also like the idea of storing the snooze information in a header when
possible. This *can* be done with nnimap, which can edit messages by
deleting the old one and creating a new one. And if you are already
copying the message to another folder, the header could be added at
the same time.

The registry has some auto-pruning features, which always makes me
worried about storing important information there.

Dan

[Ted Zlatanov]

On Tue, 11 Nov 2014 20:00:29 -0500 Dan Christensen <***@uwo.ca> wrote:

DC> The registry has some auto-pruning features, which always makes me
DC> worried about storing important information there.

Only for messages without useful metadata.

Ted

[Tassilo Horn]

Post by Ted Zlatanov
TM> Is there an idiomatic way to implement this? I'm thinking of writing
TM> - first marks the article as dormant and adds a header like
TM> X-Snooze-Until
TM> - second goes in `gnus-select-group-hook' and maybe marks the article
TM> unread + ticked if the header date is past
You can't add a header to most backends, especially IMAP, because they
don't support article editing. The gnus-registry is pretty much the only
way inside Gnus (or you can use Org, as suggested) to add new metadata
like that. The rest seems OK.

The problem with `gnus-select-group-hook' is that due articles would
become un-snoozed only when selecting the respective group. And why
should one select a group if it hasn't unread articles? So the
un-snoozing has to happen globally either periodically in a timer or at
least in `gnus-after-getting-new-news-hook'.

Bye,
Tassilo

[Ted Zlatanov]

On Mon, 10 Nov 2014 15:06:57 +0100 Tassilo Horn <***@gnu.org> wrote:

TH> The problem with `gnus-select-group-hook' is that due articles would
TH> become un-snoozed only when selecting the respective group. And why
TH> should one select a group if it hasn't unread articles? So the
TH> un-snoozing has to happen globally either periodically in a timer or at
TH> least in `gnus-after-getting-new-news-hook'.

Oh, good point. Yes. The registry could update those groups with a
glowing indicator light or something :)

Post by Ted Zlatanov
You can't add a header to most backends, especially IMAP, because they
don't support article editing.

AS> How do you define "most"?

AS> Isn't nnimap and the special ones (nnvirtual, nnir, nnmairix) the only
AS> ones that don't?

AS> nnmbox, nnbabyl, nnmh, nnmaildir, nnfolder, and nnml all do, right?

Yes. Sorry. I mean nntp and nnimap. I wrote too quickly.

AS> Nit picking, as ever,

WHAT!?!??! :)

On Mon, 10 Nov 2014 15:49:51 +0100 Rainer M Krug <***@krugs.de> wrote:

RMK> Snoozing should work on all (probably except nntp as it is read only?)
RMK> backends. But what about the approach which Mailbox is using,
RMK> i.e. moving the messages from the inbox into another folder (called "Later"?), and storing
RMK> metadata (which folder the message is from, when it is due, ...) in the
RMK> registry? The querying of the registry could be timed (every x minutes),
RMK> and when due, the message could be moved back to it's original location.

RMK> The advantage of this approach is that snoozed messages can also be
RMK> checked from other mail programs (I am thinking about an imap backend
RMK> for gmail), although only with missing information on due dates / times.

Erm, gmail is its own beast. I doubt we can influence its design. The
best we can do is work around it :)

But as far as moving messages, if Gnus supported Gmail's labels, we
could just apply a "Later" label to the message. It doesn't seem too
hard:
https://developers.google.com/gmail/imap_extensions#access_to_gmail_labels_x-gm-labels

Lars? Come on, it's a challenge! I'd actually find this useful for
removing the INBOX label from some messages. And making Gmail happy is
why we went into this in the first place, right?

Ted

[Trevor Murphy]

Post by Ted Zlatanov
But as far as moving messages, if Gnus supported Gmail's labels,
we could just apply a "Later" label to the message. It doesn't
https://developers.google.com/gmail/imap_extensions#access_to_gmail_labels_x-gm-labels

What features of Gmail labels are you missing? I add / remove
labels by copying / deleting messages from groups. If you create
a "Later" label in Gmail, and make sure it's exposed over IMAP (it
should be by default), does it not show up as an
"nnimap+Gmail:Later" group?

I found it a little frustrating that Google doesn't (can't?) make
a message's labels available as a header. So I hacked around in
`nnimap-header-parameters' to add the request and
`nnimap-transform-headers' to process it. Now I can ask for
X-GM-LABELS in `gnus-extra-headers' and do simple things like pull
them into summary lines with a user-format-function, filter my
inbox with limit-to-extra, etc.

Hmm. Maybe I should just send some patches to explain what I
mean.

[Ted Zlatanov]

Post by Ted Zlatanov
But as far as moving messages, if Gnus supported Gmail's labels, we
could just apply a "Later" label to the message. It doesn't seem too
https://developers.google.com/gmail/imap_extensions#access_to_gmail_labels_x-gm-labels

TM> What features of Gmail labels are you missing?

You can have more than one per message :)

Post by Ted Zlatanov
The registry could update those groups with a glowing indicator
light or something :)

TM> Whoa, I hadn't seen the registry before. That looks like a fairly
TM> heavyweight solution, but since it'll work with nnimap and nntp out of
TM> the box, I figure it's worth starting there.

TM> Looks like I want a command that marks the article dormant, prompts
TM> for a delay like how `gnus-delay-article' does, then sets an
TM> appropriate value under a registry "snooze" key.

TM> Then I'll throw something in the demon or the get-new-news hook to
TM> iterate over articles in the registry with a "snooze" key and mark
TM> them ticked + unread if the date is past.

TM> The manual says there's a built-in registry inverse map that'll let me
TM> look up all messages matching a particular set of criteria. Is this
TM> referring to `registry-search'? Or should I be trying to use
TM> `gnus-registry-find-keywords'?

registry.el is the generic DB, while gnus-registry.el uses it. So I
would use gnus-registry functions if possible, implementing new ones as
needed, to avoid unnecessary coupling to the underlying registry.el
implementation (which can and probably will change when we have FFI in
Emacs :)

Your plan seems good to me. Maybe you want to synchronize with Eric
Abrahamsen who was looking at fixing up some registry issues?

Ted

[Trevor Murphy]

The registry could update those groups with a glowing indicator
light or something :)

Whoa, I hadn't seen the registry before. That looks like a fairly
heavyweight solution, but since it'll work with nnimap and nntp
out of the box, I figure it's worth starting there.

Looks like I want a command that marks the article dormant,
prompts for a delay like how `gnus-delay-article' does, then sets
an appropriate value under a registry "snooze" key.

Then I'll throw something in the demon or the get-new-news hook to
iterate over articles in the registry with a "snooze" key and mark
them ticked + unread if the date is past.

The manual says there's a built-in registry inverse map that'll
let me look up all messages matching a particular set of criteria.
Is this referring to `registry-search'? Or should I be trying to
use `gnus-registry-find-keywords'?

[Eric Abrahamsen]

Post by Trevor Murphy

The registry could update those groups with a glowing indicator
light or something :)

Whoa, I hadn't seen the registry before. That looks like a fairly
heavyweight solution, but since it'll work with nnimap and nntp out of
the box, I figure it's worth starting there.
Looks like I want a command that marks the article dormant, prompts
for a delay like how `gnus-delay-article' does, then sets an
appropriate value under a registry "snooze" key.
Then I'll throw something in the demon or the get-new-news hook to
iterate over articles in the registry with a "snooze" key and mark
them ticked + unread if the date is past.
The manual says there's a built-in registry inverse map that'll let me
look up all messages matching a particular set of criteria. Is this
referring to `registry-search'? Or should I be trying to use
`gnus-registry-find-keywords'?

Keywords are specifically used for adaptive word scoring;
`registry-search' is the one you want for finding arbitrary keys.

[Trevor Murphy]

Post by Tassilo Horn
The problem with `gnus-select-group-hook' is that due articles
would become un-snoozed only when selecting the respective
group. And why should one select a group if it hasn't unread
articles? So the un-snoozing has to happen globally either
periodically in a timer or at least in
`gnus-after-getting-new-news-hook'.

Yes, this makes sense. Thanks.

[Lars Ingebrigtsen]

Post by Rainer M Krug
some mail clients (add on for notmuch [1] or Mailbox [2]) have an
interesting feature, namely snoozing messages, i.e. removing them
temporarily from the inbox and having them returned after / at a certain time.
This would make scheduling to deal with emails much easier.
I was wondering - is there something similar possible in GNUS?

I don't think Gnus has a way of making them return later automatically,
but I just mark messages as dormant with the `?' command, and `/ w' when
I want to see them again...

[Rainer M Krug]

Post by Lars Ingebrigtsen

Post by Rainer M Krug
some mail clients (add on for notmuch [1] or Mailbox [2]) have an
interesting feature, namely snoozing messages, i.e. removing them
temporarily from the inbox and having them returned after / at a certain time.
This would make scheduling to deal with emails much easier.
I was wondering - is there something similar possible in GNUS?

I don't think Gnus has a way of making them return later automatically,
but I just mark messages as dormant with the `?' command, and `/ w' when
I want to see them again...

Interesting - didn't know the `?' command.

If one now could supply a time at which the mail should be un-marked as
being dormant...

Thanks,

Rainer

[Lars Ingebrigtsen]

Post by Rainer M Krug
Interesting - didn't know the `?' command.
If one now could supply a time at which the mail should be un-marked as
being dormant...

The dormant list doesn't store the time the message was made dormant,
but I guess one could store that information somewhere. If somebody
wanted to implement this. :-)

[Eric Abrahamsen]

Post by Lars Ingebrigtsen

Post by Rainer M Krug
Interesting - didn't know the `?' command.
If one now could supply a time at which the mail should be un-marked as
being dormant...

The dormant list doesn't store the time the message was made dormant,
but I guess one could store that information somewhere. If somebody
wanted to implement this. :-)

Ted mentioned the registry...

[Rainer M Krug]

Post by Eric Abrahamsen

Post by Lars Ingebrigtsen

Post by Rainer M Krug
Interesting - didn't know the `?' command.
If one now could supply a time at which the mail should be un-marked as
being dormant...

The dormant list doesn't store the time the message was made dormant,
but I guess one could store that information somewhere. If somebody
wanted to implement this. :-)

Ted mentioned the registry...

Unfortunately I lack elisp knowledge as well as the time at the moment
to look at it.

Anyway - I think it would be a "nice to have" feature but no essential
addition.
Cheers,

Rainer