Re: Send mail in background with built-in SMTP client?
El día Thursday, April 14, 2016 a las 07:59:56PM -0700, Claus Assmann escribió: > On Thu, Apr 14, 2016, Xu Wang wrote: > > > I use mutt's built-in SMTP client. I would like to press 'y' and > > immediately be able to move on to my next email without waiting. I > > Did you check the fine manual? > > 3.234. sendmail_wait > > ... I understand this config value for the $sendmail proc, as the man page also explains. Does this really also affect the built-in SMTP client functionality? matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 ¡Dios querido denos otra vez los problemas de ayer, los que tuvimos en la RDA! My Lord, give us back the problems of yesterday, those we have had in the GDR.
Re: Send mail in background with built-in SMTP client?
On Thu, Apr 14, 2016 at 10:59 PM, Claus Assmann wrote: > On Thu, Apr 14, 2016, Xu Wang wrote: > >> I use mutt's built-in SMTP client. I would like to press 'y' and >> immediately be able to move on to my next email without waiting. I > > Did you check the fine manual? > > 3.234. sendmail_wait > > Type: number > Default: 0 > > Specifies the number of seconds to wait for the $sendmail process to finish > before giving up and putting delivery in the background. > > Mutt interprets the value of this variable as follows: > > +-+ > |>0|number of seconds to wait for sendmail to finish before continuing| > |--+--| > |0 |wait forever for sendmail to finish | > |--+--| > |<0|always put sendmail in the background without waiting | > +-+ > > Note that if you specify a value other than 0, the output of the child process > will be put in a temporary file. If there is some error, you will be informed > as to where to find the output. > Thank you very much Claus. I did not check manual (I have read it two times all the way through before, but I forget details). Thank you for walking me through it and getting started. For more details I will read manual. Kind regards! Xu
Re: Send mail in background with built-in SMTP client?
On Thu, Apr 14, 2016, Xu Wang wrote: > I use mutt's built-in SMTP client. I would like to press 'y' and > immediately be able to move on to my next email without waiting. I Did you check the fine manual? 3.234. sendmail_wait Type: number Default: 0 Specifies the number of seconds to wait for the $sendmail process to finish before giving up and putting delivery in the background. Mutt interprets the value of this variable as follows: +-+ |>0|number of seconds to wait for sendmail to finish before continuing| |--+--| |0 |wait forever for sendmail to finish | |--+--| |<0|always put sendmail in the background without waiting | +-+ Note that if you specify a value other than 0, the output of the child process will be put in a temporary file. If there is some error, you will be informed as to where to find the output.
Send mail in background with built-in SMTP client?
Dear all, I use mutt's built-in SMTP client. I would like to press 'y' and immediately be able to move on to my next email without waiting. I understand why it is important to wait---if the email send failed, then it is important for you to know that. But is it possible to be notified of a failed email in another way instead of having to wait? Kind regards, Xu
Re: How do you survive without notmuch?
On Wed, Apr 13, 2016 at 04:30:27PM -0700, Will Yardley wrote: > I'm not as much worried about bloat, especially if it's an optional > feature, but it seems like something that would be fairly difficult to > implement in a way that is both fast and useful. > > For me, the bigger areas where I find Mutt limiting are things like > responding to Exchange / Gcal invites (though mostly just use Apple > products for this now), not being able to view images inline, etc. Given > how much less email is used these days (relative to text message, > Facebook messaging, online forums / FB groups, Slack, etc.), the emails > I *do* still get tend to be weighted more heavily in this direction than > they used to be. That said, I still much prefer Mutt over GUI MUAs. I agree with all these points. I'd like to see Mutt additionally have functionality to address all of these, plus the ability to easily add new mail store types via a unified mailbox driver API. It's obviously possible, but I suspect that to make it maintainable would require rewriting a lot of the core of Mutt. IIRC there's a terminal-based web browser that has the ability to display web pages, including images, in your terminal window--though it may require the use of some specific terminal program, I can't recall. So even better HTML mail support should be doable in Mutt without making it a GUI... But I would frankly like to see a GUI option as well; I think it would be great if Mutt could switch back and forth and have a relatively consistent UI in both cases. It's totally doable. This is the kind of stuff that a modern mailer is expected to have... -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgp940ocAjQiS.pgp Description: PGP signature
Re: Mark threads as read for the future
On Thu, Apr 14, 2016 at 05:47:48PM +0200, Andreas Doll wrote: > Hello > > I'm using mutt in conjunction with offlineimap to filter mailinglists into > separate folders. Usually I decide quickly if I'm interested in a thread or > not - if not I press Ctrl-r to mark this thread as read and move on. > > The "problem" with this is, that subsequent replies to this thread will marked > as new again. Is there a way (flagging?) such that subsequent replies to this > thread will be marked also as read, maybe utilizing offlineimap (which is able > to mark mails as read)? Hey Andreas, I wrote a small folder-hook pattern which accomplishes a similar task (deletes instead 'mark as read') [1]. I suspect it can be modified to suit your needs (tag-pattern + tag-prefix maybe?). Fire again if you need help [1] http://ariis.it/static/articles/mutt-ml/page.html
Mark threads as read for the future
Hello I'm using mutt in conjunction with offlineimap to filter mailinglists into separate folders. Usually I decide quickly if I'm interested in a thread or not - if not I press Ctrl-r to mark this thread as read and move on. The "problem" with this is, that subsequent replies to this thread will marked as new again. Is there a way (flagging?) such that subsequent replies to this thread will be marked also as read, maybe utilizing offlineimap (which is able to mark mails as read)? Thanks! Best regards, Andreas
