There are quite a few ways to handle e-mail clients. My favorite working environment is the command line and several times I have attempted to switch to @mutt@ as my e-mail client. But whenever doing so I always seemed to lose the configuration one way or the other. But like re-installing Gentoo over and over, with practice it gets easier. The Arch Linux wiki has a looong article on "using mutt":https://wiki.archlinux.org/index.php/mutt#IMAP that I should probably get through some time. I also found a "forum thread":https://bbs.archlinux.org/viewtopic.php?pid=293494 on setting up mutt, which I followed and seems to work. The only problem with the setup is that whenever I open mutt, the _entire_ inbox is downloaded--and it has over 11000 e-mails. Clearly some sort of caching is required in which I keep a local copy of the inbox. My dream configuration would involve some sort of notification system, in which GMail somehow would invoke a kind of callback function to notify my e-mail retriever of new e-mails. So instead of periodically pulling information, it would be pushed to me. I much prefer this "lazy" form of communication, as I tend to believe it has less overhead. But it is also more difficult to implement, and in the case of a GMail server invoking a callback function to contact my laptop, it might not be feasible. So rather polling at regular intervals could be used. Pulling e-mails shouldn't just happen once every fifteen minutes or so, rather it should be an adaptive algorithm that attempts to query more often when the likelihood of receiving e-mails is greater. One adaptive approach could be a learning algorithm analysing high traffic times based on already received e-mails. This would require some advanced filtering to sort out e-mails such as newsletters, spam and advertisements. Rather you want to focus on personal e-mails or e-mails with a small group of recipients. Such an algorithm could also be real-time adaptive, say you receive an e-mail an respond immediately, it should attempt to keep the conversation "alive", and if the exchange turns into a chat, the polling algorithm should not delay it because it only polls every 2 minutes.