Re: unified inbox
On Sun, Feb 27, 2011 at 08:08:49PM -0600, Derek Martin wrote: > On Sat, Feb 26, 2011 at 08:32:25PM +0100, Joost Kremers wrote: > > On Sat, Feb 26, 2011 at 01:29:21PM -0500, Logan Rathbone wrote: > > > On Thu, Feb 24, 2011 at 02:34:43PM -0600, Puneet Kishor wrote: > > > > So, since nothing is impossible in mutt, how can I get a unified inbox > > > > for my two accounts? > > > > > > I don't think having a specific feature in Mutt is necessary or > > > desirable to achieve this. You can easily have mail from multiple > > > accounts delivered to your mailspool using getmail or fetchmail. > > > > except that that downloads the mail to your local machine. > > Not if you run it on your IMAP server. but it still puts all your mail into a single mail box, which entirely defeats the purpose of a unified inbox. > > mutt is really a one-mail-account kind of mail client. > > That's amusing... I've been using it with multiple accounts for over a > decade. so have i, but you need to resort to some trickery to do that. either by defining macros to change account info (server, username/password), or by collecting the mail into a single mailbox, or (like me) by running multiple instances of mutt within screen/tmux or in different tabs of one's terminal emulator. it's certainly not as simple as: set imap_user[1] = "f...@bar.com" set imap_pass[1] = "baz" set imap_user[2] = "f...@buz.com" set imap_pass[2] = "baz2" > > it would be nice if mutt were to gain the ability to conveniently deal with > > multiple mail accounts within a single instance, but it's up to the > > developers > > to decide if they want to implement it. > > Many would argue that it does that already, and much more flexibly > than other clients do it. define "flexible" in this regard. i'm not aware of anything that mutt can do with multiple accounts that e.g. thunderbird cannot. (and there are things thunderbird can do, and mutt can't, such as the unified inbox, or easily copying messages from one IMAP server to another.) i would say that mutt is so flexible that it is possible to deal with multiple accounts in spite of the fact that it wasn't designed to do so. i mean, if thunderbird were designed to handle just one mail account, there would be no way to use it with more than one. -- Joost Kremers Life has its moments
Re: unified inbox
On Mon, Feb 28, 2011 at 10:01:01AM +0100, Joost Kremers wrote: > > > > I don't think having a specific feature in Mutt is necessary or > > > > desirable to achieve this. You can easily have mail from multiple > > > > accounts delivered to your mailspool using getmail or fetchmail. > > > > > > except that that downloads the mail to your local machine. > > > > Not if you run it on your IMAP server. > > but it still puts all your mail into a single mail box, which entirely defeats > the purpose of a unified inbox. I don't see that at all... The purpose of having a unified inbox is to present all of your new mail to you simultaneously. This does exactly that. > > > mutt is really a one-mail-account kind of mail client. > > > > That's amusing... I've been using it with multiple accounts for over a > > decade. > > so have i, but you need to resort to some trickery to do that. either by > defining macros to change account info (server, username/password), or by > collecting the mail into a single mailbox, or (like me) by running multiple > instances of mutt within screen/tmux or in different tabs of one's terminal > emulator. it's certainly not as simple as: > > set imap_user[1] = "f...@bar.com" > set imap_pass[1] = "baz" > > set imap_user[2] = "f...@buz.com" > set imap_pass[2] = "baz2" No, it's much simpler. You simply need to understand how to configure Mutt. Just use URL syntax to define your mail folders, i.e.: mailboxes imap[s]://[username1[:password1]@]server1[:port][/path] mailboxes imap[s]://[username2[:password2]@]server2[:port][/path] [Of course, putting passwords in a config file is generally stupid... but mutt is flexible enough to let you be stupid.] Then, if need be, define folder hooks (or similar) to set your identities for sending mail, and such. This is hardly "trickery"; this is the standard way Mutt is configured to use multiple accounts (and to do many, many other things). > > > it would be nice if mutt were to gain the ability to > > > conveniently deal with multiple mail accounts within a single > > > instance, but it's up to the developers to decide if they want > > > to implement it. Mutt is extremely unconventional, by design... that is what gives it its power. However what you want is pretty simple. You may not prefer the way it works in Mutt, but that bit is your problem. ;-) > > Many would argue that it does that already, and much more flexibly > > than other clients do it. > > define "flexible" in this regard. See above. I think that's pretty flexible. With proper hooks defined, folder or otherwise, you can switch back and forth between multiple accounts seamlessly and effortlessly, without even needing to notice. I haven't used Thunderbird for any meaningful mail usage, so I can't really compare, sadly. Each time I tried it I found it lacking in some way or other. Unified inbox is something I specifically DO NOT want, as it removes a certain amount of context from the mail-handling process for me. -- 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. pgpDxwqUZMhKW.pgp Description: PGP signature
Re: unified inbox
On Feb 28, 2011, at 8:15 AM, Derek Martin wrote: > On Mon, Feb 28, 2011 at 10:01:01AM +0100, Joost Kremers wrote: > I don't think having a specific feature in Mutt is necessary or > desirable to achieve this. You can easily have mail from multiple > accounts delivered to your mailspool using getmail or fetchmail. except that that downloads the mail to your local machine. >>> >>> Not if you run it on your IMAP server. >> >> but it still puts all your mail into a single mail box, which entirely >> defeats >> the purpose of a unified inbox. > > I don't see that at all... The purpose of having a unified inbox is > to present all of your new mail to you simultaneously. This does > exactly that. > Actually, a "unified inbox" (as provided by Apple Mail.app or Postbox) presents all my new mail in one view, however, the mail actually remains in separate inboxes behind the scenes. A column in the view tells me where the mail actually resides. That way, mail can remain in physically separate accounts/inboxes, but can be seen in one view. Postbox takes this a bit further by allowing the user to create arbitrary number of groups -- so I could see inbox1 and inbox2 in a virtual view called "work" and inbox3 and inbox4 in a virtual view called "gambling," if I so wanted. > lacking in some way or other. Unified inbox is something I > specifically DO NOT want, as it removes a certain amount of context > from the mail-handling process for me. > > .. As noted above, the context is provided by a column in the view. My unified inbox in Apple Mail looks like so -- Subject Date Recd Mailbox = == = Derek Martin 8:18 AMInbox - punk.kish Re: unified inbox -- Someone Else 7:14 AMInbox - punkish Re: logging in BC makes.. -- I hope the above doesn't come out garbled. In the view above, I can see emails from two inboxes (even as they remain in their respected inboxes). In addition, since 2 lines are devoted to each mail, I can see the subject below the sender's name. Actually, Sparrow, a new, Gmail-specific IMAP only client (soon to expand to other IMAPs also) even shows the first couple of lines from the message text as well. Rather useful. Additional Note: Part of the issue is that I haven't really understood how Mutt works. In true Unix philosophy, mutt is (was) designed to do only one thing (reading and replying to my mail), while other tools did other things. More and more, tools are doing one "conceptual" thing (working with my mail) even though behind the scenes it is doing many things. The user, me, is not worrying about what is happening behind the scenes. More and more programs don't even require the user to interact with the physical location and storage of the content (iPhoto, Mail, and more programs in the new iOS paradigm). You open the program and your content appears there. Even if mutt works with the IMAP server, my mail is actually "stored" (cached) in my mutt cache location. I would like that to continue, particularly since I don't trust any IMAP servers (Google could vanish tomorrow -- in fact, just yesterday there was a report of some users finding their emails had vanished -- Google was working on fixing it), but I also like the ubiquitous availability of IMAP. The solution, for me, is to use IMAP, but to sync all my email locally, so I can have the best of both worlds. Will get there soon hopefully. Thanks all. Puneet.
stopped using mailcap
Hi, I've recently updated mutt to version 1.5.21 using FreeBSD ports. I used to look my text/html attachments using a text-based web browser, but it stopped working when simply hitting "Enter" ( function), that is I just see the HTML content in mutt's pager. My ~/.mailcap still works when I hit "m" ( function). Is anyone able to explain this behaviour? I've skimmed through the manual about mailcap, but I didn't see setting that could explain this behaviour. Something is unclear to me though: the description of the function states "view attachment using mailcap entry _if necessary_". When is it necessary? Thanks a lot for your help. Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche
Re: unified inbox
* Derek Martin [2011-02-27 18:11 -0800]: > On Thu, Feb 24, 2011 at 02:34:43PM -0600, Puneet Kishor wrote: > > There is much that I have to do to really get comfortable with mutt, but > > I think I am making slow but steady progress. One feature that really > > bothers me because of its absence is a unified mailbox. > > There isn't really any way to do this, except -- as others have said > already -- to get all your mail somehow delivered to the same folder. > ... > The easiest way to deal with multiple accounts with mutt is to deliver > mail from those accounts into specific folders, and use folder hooks > to set variables associated with the respective accounts upon entering > the folder. I was reading the above message when it occurred to me that using the hcache functions of mutt might be suitable to implementing a unified inbox functionality. For example, if you could define multiple inboxes and their aliases, and defined each to have the same aliase, then each accounts' messages would be stored in the same hcache directory, and thus displayed in the same the mail folder. Obviously, this is a rough draft and would need more work to be fully functional... but I think it might be useful and doable. Of course, it would need a patch (extensive) to implement... thoughts? -- dave [ please don't CC me ] pgpuy5sqyfvXT.pgp Description: PGP signature
Re: stopped using mailcap
On Tuesday, 01 March 2011 at 00:07, Jeremie Le Hen wrote: > Hi, > > I've recently updated mutt to version 1.5.21 using FreeBSD ports. I > used to look my text/html attachments using a text-based web browser, > but it stopped working when simply hitting "Enter" ( > function), that is I just see the HTML content in mutt's pager. My > ~/.mailcap still works when I hit "m" ( function). > > Is anyone able to explain this behaviour? I've skimmed through the > manual about mailcap, but I didn't see setting that could explain this > behaviour. Something is unclear to me though: the description of the > function states "view attachment using mailcap entry _if > necessary_". When is it necessary? The change was made so that the pager would work the same way on a single attachment that it does on the whole message (previously, there was no way to get the default pager view for this scope). If there's an autoview for a mime type, it will be used on the attachment unless you use view-mailcap. A different change in 1.5.21 allows all text parts to be viewed without mailcap (e.g., so that you don't have to define a separate viewer for text/patch), and this is what's causing the behavior you're seeing. It's somewhat controversial: http://dev.mutt.org/trac/ticket/3496 http://dev.mutt.org/trac/ticket/3246
