Re: Preferred way to get imap emails
On Tue, Jul 30, 2019 at 02:57:26PM -0500, Derek Martin wrote: > Joining any community requires to at least some extent that you gain > that community's trust. Your posts thusfar have not earned you that. > May be over time, I'll gain it. :-) all well now. -- Pankaj Planet Earth. "" A nasty looking dwarf throws a knife at you. signature.asc Description: PGP signature
Re: Preferred way to get imap emails
On Tue, Jul 30, 2019 at 02:52:27PM -0500, Derek Martin wrote: > > Honestly speaking, I have tried a couple of tools - offlineimap, mbsync > > and fetchmail. All are flawed. > > I don't know what you think the flaws are with this, but I can say > that I use fetchmail + procmail for this purpose myself at work for > reasons I won't get into here. I've been doing it for many years, > and find it to have no particular flaws. Together these tools are > extremely powerful and very flexible. It may just be that you have > not yet discovered how best to use such tools to accomplish your > goals and need to spend a bit more time learning them. This could be a probability. It is just 2 weeks that I have restarted using these tools again after ~20 years. 'mbsync' wasn't there at that time. But it is working Okay as of now. Sometimes the sync fails. I am discussing those issue in their mailing list. Thanks for your detailed reply, Derek. -- Pankaj Planet Earth. "" There's nothing disgusting about it [the Companion]. It's just another life form, that's all. You get used to those things. -- McCoy, "Metamorphosis", stardate 3219.8 signature.asc Description: PGP signature
Re: Preferred way to get imap emails
On Tue, Jul 30, 2019 at 03:00:32AM +0530, Pankaj Jangid wrote: > On Mon, Jul 29, 2019 at 01:50:54PM -0700, Kevin J. McCarthy wrote: > > If you want to participate in development, then please do so by starting > > small and showing me I can trust your patches. After you've done that, we > > can talk about larger changes. > > > This is really encouraging. But to be very clear, it is not meant to be. You came in saying you want Mutt to handle a protocol in a way that is expressly against the way that protocol is intended to be used, by adding features to Mutt which are counter to its design philosophy. You should not expect encouragment for that. Joining any community requires to at least some extent that you gain that community's trust. Your posts thusfar have not earned you that. -- 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. pgpanUGB_PAap.pgp Description: PGP signature
Re: Preferred way to get imap emails
On Tue, Jul 30, 2019 at 01:47:35AM +0530, Pankaj Jangid wrote: > On Mon, Jul 29, 2019 at 03:13:37PM -0400, Dan Ritter wrote: > > IMAP is, explicitly, a mail protocol for clients to do the > > minimal amount of fetching necessary. You can do a full sync on > > top of it, but that's not what it's there for. > > A lot has changed since then. I remember I used to pop everything > because the mailserver quota was less than 10mb (20 years back). And > then take backup of local emails on floppy drives. > > Now we check emails on mobiles, browser and obviously *mutt*. There must > be some inclusive intuitive changes now. But none of this really affects how IMAP works, or should work. If anything, it's a recommendation for using IMAP as intended. As far as I can tell, your whole motivation is to avoid a bit of latency as each message is downloaded for display, by downloading all the messages ahead of time (and I guess storing them in some local cache? Or something)... But that's sort of the antithesis of IMAP, as Dan indicated. It requires a potentially lengthy wait while all of the relevant message bodies are downloaded, which IMAP was expressly designed to avoid. As I said already, if you're on a fast, low-latency connection to your IMAP server, generally you won't notice this latency, and this is probably the case for the vast majority of e-mail users (who typically are using IMAP at work, or at home, on a local LAN, OR to their ISP's servers, over a fast broadband connection on the same network). So I conclude that is not your situation. If you're not in that situation, there are already solutions available to you: 1. Fetch the messages yourself and read them locally. Fetchmail and mbsync were both designed for exactly this. 2. Accept that the latency is just something you have to deal with. 3. Investigate an alternative provider with whom you have a better connection. > Honestly speaking, I have tried a couple of tools - offlineimap, mbsync > and fetchmail. All are flawed. I don't know what you think the flaws are with this, but I can say that I use fetchmail + procmail for this purpose myself at work for reasons I won't get into here. I've been doing it for many years, and find it to have no particular flaws. Together these tools are extremely powerful and very flexible. It may just be that you have not yet discovered how best to use such tools to accomplish your goals and need to spend a bit more time learning them. There's no need for Mutt to do this, and it's rather against its design philosophy. Given that, I wouldn't guess you'd have much luck getting such a feature accepted by the Mutt development community, particularly since the primary maintainer has already basically said so. That said, I haven't used Mutt's IMAP functionality myself in many years, and it has been completely rewritten since then. It could be the case that it might be possible to optimize the way Mutt handles the fetch and display of the message, such that it only reads enough of the message to fill up the display window, and then continues reading the rest of the message. But for all I know it already does that. And of course in cases where the message is encoded in such a way that reading the whole message is required to decode any of it (I'm thinking encryption, for example), such an optimization will not work. Surely Kevin would know and could comment further. [My understanding is that it is technically possible to decrypt messages encoded with asymmetric encryption in pieces, but neither GnuPG nor OpenSSL do this, and Mutt's behavior is dependent on theirs.] -- 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. pgpeDOsO3IxVD.pgp Description: PGP signature
Re: Unsubscribing from mailing-list threads (was: Preferred way to get imap emails)
On 2019-07-30, José María Mateos wrote: > On Tue, Jul 30, 2019 at 10:08:02AM -0400, Mark H. Wood wrote: > >> You may want to examine some netnews clients for ideas. They tend to >> have exactly this: a database of killed threads, easily augmented with >> a simple keystroke. > > This. Having used slrn in the past, I was surprised mutt didn't have > some kind of killfile mechanism readily available (or, if it's > available, I have completely missed it). That's one of the reasons I use slrn rather than mutt for following mailing lists (including this one). -- Grant Edwards grant.b.edwardsYow! Quick, sing me the at BUDAPEST NATIONAL ANTHEM!! gmail.com
Re: Unsubscribing from mailing-list threads (was: Preferred way to get imap emails)
On Tue, Jul 30, 2019 at 10:08:02AM -0400, Mark H. Wood wrote: > You may want to examine some netnews clients for ideas. They tend to > have exactly this: a database of killed threads, easily augmented with > a simple keystroke. This. Having used slrn in the past, I was surprised mutt didn't have some kind of killfile mechanism readily available (or, if it's available, I have completely missed it). Cheers, -- José María (Chema) Mateos || https://rinzewind.org/
Re: Unsubscribing from mailing-list threads (was: Preferred way to get imap emails)
On Tue, Jul 30, 2019 at 07:40:02AM +0200, Matthias Apitz wrote: > El día martes, julio 30, 2019 a las 06:36:35a. m. +0200, Francesco Ariis > escribió: > > > On Tue, Jul 30, 2019 at 06:31:42AM +0200, Matthias Apitz wrote: > > > > > > I'm a mutt user for many years. From time to time I do miss a feature in > > > mutt to mark a given thread as "do not present any mail of this thread > > > anymore, just collapse them and mark for deletion on exit". > > > > > > This is such a thread I would mark as this. > > > > Maybe this link can be of interest > > > > http://ariis.it/static/articles/mutt-ml/page.html > > Thanks for this pointer. The doc describes exactly the problem. But, the > proposed solution with a macro deleting threads which follow the rule > (copied from the doc): > > "Threads with only replies means threads where the originating post > isn’t present; if it is not present is because we deleted it; if we > deleted it we didn’t like it and we don’t want replies to it, too." > > is not good. Sometimes (many times) I have saved the original post of a > "good" thread in some place, for example into the mbox file ~/Mail/mutt and > so the > above pattern would touch/delete a "good" thread also as a "bad" one. > > A solution must be based on some kind of a local "database" file of threads > marked as > "bad" threads (perhaps as patterns) and one must actively store the given > "bad" thread into it, for example with M and then a D would > later, even in the next mutt session, read this "database" file and delete > all threads from the actual mailbox for all patterns in it. You may want to examine some netnews clients for ideas. They tend to have exactly this: a database of killed threads, easily augmented with a simple keystroke. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu signature.asc Description: PGP signature
Re: Preferred way to get imap emails
On Tue, Jul 30, 2019 at 03:05:15PM +0200, Marcus C. Gottwald wrote: > Fetch them as soon as new mail becomes visible or once after entering > a folder? Maybe the latter can get achieved using a folder-hook (or a > manually executed key press) triggering the execution of a macro along > the lines of: > >~N ~z <10K ~b whatever >all > > > The idea is that Mutt will need to look at the email bodies (~b) and > will have to fetch them in order to be able to look at them. I am surprized at the remarkable ways in which *mutt* can be configured. Great answer. Thanks. I'll try this and report. Regards. -- Pankaj Planet Earth. "" The light at the end of the tunnel is the headlight of an approaching train. signature.asc Description: PGP signature
Re: Preferred way to get imap emails
Pankaj Jangid wrote (Sat 2019-Jul-27 20:58:20 +0530): > My 2nd question is - is there a way to pre-fetch all the emails in inbox. Fetch them as soon as new mail becomes visible or once after entering a folder? Maybe the latter can get achieved using a folder-hook (or a manually executed key press) triggering the execution of a macro along the lines of: ~N ~z <10K ~b whatever all The idea is that Mutt will need to look at the email bodies (~b) and will have to fetch them in order to be able to look at them. Cheers, Marcus -- Marcus C. Gottwald ·· https://cheers.de
Re: Unsubscribing from mailing-list threads (was: Preferred way to get imap emails)
On Jul 30, 2019 at 7:40, Matthias Apitz wrote: A solution must be based on some kind of a local "database" file of threads marked as "bad" threads (perhaps as patterns) and one must actively store the given "bad" thread into it, for example with M and then a D would later, even in the next mutt session, read this "database" file and delete all threads from the actual mailbox for all patterns in it. Would it be possible to keep this information in the email by, say, adding a header to it. And have mutt mark any message whose parent contains this header as read. Something like this as a macro or hook (untested): ~h X-Mark-Thread-Read\n An external tool can probably add the header if mutt can't do it. One could also (ab)use the spam detection mechanism spam "X-Mark-Thread-Read" "100/NotInterested" I'm reading this out of the NeoMutt manual, I suppose Mutt has similar functionality. I Cc'ed the author of the article: fa...@ariis.it Please keep him/her in Cc when you reply. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub signature.asc Description: PGP signature
