On Wed, Dec 24, 2003 at 09:32:00AM -0800, Brian M. Sutin wrote: > Mutt 1.4i (2002-05-29): As you can readily tell, that's an old version. You should be on the 1.5.x branch instead, judging by some of your issues below (especially the IMAP stuff). > I have recently been trying to use Mutt from home to remotely read > my mail. I have a list of bugs/issues/whatever that I have run into > recently. None are fatal. I would appreciate if people could let > me know which of these are misunderstandings on my part, so I can > report the rest as bugs and not waste the developers' time. I'll try as many as I can, and hopefully others'll step forward for the rest. > Issue 1: > > "unmy_hdr" does not seem to always function correctly. Neither of: > > unmy_hdr Bcc: > unmy_hdr bcc > > make the "Bcc:" not appear in outgoing mail messages when $edit_headers > is set. What you see in your editor and what actually gets sent are two different things. You'll notice there's a blank "Reply-To:" header also in there if you don't have one set. It's just Mutt's way of making it easy for you to add blind carbon copy recipients. Also, unmy_hdr and my_hdr aren't for editing messages per se. They're simply for adding (or cancelling the addition) of user-defined headers (which happens to occur before editing). Try "unmy_hdr From:" and you'll see it does nothing either, since it's not a user-defined header (although if you have "my_hdr From: blah@xxxxxxx" in effect, then "unmy_hdr From:" will undo that, allowing Mutt to pick its own "From:" header). > Issue 2: > > My email is at "domain.com", and has the login name "user+domain.com". > When I use: > > account-hook imap://domain.com/ 'set imap_user=user+domain.com > imap_pass=password' > mutt -f imap://domain.com/ > > then Mutt functions perfectly. The problem is that I have two accounts > at domain.com. When I tried: > > account-hook imap://user+domain.com@xxxxxxxxxx/ 'set > imap_user=user+domain.com imap_pass=password' > mutt -f imap://user+domain.com@xxxxxxxxxx/ > > then I was still asked for a password. The version: > > account-hook imap://user+domain.com@xxxxxxxxxx/ 'set imap_pass=password' > mutt -f imap://user+domain.com@xxxxxxxxxx/ > > is unable to log in. Don't look at me. I use only a single IMAP account on my own system, and fetchmail(1) everything from my other accounts into it. > Issue 3: > > In the IMAP multiple-account section of the manual, there should be an > example for user@host. Send mutt-dev a patch, and I'm betting it'll be included. > Issue 4: > > In the manual, it isn't clearly written what "allow8bit" does. Which is > yes and which is no? ditto > Issue 5: > > Mutt needs to flush the GPG/PGP passphrase if it is entered wrong. > Otherwise > it doesn't prompt again, and mutt has to be restarted to send signed mail. There's a patch available for that. Take a look at the recent mutt-dev archives, or buzz me privately and I'll forward you a copy of the relevent post. > Issue 6: > > Setting "reverse_name" does not appear to function. I have multiple email > addresses forwarded to one inbox, ans when I reply, I want the previous > "To:" address to be my new "From" address. Even though I have set > "reverse_name", I am not seeing this behaviour. Perhaps the manual needs > to document just what "reverse_name" is using to find the address. reverse_name depends on alternates being set correctly. If Mutt doesn't know that an address in the "To:" header is in fact yours, it has no reason to assume you'd like to forge it while sending mail out. > Issue 7: > > Mutt appears to lack an environment variable MUTTRC for the location of > the mutt initialization file. What's the need for? If you don't want to pollute your home directory with hidden files, just create a ~/.mutt/muttrc file instead; Mutt will check for it automatically if ~/.muttrc doesn't exist. > Issue 8: > > If PGPPATH is not set, Mutt should check GNUPGHOME. Or does it need to? > The manual should address this. That's handled 100% by your PGP RC file. Mine checks my own $PATH. (The stock one shipped with late versions has /usr/bin hardcoded, which I don't like. 1.2.x used to simply look in the $PATH, which IMHO is better.) > Issue 9: > > IMAP does not give the sizes before download. This is a problem for very > large files. Is this an IMAP problem or a Mutt problem? 1.5.x does. It's simply a feature that nobody bothered to include in the 1.4.x Mutt branch. > Issue 10: > > IMAP does not notify of new mail. No recheck, for some reason. I have to > close and reopen the connection to see new mail. That's weird. Here's what I have to check for new email every second: $ grep timeout ~/.mutt/muttrc set timeout=1 > Issue 11: > > The mutt.org bug reporting system should list most-recent bugs first, not > last. <shrugs>People actually use that page?</shrugs> /me just googles for anything interesting, and lets google sift through the bug reports instead ;-) > That's the list. I hope your list is now a bit shorter :-) > Brian - Dave -- Uncle Cosmo, why do they call this a word processor? It's simple, Skyler. You've seen what food processors do to food, right? Please visit this link: http://rotter.net/israel
Attachment:
pgpzqyFLnjk6A.pgp
Description: PGP signature