Re: Scheduling mails
Hi there, > I might be wrong, but I don't think the Gnus agent can be easily reused > from notmuch. We could perhaps save the message as a draft upon C-c C-j, > and then have a periodic timer that checks if any of the drafts has > expired (maybe using a special, additional tag for the search) and send > it? I have solved this myself using `gnus-delay-article` as a basis. I am attaching here my current code, it is my intention to (time permitting) turn this over a patch for inclusion into notmuch itself. What is preventing such patch right now: - Writting tests, - I'm trying to find something like `killing-new-buffers` builtin but will probably just include the code. A side of the attached file you will need the `killing-new-buffers` macro, pasted below. (defmacro killing-new-buffers ( body) "Run BODY and kill any buffers that were not already open." (declare (debug t)) (cl-with-gensyms (initial-buffers) `(let ((,initial-buffers (buffer-list))) (unwind-protect ,(macroexp-progn body) (dolist (b (buffer-list)) (unless (memq b ,initial-buffers) (kill-buffer b))) Hope this helps, marc notmuch-delay.el Description: application/emacs-lisp ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Scheduling mails
Hi there, > I might be wrong, but I don't think the Gnus agent can be easily reused > from notmuch. We could perhaps save the message as a draft upon C-c C-j, > and then have a periodic timer that checks if any of the drafts has > expired (maybe using a special, additional tag for the search) and send > it? I have solved this myself using `gnus-delay-article` as a basis. I am attaching here my current code, it is my intention to (time permitting) turn this over a patch for inclusion into notmuch itself. What is preventing such patch right now: - Writting tests, - I'm trying to find something like `killing-new-buffers` builtin but will probably just include the code. A side of the attached file you will need the `killing-new-buffers` macro, pasted below. (defmacro killing-new-buffers ( body) "Run BODY and kill any buffers that were not already open." (declare (debug t)) (cl-with-gensyms (initial-buffers) `(let ((,initial-buffers (buffer-list))) (unwind-protect ,(macroexp-progn body) (dolist (b (buffer-list)) (unless (memq b ,initial-buffers) (kill-buffer b))) Hope this helps, marc notmuch-delay.el Description: application/emacs-lisp ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Scheduling mails
João Pedro writes: > Ah, indeed message properties seem to be more appropriate. Are they > persisted, or are they tied to an Emacs session? They are persisted in the database, and backed up with notmuch dump. > >> but your periodic search would still have to search for all of the >> scheduled=time properties (wildcard search is currently only supported >> using s-exp queries). > > How about having a list of '(MESSAGE-ID . SCHEDULED-TIME), with the > periodic check looking in that list for the scheduled times? It would > have the issue of it not being persistent between Emacs sessions, but I > think that could be addressed by letting the users know this lack of > persistance, and documenting how you could achieve it with > `savehist-additional-variables'. One advantage of doing it outside emacs (in the notmuch database) is that you could have the delivery also managed outside emacs. So cron / systemd-timer / whatever. I guess the downside is it might be more work to prototype. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Scheduling mails
Em quarta, 03/04/2024 às 07:06 (-03), David Bremner escreveu: > Message properties might work a bit better than tags Ah, indeed message properties seem to be more appropriate. Are they persisted, or are they tied to an Emacs session? Because I would like to have it so that even if I kill my Emacs session and open a new one, if the message has the `:scheduled' property with the right time, it should be sent. There's also concerns on what to do when Emacs was not up when the scheduled time arrived. Do we 1. send it immediately? or 2. inform the user it was not able to deliver the message? Going with the latter has the caveat that it might be missed by the user, and one would be clueless to the fact that their message hadn't arrived. > but your periodic search would still have to search for all of the > scheduled=time properties (wildcard search is currently only supported > using s-exp queries). How about having a list of '(MESSAGE-ID . SCHEDULED-TIME), with the periodic check looking in that list for the scheduled times? It would have the issue of it not being persistent between Emacs sessions, but I think that could be addressed by letting the users know this lack of persistance, and documenting how you could achieve it with `savehist-additional-variables'. > I would suggest having a look at the existing draft handling, as what > you describe sounds like it is related. Taking a quick glance at it, it seems like we could have a similar thing, where scheduled messages are saved to the database somewhere, with either the tag, as it is with drafts, or just the message property as you suggested. -- João Pedro de A. Paula IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN) ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Scheduling mails
João Pedro writes: > Em terça, 02/04/2024 às 02:05 (+01), Jose A Ortega Ruiz > escreveu: > >> I might be wrong, but I don't think the Gnus agent can be easily reused >> from notmuch. We could perhaps save the message as a draft upon C-c C-j, >> and then have a periodic timer that checks if any of the drafts has >> expired (maybe using a special, additional tag for the search) and send >> it? > > I think we should be able to use a similar logic to > `gnus-delay-article': it adds an X-Gnus-Delayed header with a timestamp > and seems to, as you proposed, periodically check for scheduled > messages. The header holds a timestamp for the prompted scheduled time > (which can be given in as an absolute date, or relative to the current > time) and we could add to that a `scheduled' tag or something along > those lines. Message properties might work a bit better than tags, but your periodic search would still have to search for all of the scheduled=time properties (wildcard search is currently only supported using s-exp queries). I would suggest having a look at the existing draft handling, as what you describe sounds like it is related. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Scheduling mails
Em terça, 02/04/2024 às 02:05 (+01), Jose A Ortega Ruiz escreveu: > I might be wrong, but I don't think the Gnus agent can be easily reused > from notmuch. We could perhaps save the message as a draft upon C-c C-j, > and then have a periodic timer that checks if any of the drafts has > expired (maybe using a special, additional tag for the search) and send > it? I think we should be able to use a similar logic to `gnus-delay-article': it adds an X-Gnus-Delayed header with a timestamp and seems to, as you proposed, periodically check for scheduled messages. The header holds a timestamp for the prompted scheduled time (which can be given in as an absolute date, or relative to the current time) and we could add to that a `scheduled' tag or something along those lines. -- João Pedro de A. Paula IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN) ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Scheduling mails
Hi, On Mon, Apr 01 2024, João Pedro wrote: > I am using notmuch in Emacs, with mbsync and msmtp (I actually use > smtpmail.el in Emacs, but it uses the `sendmail' command, which is > symlinked to msmtp) and the only thing I miss from other mail clients > is the ability to schedule a mail to be sent on a certain time. I do > also use `message-mode' to compose my emails, and it has > `gnus-delay-article' bound to C-c C-j, which at first sight seems to > be exactly what I need. The problem is, when calling it from > =notmuch-message-mode= I get a `wrong-type-argument' from the first > line of `gnus-agent-queue-setup', I might be wrong, but I don't think the Gnus agent can be easily reused from notmuch. We could perhaps save the message as a draft upon C-c C-j, and then have a periodic timer that checks if any of the drafts has expired (maybe using a special, additional tag for the search) and send it? Sounds doable, but maybe there's an easier way: what do more knowleadgeble people think? Cheers, jao -- Dealing with failure is easy: Work hard to improve. Success is also easy to handle: You've solved the wrong problem. Work hard to improve. - Alan Perlis, Epigrams on Programming ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Scheduling mails
Hi there, This might not be the best mailing list to ask this, but I figured I could at least be given some directions. I am using notmuch in Emacs, with mbsync and msmtp (I actually use smtpmail.el in Emacs, but it uses the `sendmail' command, which is symlinked to msmtp) and the only thing I miss from other mail clients is the ability to schedule a mail to be sent on a certain time. I do also use `message-mode' to compose my emails, and it has `gnus-delay-article' bound to C-c C-j, which at first sight seems to be exactly what I need. The problem is, when calling it from =notmuch-message-mode= I get a `wrong-type-argument' from the first line of `gnus-agent-queue-setup', which tries to get a value from a hash table stored in a variable that is initialized with nil. Gnus must initialize this variable with some sort of hash table, but I could not emulate this behaviour to make this scheduling work. Is it possible to use `message-mode''s scheduling facility with notmuch? Cheers, -- João Pedro de A. Paula IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN) ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
