Re: set include=yes bypasses Compose Menu
On Sun 14 at 08:06 PM -0700, Kevin J. McCarthy ke...@8t8.us wrote: I'm not super familiar with the details of send-hook but I suspect multiple commands may not be allowed. Try breaking the last line into two parts and see if that helps: I think I wasn't quite clear: I do *not* have the problem when the following line is active, send-hook '(~Czsh-users| ~Cmutt-users| ~Cvex)' 'set crypt_autosign; my_hdr From: rj r...@panix.com' I only have the instant-send problem when the above send-hook line is commented-out. That would mean that although this line cures the problem, something else is causing it. I was actually wrong to say the two lines above this line had anything to do with the problem. Nothing changes either way if the two lines above it are commented-out or not commented-out. So as long as I keep this send-hook line active (which I generally want to do), I have no problem. However, given that the problem shouldn't be happening at all, I'll continue trying to isolate what else in my muttrc is causing it. -- Reintarnation: Coming back to life as a hillbilly pgpBL_hebeQG8.pgp Description: PGP signature
Re: gbnet address still used for mutt-users list?
On Sat 06/21/08 at 10:11 AM -0400, Sahil Tandon [EMAIL PROTECTED] wrote: Why not place all email addressed to mutt-users@ (regardless of the domain name) in your mutt mailbox? Great idea, and I think this is my preferred solution. Thanks for the tip. -- // [EMAIL PROTECTED] //
Re: gbnet address still used for mutt-users list?
On Sat 06/21/08 at 02:12 AM -0500, David Champion [EMAIL PROTECTED] wrote: If it is not, I'd like to remove the following from my .procmailrc: :0 * ^Delivered-To:[EMAIL PROTECTED] $HOME/Mail/m/ Just use a List-* header instead: List-Post: mailto:mutt-users@mutt.org It's too bad Majordomo doesn't offer List-ID, but List-Post will do. Not sure what you mean by use a List-* header -- I'm trying to clean out as much old cruft as possible from my .procmailrc, so I took that recipe out. Doing a imit in the mutt-users list on gbnet revealed a single message from six years ago. The worst I can suffer from removing that recipe is that if someone sends to the list using the gbnet address, it'll go to my inbox, I'll read and/or delete it. Doesn't seem like a big worry given that the last one I got was six years ago: I'd rather have old addresses and recipes I don't need cluttering up my procmailrc. -- // [EMAIL PROTECTED] //
A few years ago messages to the mutt-users list (from Germany?) were
A few years ago messages to the mutt-users list (from Germany?) were occasionally ending up in my inbox because they had been sent to what was apparently some sort of alternative address for the list: [EMAIL PROTECTED] Is anyone aware if this address is still in any way active for the list? If it is not, I'd like to remove the following from my .procmailrc: :0 * ^Delivered-To:[EMAIL PROTECTED] $HOME/Mail/m/ which of course is a recipe for putting any mail sent to that address into my mutt-users-list folder. -- // [EMAIL PROTECTED] //
gbnet address still used for mutt-users list?
A few years ago messages to the mutt-users list (from Germany?) were occasionally ending up in my inbox because they had been sent to what was apparently some sort of alternative address for the list: [EMAIL PROTECTED] Is anyone aware if this address is still in any way active for the list? If it is not, I'd like to remove the following from my .procmailrc: :0 * ^Delivered-To:[EMAIL PROTECTED] $HOME/Mail/m/ which of course is a recipe for putting any mail sent to that address into my mutt-users-list folder. -- // [EMAIL PROTECTED] //
Re: gbnet
On Sat 06/21/08 at 12:37 AM -0400, Sahil Tandon [EMAIL PROTECTED] wrote: It is no longer active. Users who send email to that address are asked, via a bounce, to direct email to [EMAIL PROTECTED] Thank you muchly, sorry for the dupe. -- // [EMAIL PROTECTED] //
Re: :source ~/.muttrc command weirdly moves message around in
On Tue 06/17/08 at 02:30 AM -0500, Kyle Wheeler [EMAIL PROTECTED] wrote: Use whatever works for you; I just recommend using a tighter pattern when possible. Your original pattern of just two lowercase letters seems to be just begging to match things you don't intend. I've never actually once ever had any matching I didn't want on |cv|dm in the line folder-hook '|cv|dm''set index_format=%3C %Z %[%m/%d] %-22.22F \ %?l?%4l%4c? %s' The cv and dm folders don't ever get mail sent directly to them. The only way any messages ever get into them is when I save them to there from my inbox, and messages I *send* to the persons (whose initials those are) get saved to there instead of to my sent-mail folder. Given that, do I still need to be concerned about false matches? I would think there's nothing that could ever get erroneously matched to them. -- // [EMAIL PROTECTED] // It is only when we step away from the actual and begin to explore the possible that life's infinities begin to reveal themselves to us. -- James Kent pgpEyfqITIGpX.pgp Description: PGP signature
Re: short-keys [OT}
IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. I find these hysterics hysterical -- some bureaucrat's idea of something IMPORTANT to put at the end of the outgoing e-mail of every single person in a company. Nobody cares about your dumb disclaimer, you rube. Of course, none of this is alex's fault. Most companies, in fact, have one that's even longer and more pompous. -- // [EMAIL PROTECTED] //
Re: :source ~/.muttrc command weirdly moves message around in
On Mon 06/16/08 at 02:30 PM -0500, Kyle Wheeler [EMAIL PROTECTED] wrote: Hmmm... so it's not matching? Interesting. Try deconstructing it, to see what's breaking the match. For example, remove the $ off the end, and see if that helps. I originally had this: |cv|dm and you suggested this: '(|=cv|=dm)$' but the only two things that works are these: |cv|dm and '|cv|dm' No other combination lets it read the%cto the right of the line. So for now, at least, I'm using the quoted version, with the notation Christian suggested for line numbers / byte size. -- // [EMAIL PROTECTED] // pgphNglQFKsjb.pgp Description: PGP signature
Re: :source ~/.muttrc command weirdly moves message around in
On Mon 06/16/08 at 09:38 PM +0200, Christian Brabandt [EMAIL PROTECTED] wrote: Have you tried something like the following format: (%?l?%4l%4c?) This will display the line number if available otherwise it will print the byte size. This is perfect. It's amazing how mutt has a solution for almost everything if you're persistent with what can sometimes seem like its formidable setup complexities. -- // [EMAIL PROTECTED] //
Re: :source ~/.muttrc command weirdly moves message around in
On Sun 06/15/08 at 09:40 PM -0500, Kyle Wheeler [EMAIL PROTECTED] wrote: [...] that you use something more like this: folder-hook '(|=cv|=dm)$' 'set index_format=whatever' The only problem I'm having with this: '(|=cv|=dm)$' instead of this: '|cv|dm' in this: folder-hook '(|=cv|=dm)$' 'set index_format=%3C %Z %[%m/%d] %-22.22F %c %s' is that with '(|=cv|=dm)$' these three folders don't show, in their index, the result of %c above, but rather the result of %3l in the following line (which is a few lines above in my.muttrc): folder-hook . 'set index_format=%3C %Z %[%m/%d] %-20.20n %3l %s' And that of course gives me an index-view that shows the number of lines in the message (some of which are 0 since I use maildirs) instead of the message's size in bytes. How can I keep the form you've suggested and also get the results of %c instead of %3l ? -- // [EMAIL PROTECTED] // To do: 1) Get VIM for Linux. 2) Get VIM for NetBSD 3) Get VIM for Solaris. 4) Get VIM for the Mac. 5) Get VIM for Windows. 6) Laugh at non-VIM users. pgp1sDjbhVyNG.pgp Description: PGP signature
Re: :source ~/.muttrc command weirdly moves message around in
On Sun 06/15/08 at 10:39 AM -0500, Kyle Wheeler [EMAIL PROTECTED] wrote: Probably a folder-hook that sets your sorting order whenever you enter the INBOX. Well, I have what's below, but I've these forever: folder-hook . set sort=threads folder-hook .'set index_format=%3C %Z %[%m/%d] %-20.20n \ %3l %s' # Now handle special mailboxes: folder-hook ! set sort=date-sent folder-hook set sort=date-received folder-hook |sent|cv|dm|fabio'set index_format=%3C %Z %[%m/%d] %-22.22F %c %s' folder-hook |sent|cv|dm|fabio'set pager_format=-%S- [%C/%m] %n \ (%c) %s' -- // [EMAIL PROTECTED] // My mechanic told me, I couldn't repair your brakes, so I made your horn louder. pgpZh0gNmwQ6u.pgp Description: PGP signature
Re: :source ~/.muttrc command weirdly moves message around in
On Sun 06/15/08 at 02:50 PM -0500, Kyle Wheeler [EMAIL PROTECTED] wrote: Think of it this way: mutt reads your muttrc (sort=date) mutt opens your inbox (hook triggered, sort=threads) you tell mutt to re-read the muttrc (sort=date) you tell mutt to re-open your inbox (hook triggered, sort=threads) Thanks -- my problem was I'd set sort=mailbox-order at some point. I restored that to date-sent -- that's how I'd always had it before. Another mistake I had to see up on the list before I could really see it was: folder-hook |sent|cv|dm|fabio'set index_format= etc ^^^ . . . duplication of sent-folder names. -- // [EMAIL PROTECTED] // pgptIUhgLfH0Y.pgp Description: PGP signature
Re: :source ~/.muttrc command weirdly moves message around in
On Sun 06/15/08 at 07:22 PM -0500, Kyle Wheeler [EMAIL PROTECTED] wrote: [that I wrote] folder-hook |sent|cv|dm|fabio'set index_format= etc ^^^ . . . duplication of sent-folder names. Well, not necessarily. Remember, you're providing a *pattern*, so that pattern you have there will match against folders named: sentimental madmen admission windmill grandma Redmond absent essential ...and lots more. Howver, given that I have: set record=+sent and that I haven't overwritten this in any of the ways it's possible to, and that the manual states: -- refers to your $record file wouldn't this mean that indicates my sent-mail folder, and that |sent|etc (as above) is a duplication of the naming of the sent-mail folder? I mean, what I need is surely this: folder-hook |cv|dm'set index_format=whatever and not this: folder-hook |sent|cv|dm 'set index_format=whatever if I want the three folders, cv and dv, all to have the same index format, yes? -- // [EMAIL PROTECTED] // pgpgvbLUm1GRR.pgp Description: PGP signature
Re: :source ~/.muttrc command weirdly moves message around in
On Sun 06/15/08 at 09:40 PM -0500, Kyle Wheeler [EMAIL PROTECTED] wrote: [...] that sent string in the original pattern will also match folders named abSENT and SENTimental and esSENTial. So it was entirely possible that the sent string was not redundant, and was actually intentional. Ah. Definitely. What you're talking about is finally sinking in. if I want the three folders, cv and dv, all to have the same index format, yes? That's still a bad regular expression for that purpose, because it's still excessively general. It will match against things like advocacy and inadvertent and advisor. Damn. Of course. I suggest, at the very least, that you use something more like this: folder-hook '(|=cv|=dm)$' 'set index_format=whatever' Absolutely. Though I'm partial to the plus-sign, so I used that instead of =. folder-hook '(|+cv|+dm)$''set index_format=whatever' Thanks for the fine-tuning. -- // [EMAIL PROTECTED] // pgpwTHsA74SbS.pgp Description: PGP signature
Re: :source ~/.muttrc command weirdly moves message around in
On Sun 06/15/08 at 11:15 PM -0400, Russell Hoover [EMAIL PROTECTED] wrote: Absolutely. Though I'm partial to the plus-sign, so I used that instead of =. folder-hook '(|+cv|+dm)$''set index_format=whatever' ^ ^ Looks like I'm better off with the equal-sign (instead of those pluses) after all. The pluses caused a repetition-operator operand invalid error message. -- // [EMAIL PROTECTED] // pgpAVsAMeb348.pgp Description: PGP signature
:source ~/.muttrc command weirdly moves message around in index
Suddenly I've discovered that when I try to re-load my .muttrc with the :source ~/.muttrc command, the last message in my index (number 920), is re-positioned as number 576. Other messages are also moved around. If I change folders out of the inbox and then back into it, the message-order is restored to normal. What could be causing this? -- // [EMAIL PROTECTED] //
Re: forwarding multiple messages
On Mon 06/09/08 at 09:37 AM -0500, Kyle Wheeler [EMAIL PROTECTED] wrote: Just thought I would point out... You can compress that into a single macro by putting a comma between index and pager:: macro index,pager F enter-commandset mime_forward=yesenterforward-message Wow. This significantly reduces the size of my muttrc. Mind if I ask how recently this feature was implemented? -- // [EMAIL PROTECTED] // Intaxication: Euphoria at getting a refund from the IRS, which lasts until you realize it was your money to start with. pgpGdNYTOQRar.pgp Description: PGP signature
ignore / unignore: what up?
I want to see *some* X-headers, like people's interesting and funny custom my_hdrs (even though there doesn't seem to be as many of them these days). But of course I don't want to see all X-headers. So I have a very long list of boring and irrelevant X-headers in my ignore list. And I have an unignore list: unignore From: Date Subject To Cc Organization Organisation \ User-Agent X-Mailer I do not have X- in that unignore list, as that of course would override the ignore list above it, and display *all* the X-headers. But for some reason I am no longer seeing *any* X-headers in my mails. This is with mutt-1.5.10i. Any clues as to what may be causing this are appreciated. -- // [EMAIL PROTECTED] //
Fixed
Fixed. I had asterisks where I shouldn't have had them in the ignore list. Sorry for the false alarm. -- // [EMAIL PROTECTED] //
Re: get Message not modified! when I try to edit a msg
On Sat 11/03/07 at 12:30 AM -0700, Gary Johnson [EMAIL PROTECTED] wrote: There's been no deliberate change to this behavior that I know of. What is your 'editor' variable set to? set editor=/usr/local/bin/vim.new +/^$# Puts vim's cursor at the second # blank line after the headers. -- // [EMAIL PROTECTED] //
Fixed
On Sat 11/03/07 at 04:50 AM -0400, I, Russell Hoover [EMAIL PROTECTED] wrote: set editor=/usr/local/bin/vim.new +/^$ The fix was to change vim.new to vim in the line above, as there is currently no vim.new on the system. I had to see it posted before I could recognize what was wrong. -- // [EMAIL PROTECTED] //
Re: no linea hdr after editing msg
On Sat 11/03/07 at 01:04 AM -0400, I, Russell Hoover [EMAIL PROTECTED] wrote: In mutt-1.4.2.3 (used on a different ISP than where I use mutt-1.5.10), if I edit a message, the lines header is lost, leaving the lines number in the index at zero. Same thing occurs with mutt-1.5.10i. -- // [EMAIL PROTECTED] //
Re: no lines header after editing a message
On Sat 11/03/07 at 01:04 AM -0400, Russell Hoover [EMAIL PROTECTED] wrote: How can I edit a message and keep a (now changed) lines header? Maybe this question should be put this way: How can I have an updated Lines: header automatically created immediately after I edit a message that is sitting in one of my mailboxes? Vim is my editor. Currently when I edit a message (in any version of mutt), the number of lines in the message-body is almost always changed. Because of this, the Lines: header is removed (and not changed to correctly reflect the new number of lines). This leave a zero in the index (and in the pager's status-line) where normally what would appear is the number of lines in the message-body. My thinking is that there must be some way to put this recipe from my .procmailrc file to work for this: # Generate a Lines: header (needed for maildir mailbox # format) using procmail's scoring mechanism. Only # message-body lines are counted (not the headers): :0 Bfhw * -1^0 * 1^1 ^.*$ |formail -ILines: $= But I'm coming up short as to how this might be done. This raises another question: There must be a reason I deleted this recipe form the .procmailrc I use with mutt-1.5.10. Did it become unnecessary at some point with mutt to have it there? -- // [EMAIL PROTECTED] //
get Message not modified! when I try to edit a msg
In mutt 1.5.10 when from either mutt's index or pager I press e to edit a message, the screen blinks and I see the error message Message not modified! What do I need to do to be able to be put into my editor to edit a message (as always happened before) ? -- // [EMAIL PROTECTED] // If everything seems to be going well you have obviously overlooked something.
no linea hdr after editing msg
In mutt-1.4.2.3 (used on a different ISP than where I use mutt-1.5.10), if I edit a message, the lines header is lost, leaving the lines number in the index at zero. I do have the following in 1.4.2.3's .procmailrc file: # Generate a Lines: header (needed for maildir mailbox # format) using procmail's scoring mechanism. Only # message-body lines are counted (not the headers): :0 Bfhw * -1^0 * 1^1 ^.*$ |formail -ILines: $= Though I no longer have this in the .procmailrc I use with mutt-1.5.10, I forget why (not needed anymore?). How can I edit a message and keep a (now changed) lines header? -- // [EMAIL PROTECTED] // This virus works on the honor system: please forward this message to everyone you know and delete a bunch of your files at random.
mutt/vim compose-new-mail macro
When I am in mutt and I press 'm' to compose a new mail, and I'm then
dropped into my editor (vim), I'd like to have it so that I'll always
be automatically already in vim's insert mode.
Right now, once mutt puts me into vim after I press 'm',
and I am in vim's 'normal mode' ready to compose a new mail,
I can invoke vim's 'O' command (open a new line above the
cursor and put the editor into insert mode) to get exactly
what I want -- insert mode plus the new line.
What I'd like to do is put the 'O' command into a mutt macro,
and I've forgotten how I'd do it.
I already have this:
# Start cursor at line 9 (with edit_hdrs set) when composing new mails ('m'):
macro index m:set editor='vim +9'^M_A compose a new mail message
macro pager m:set editor='vim +9'^M_A compose a new mail message
(Earlier in my .muttrc I bound _A' to (send a) mail, ('m' by default), so
that 'm' could be the key for the macro.)
How do I put vim's 'O' command into a this macro so that it does what
I want?
--
// [EMAIL PROTECTED] //
How can I save the help screens?
Is there an easy way to save mutt's help screens to a file, without doing a cut paste? -- // [EMAIL PROTECTED] //
How is it that mutt-users gets zero spam?
I am amazed that this list gets absolutely no spam. How is this accomplished? Perhaps some tricks cam be passed on to zsh-users, which isn't nearly as air-tight when it comes to spam-infestation. -- // [EMAIL PROTECTED] //
running mutt behind a firewall
Hey mutt users, I'm putting this question to the list for a friend. (Let me know if any more info is needed for help with answers/suggestions): How can I configure mutt to communicate directly with a POP server and SMTP server outside of my local network. I'm running Linux behind a firewall and do not wish to configure sendmail locally. Thanks in advance for any suggestions. -- // [EMAIL PROTECTED] //
startup commands
Is there any way of telling mutt to execute an interactive command (e.g. collapse-all) in .muttrc short of using push? -- // [EMAIL PROTECTED] // There are no differences but differences of degree between different degrees of difference and no difference. --William James, 1882
mutt-1.5.0, was Re: \223 and \224
On Fri 01/25/02 at 05:27 PM -0600, Jeremy Blosser [EMAIL PROTECTED] wrote: From: Jeremy Blosser [EMAIL PROTECTED] Date: Fri, 25 Jan 2002 17:27:19 -0600 Subject: Re: \223 and \224 To: [EMAIL PROTECTED] Cc: Christopher S. Swingley [EMAIL PROTECTED], Nick Wilson [EMAIL PROTECTED] User-Agent: Mutt/1.5.0i Could this mean that a 1.5.0 release is around the corner? I'm asking because, if it is, I'd like to tell my admin to hold off upgrading from 1.3.25 to 1.3.27, if 1.5.0 will be available in a week or two . . . -- // [EMAIL PROTECTED] // msg23901/pgp0.pgp Description: PGP signature
Re: [Announce] SECURITY: mutt-1.2.5.1 and mutt-1.3.25 released.
On Tue 01/01/02 at 09:40 PM +0100, Thomas Roessler [EMAIL PROTECTED] wrote: mutt-1.2.5.1 and mutt-1.3.25 have just been released. These releases both fix a security hole which can be remotely exploited. ^ ^^ I'm not sure what that means -- can you send an e-mail message that hijacks the mutt process? -- // [EMAIL PROTECTED] // msg22206/pgp0.pgp Description: PGP signature
Re: [Announce] SECURITY: mutt-1.2.5.1 and mutt-1.3.25 released.
On Tue 01/01/02 at 09:40 PM +0100, Thomas Roessler [EMAIL PROTECTED] wrote: mutt-1.2.5.1 and mutt-1.3.25 have just been released. These releases both fix a security hole which can be remotely exploited. May we be told the nature (if not the details) of the vulnerability? -- // [EMAIL PROTECTED] // msg22140/pgp0.pgp Description: PGP signature
Re: Using Maildirs, messages have 0 lines
On Tue 12/25/01 at 02:18 AM -0500, Philip Mak [EMAIL PROTECTED] wrote: I think this is the easiest solution to the Maildir lines problem, assuming that the user doesn't mind seeing bytes instead. But if you do want to see the number of lines rather than bytes, put this in your .procmailrc : # --- # Generate a Lines: header (needed for maildir mailbox # format) using procmail's scoring mechanism. Only # message-body lines are counted (not the headers): :0 Bfhw * -1^0 * 1^1 ^.*$ |formail -ILines: $= # --- -- // [EMAIL PROTECTED] // It is in no way obvious that the freedom to have a private conversation will survive. -- Whitfield Diffie msg21885/pgp0.pgp Description: PGP signature
Re: Why no new stable-branch version?
On Sun 10/28/01 at 02:59 AM -0700, Rob 'Feztaa' Park [EMAIL PROTECTED] wrote: So when the development branch gets all fixed up real nice-like, they'll make it 1.4.0. I don't want to be prescriptive, by any means, because I'm not a developer, but it would seem that the overall project runs the risk of lacking a certain healthiness if some thought isn't put toward doing this, say, at least once a year. Because if not, you're leaving behind all mutt users who have to depend on sysadmins to do the installing (I, for example -- for the time being, at least -- run MacOS at home and ssh to panix where I run mutt. As it happens, I'm lucky, because they will install 1.3.23i when I ask them to, but most sysadmins will not install anything other than non-beta, non-development software even if you beg them. Well, there was a time in your life when you were using another mail client, right? That means you had to migrate to mutt from something else at one point. Of course, but I'm not at all eager to repeat that experience. Learning mutt well and getting it optimally configured was a gradual process that took several months, though granted it was in its early stages of development then. -- // [EMAIL PROTECTED] // PGP signature
Re: Why no new stable-branch version?
On Sun 10/28/01 at 08:47 AM -0800, Eugene Lee [EMAIL PROTECTED] wrote: I wonder if Russell is thinking of something more akin to the FreeBSD development cycle where there are two branches: [snip] However, I don't know if Mutt or the Mutt community is large enough to warrant this system. This was essentially the system in effect for mutt over the last few years, but it may not be necessary now. -- // [EMAIL PROTECTED] //
Why no new stable-branch version?
It has now been -- to the day -- exactly one year and three months since a stable-branch, general-release version of mutt has appeared. While the developer-branch continues to evolve (and is now at version 1.3.23i), the stable branch stagnates at 1.2.5i. Maybe there is, in fact, a good reason for this -- I don't know. But I (and lots of others, I'm sure) would like to know. Would someone from the mutt developer community mind giving a heads-up as to the philosophy or current thinking about this situation? It just seems to me that the longer it goes on, the more difficult it will be for stable-branch users to make the change-over to a mutt-1.4.0 or whatever, as so many things will have changed so radically. -- // [EMAIL PROTECTED] // PGP signature
From header question
I use mutt 1.2.5i and the maildir mailbox format. Pressing 'h' shows the full list of headers. There is never a From line visible. But, when I press 'e' to edit the message, once I am in vim, I see a new header as the top line, From [EMAIL PROTECTED] Mon Aug 6 11:29:56 2001 I know that the address in it is the envelope (return-path) address of the mail, but why is it visible only from within vim, and not from within mutt? If I write a procmail recipe to catch text in this line (assuming I've written it correctly) should it catch it, i.e. is the line really there in incoming mail for procmail to read? -- // [EMAIL PROTECTED] //
moody mail notification
I noticed I hadn't been seeing my (zsh) shell's You have new mail notification for awhile, so I sent myself a few mails from another ISP account and discovered that mail notification is definitely not happening. But it does work if I *edit an existing message* in my inbox. (since, In mutt, if you edit a message, it's marked for deletion and a new one is created.) I can close vim, quit mutt, and the You have new mail message appears below the shell prompt. (Or I can close vim switch to another terminal where the shell prompt is displayed, press RETURN and then see the new mail message.) init file settings: biff n mesg y export MAILPATH=~/.mailspool/rj/ export MAILCHECK=5 I use maildirs, and this may be the key to the problem. I tried setting: export MAILPATH=~/.mailspool/rj/new/ since the zsh manpage has this: mailpath S Z (MAILPATH S) An array (colon-separated list) of filenames to check for new mail. [...] If an element is a directory instead of a file the shell will recursively check every file in every subdirectory of the element. but that made no change. All clues appreciated. -- // [EMAIL PROTECTED] //
Re: Does this patch really exist (Sven?)
On Thu 06/28/01 at 06:33 PM +0800, Greg Matheson [EMAIL PROTECTED] wrote: Yes, I only tried it on mbox folders. I wonder if a patch to readmsg for maildir folders was what Sven Guckes was talking about?! Probably not, but I sometimes use mbox, and know others who do. It would still help if you could say what editor you use how-where-when you invoke readmsg. Do you always have to escape to the shell to enter the readmsg command, and if you don't enter a number, will it insert the current message (as it does using it with elm)? -- // [EMAIL PROTECTED] // Snobs use their nose to cough with. -- Malcolm de Chazal Sens-Plastique
Re: Does this patch really exist (Sven?)
On Thu 06/28/01 at 06:54 AM +0800, Greg Matheson [EMAIL PROTECTED] wrote: Why not use readmsg itself? It may be on your machine. It's on mine, a Red Hat derivative, with elm. You still have to specify what number message it is you are looking for, however. Trying it from within vim from within mutt, initiating a mail message, I get this: :!readmsg 66---[my command] readmsg: Folder /net/u/5/r/rj/.mailspool/rj is empty. Press RETURN or enter command to continue (My inbox is definitely not empty.) Does it actually work for you? Exactly how are you invoking it? At which point? From within mutt? From inside your editor? Also, what mailbox format do you use? It probably works fine with mbox, but may choke on others. I use maildir mailbox format, and I have a feeling that may be affecting readmsg's functioning.
readmsg for mutt?
Can a message be put into the body of an outgoing message in mutt? 'A' inserts one as an attachment, yes, but can it be done not as an attachment? If not, is there anything like a 'readmsg' patch for mutt? This is one of the very few instances where elm does something better than mutt (shocking, when you think of it). -- // [EMAIL PROTECTED] // Dopeler effect: The tendency of stupid ideas to seem smarter when they come at you rapidly.
how insert mail-messages into body of msg I'm cmposing in mutt w/vim
What's the best way to insert one or two of the mail-messages that I have sitting in my inbox -- the current folder -- (and, say, one from another mail-folder) into an outgoing message that I'm composing (from within vim) in mutt? Is there more than one way? This is very simple to do with 'readmsg' in elm. Can it be done as simply and easily with mutt/vim? (I've been using mutt for awhile but haven't done this in so long I've forgotten how. TIA.) -- // [EMAIL PROTECTED] //
GPG sign error-message
When I sign a mail with GPG I get the following error-message: gpg: skipped `my-secret-key-ID': this is a PGP generated ElGamal key which is not secure for signatures! Press any key to continue... However, the recipient sees nothing wrong: [-- PGP output follows (current time: Tue Jan 2 07:51:37 2001) --] gpg: Signature made Tue Jan 02 06:26:09 2001 EST using DSA key ID my-public-key-ID gpg: Good signature from "Russell Hoover [EMAIL PROTECTED]" [-- End of PGP output --] This is with: set pgp_sign_as=my-secret-key-ID in my gpg.rc. But when I put in my gpg.rc: set pgp_sign_as=my-PUBLIC-key-ID I get no error message, but the recipient sees: [-- PGP output follows (current time: Tue Jan 2 07:51:37 2001) --] gpg: can't handle these multiple signatures [-- End of PGP output --] What am I dong wrong? -- // [EMAIL PROTECTED] //
Re: GPG sign error-message
On Tue 01/02/01 at 08:24 AM -0500, Russell Hoover [EMAIL PROTECTED] wrote: When I sign a mail with GPG I get the following error-message: gpg: skipped `my-secret-key-ID': this is a PGP generated ElGamal key which is not secure for signatures! Press any key to continue... I commented-out the "set pgp_sign_as" setting in my gpg.rc, and that solved the problem, though I don't know that this might adversely affect other things. Anyone know if it will? -- // [EMAIL PROTECTED] //
Re: scroll padding
On Fri 12/22/00 at 02:54 PM -0800, Mike E [EMAIL PROTECTED] wrote:
I find myself having to constantly recenter the cursor while I'm
going through emails...
Although you can always use 'H' to put the index indicator-bar (or arrow)
at the top message of your screen, 'M' to put it in the middle, and 'L' to
put it at the bottom, I agree that it might be nice if the indicator could
remain positioned at the same place while scrolling through screenfuls of
messages in the index.
(At the center, for example, if that's where you want it, or 4 lines below
center, or wherever you choose.)
Instead of it always landing at the top when you scroll to the next page
using the page-down command ('z').
Then again, it doesn't bother *me* that much to use one of the above
commands after I've landed on a new page. Why? Because there's no telling
which part of the screen I want to move to until I've looked over the list
of subject-headers. But that's just me.
--
// [EMAIL PROTECTED] //
How do I put a msg into the msg I'm composing?
A question about mutt forwarded from an elm user: I'd like to be able to incorporate into the message I'm composing an arbitrary message from the current folder, whatever it is, without first having to tag that message and without having to incorporate it as an attachment. Secondarily, it would be nice if I could use some standard prefix (like "=filename") to get "readmsg" to recognize the path to "filename" without my having to type the whole thing. There are three different directories (one of which is actually a subtree) in which I'm likely to look for a message. I don't insist on having all three of my directories recognized; one would do just fine. Thank you! -- // [EMAIL PROTECTED] //
Re: Error: could not find beginning of PGP message!
On Sun 10/08/00 at 08:07 PM -0400, Russell Hoover [EMAIL PROTECTED] wrote: Does anyone know why this error messages appears whenever I try to mail my key with ESC-k in the compose menu? [-- Attachment #2: PGP Key 0xFC5C7370. --] [-- Type: application/pgp-keys, Encoding: 7bit, Size: 0K --] [-- Error: could not find beginning of PGP message! --] This was occurring because I had the following set in my .gnupg/options file: # GnuPG takes the output from commands and prints it to this filename: # output gpg-output For anyone else who might encounter this, keep this commented-out as it is here and you shouldn't have a problem. -- // [EMAIL PROTECTED] //
Re: Mutt and Maildir?
On Fri 10/06/00 at 12:40 PM +0200, Mark Weinem [EMAIL PROTECTED] wrote: maildir is not correct: use Maildir. set mbox_type ="Maildir" I beg to differ. I've had: set mbox_type=maildir# Which of the 4 mailbox formats I use. in my .muttrc for quite some time and it's always worked fine. Why shouldn't it? Is that a Qmail thing? E.g. Is the lower-case 'm' not acknowledged by Qmail or sme other MTA? (Postfix used here w no problems.)
Error: could not find beginning of PGP message!
Does anyone know why this error messages appears whenever I try to mail my key with ESC-k in the compose menu? [-- Attachment #2: PGP Key 0xFC5C7370. --] [-- Type: application/pgp-keys, Encoding: 7bit, Size: 0K --] [-- Error: could not find beginning of PGP message! --] -- // [EMAIL PROTECTED] // PGP signature
GnuPG signing glitch
I'm having some trouble GPG-signing my outgoing messages. For example if I __'s'ign__ from the PGP options menu, these headers appear (these appear to be the defaults right now): sign as: Russell HooverMIC algorithm: pgp-sha1 I then hit RETURN, enter my passphrase, and I get: gpg: Segmentation fault caught ... exiting Press any key to continue... but if I __sign 'a's__ from the PGP options menu, and hit RETURN at the "sign as:" prompt at the bottom of the screen (and then select my name key id from the list presented) it puts these headers in: sign as: 0xFC5C7370MIC algorithm: pgp-rmd160 This time when I hit RETURN and enter my passphrase, the mail is sent, **signed**, with no problems. Any suggestions? -- // [EMAIL PROTECTED] // PGP signature
Re: Some changes / additions to the mutt-newbie docs (mutt-newbie.sourceforge.net)
On Mon 10/02/00 at 06:50 PM +0530, Suresh Ramasubramanian [EMAIL PROTECTED] wrote: [-- Type: text/sgml, Encoding: 7bit, Size: 10K --] What is a preferable mailcap entry for text/sgml? I have: text/sgml; lynx -dump %s; needsterminal; copiousoutput but this produces one long monolithic block of text with no line-spaces, tabs, paragraph indents, etc. Is this the best that can be done? -- // [EMAIL PROTECTED] //
Re: GnuPG signing glitch
On Mon 10/02/00 at 04:28 PM -0500, Jeremy Blosser [EMAIL PROTECTED] wrote: What do you have set for $pgp_sign_as? This should be a key id (0xFC5C7370), not your name (Russell Hoover). That's it -- it *was* set to my name. Why did I think it should be? Was this the case at some time in the past? I must have read that to have set it that way. Or maybe not, who know. Anyway I've now set it to my public key id and that fixed the problem. I should have picked up on this myself when I said that seemed to be the default -- I just couldn't remember exactly where it was set. **thanks** -- // [EMAIL PROTECTED] //
Re: News support in mutt
On Wed 09/20/00 at 08:05 PM +0930, Brian Salter-Duke [EMAIL PROTECTED] wrote: However hard one tries to customorize mutt or slrn to be the same there are irritating small differences. Yes !!! And this is one big plus in favor of the NNTP patch. -- // [EMAIL PROTECTED] //
Unable to send key
I seem to be unable to send my public GPG key. Here's what happens when I try: 1) Let's say I've composed an e-mail and am ready to send it, along with my key. From the compose menu, I press Esck; 2) I'm prompted at the bottom of the screen: "Please enter the key ID:" I enter the ID of my GPG public key and press RETURN. 3) This puts me in the PGP menu where I see my public and private key IDs listed thus: 1 + 1024/0xFC5C7370 DSA -s Russell Hoover [EMAIL PROTECTED] 2 + /XxXXXX XXX e- Russell Hoover [EMAIL PROTECTED] 4) I press RETURN and get this message at the bottom of my screen: Invoking pgp...File `gpg-output' exists. Overwrite (y/N)? This is where the trouble starts, because I am now stuck here. I can't get out by pressing RETURN or y or Y or n or N or anything else. I'm hung. 5) So I Control-c out, and am put back into the compose menu, where I see my public key listed in the Attachments list: - A 2 PGP Key 0xFC5C7370. [applica/pgp-keys, 7bit, 0K] But when I 'v'iew the key attachment, I get this message: [-- Error: could not find beginning of PGP message! --] And if I send this mail, the recipient sees this: -- [-- Attachment #1 --] [-- Type: text/plain, Encoding: 7bit, Size: 0.1K --] My text message here. -- // [EMAIL PROTECTED] // [-- Attachment #2: PGP Key 0xFC5C7370. --] [-- Type: application/pgp-keys, Encoding: 7bit, Size: 0K --] [-- Error: could not find beginning of PGP message! --] --- What am I doing wrong? -- // [EMAIL PROTECTED] //
Re: send pubkey trouble
On Tue 07/11/00 at 12:41 PM -0400, Hardy Merrill [EMAIL PROTECTED] wrote: I mis-wrote - I really used Esck, and *that* created an empty attachment. Am I trying to do this the right way? I want to extract my public key and send it using mutt - any help is appreciated ;-) I, too, am unable to send my public gpg key. Here's what happens when I try: 1) I have composed an e-mail and am ready to send it (along with my key). So, from the compose menu, I press Esck; 2) I am prompted at the bottom of the screen: "Please enter the key ID:" I enter the ID of my GPG public key and press RETURN. 3) This puts me in the PGP menu where I see my public and private key IDs listed thus: 1 + 1024/0xFC5C7370 DSA -s Russell Hoover [EMAIL PROTECTED] 2 + /XxXXXX XXX e- Russell Hoover [EMAIL PROTECTED] 4) I press RETURN and get this message at the bottom of my screen: Invoking pgp...File `gpg-output' exists. Overwrite (y/N)? And this is where the trouble starts, because I am stuck here. I can't get out by pressing RETURN or y or Y or n or N or anything else. I'm hung. 5) So I Control-c out, and am put back into the compose menu, where I see my public key listed in the Attachments list: - A 2 PGP Key 0xFC5C7370. [applica/pgp-keys, 7bit, 0K] But when I 'v'iew the key attachment, I get this message: [-- Error: could not find beginning of PGP message! --] And if I send this mail, the recipient sees this: -- [-- Attachment #1 --] [-- Type: text/plain, Encoding: 7bit, Size: 0.1K --] My text message here. -- // [EMAIL PROTECTED] // [-- Attachment #2: PGP Key 0xFC5C7370. --] [-- Type: application/pgp-keys, Encoding: 7bit, Size: 0K --] [-- Error: could not find beginning of PGP message! --] --- What am I doing wrong? -- // [EMAIL PROTECTED] //
Re: How can I display most X- headers but not all
On Mon 07/24/00 at 03:56 PM -0400, yours truly, [EMAIL PROTECTED] wrote:
What if you want to see *all* X- headers (including ones you don't know)
except a specific few that you *are* able to specify? As I noted above,
I tried using a second "ignore" line after the "unignore" line, and that
didn't work.
According to the manual (for anyone who's interested), I'm apparently SOL if
I want to keep "X-" in the unignore line (which I do):
To remove a previously added token from the [ignore] list, use the
``unignore'' command. Note that if you do ``ignore x-'' it is not
possible to ``unignore x-mailer,'' for example.
Though I'm doing the opposite ("unignore X-"), it works the same way (I
can't "ignore X-mailer" after the unignore).
--
// [EMAIL PROTECTED] //
PGP signature
How can I display most X- headers but not all
I thought I wanted to see all "X-" headers that came my way, so I set: ignore * # This means "ignore all header lines by default." unignore From: Date Subject To Cc Organization Organisation User-Agent \ X-Mailer X- But there are some I don't want to see, such as: X-Authentication-Warning: X-Accept-Language: X-Priority: X-MSMail-Priority: X-MimeOLE: How can I eliminate a specified few X- headers while maintaining the visibility of all others? I tried: color header black black ^X-(Priority|MSMail-Priority): It just gave me the headers in gray. -- // [EMAIL PROTECTED] // An animal's feet are as intelligent as a man's hands. -- Malcolm de Chazal Sens-Plastique
Re: How can I display most X- headers but not all
On Mon 07/24/00 at 01:47 AM -0700, Anton Graham [EMAIL PROTECTED] wrote: Your muttrc file is read from the top down, so you can put another ignore line after the unignore: ignore X-Priority X-MSmail-Priority That was the first thing I did, and it had no effect. Does that really work for you? -- // [EMAIL PROTECTED] // PGP signature
Re: How can I display most X- headers but not all
On Mon 07/24/00 at 02:31 PM +0530, Suresh Ramasubramanian [EMAIL PROTECTED] wrote: Here's part of my .muttrc - ignore * unignore From To Cc Subject Date Reply-To Organization X-Mailer Whichever X-Foo headers you want to see get explicitly unignored. In your example (if I understand you correctly), for the X- headers you want to see, you have to place each specific X- header individually by name in the "unignore" line. What if you want to see *all* X- headers (including ones you don't know) except a specific few that you *are* able to specify? As I noted above, I tried using a second "ignore" line after the "unignore" line, and that didn't work. -- // [EMAIL PROTECTED] // PGP signature
Re: How can I display most X- headers but not all
On Mon 07/24/00 at 01:13 PM -0700, Anton Graham [EMAIL PROTECTED] wrote: Yes :) As an example, these are the ignore / unignore lines I normailly use: ignore lines precedence status nntp-posting-host path old-return-path [...] ignore X-eGroups-From x-sequence resent- from unignore from: To test, before I responded, I added: unignore x-sequence x-loop x-sender x-priority X-MSMail-Priority unignore X-MimeOLE ignore X-MSMail-Priority X-MimeOLE Then I took a message from an outlook user on another list and looked at it with the new settings (From: header extracted for the poster's privacy): [snip] Hmm. Something about the way I'm doing it isn't working: -- # HEADERS (incoming mail): # Don't show any header-fields except the ones in the 'unignore' line: ignore * # This means "ignore all header lines by default." unignore From: Date Subject To Cc Organization Organisation User-Agent \ X-Mailer X- ignore X-Priority X-MSMail-Priority hdr_order From: Date Subject To Cc Organization Organisation User-Agent \ X-Mailer X- -- "X-Priority" and "X-MSMail-Priority" still show. Anything identifiable here? I also have, in the colors section above this section: color headercyanblack ^(X-*|User-Agent*) -- // [EMAIL PROTECTED] // PGP signature
Why would setting dsn_notify _return disrupt normal mail-sending?
I've just gotten mutt to work on a new (backup) ISP. (And at least until I persuade the sysadmin to upgrade, it's mutt 0.95.7i). It took me the *longest* time to be able to send any mail. Then I finally realized I had to disable "dsn_notify" and "dsn_return" in my .muttrc in order for any mail at all to be sent out. I had them set at "dsn_notify=failure,delay" and "dsn_return=hdrs". Now I have to keep them commented-out. Does this mean the ISP is using a version of sendmail older than 8.8? (I ask this because the mutt manpage mentions Berkeley sendmail 8.8 in the section on dsn.) This seems very messed-up. No one uses mutt on that ISP, and I'd like to be able to tell the sysadmin what to do to prevent this from happening (because he's not going to know). Can anyone offer tips? -- // [EMAIL PROTECTED] // PGP signature
'reload .muttrc' removes parens around no-of-lines in index
I've noticed recently that when I'm looking at mutt's index, and I do a 'reload .muttrc', suddenly the parentheses around the number-of-lines field disappear. Also, a zero gets added to the date field just-to-the-left-of the number representing days of the month consisting of a single digit. In other words, the index goes from looking like this: 20 r T 05/ 9 [EMAIL PROTECTED] ( 50) Re: Receipt for payment 21 s 05/ 9 Thomas Roessler ( 85) [Announce] mutt-1.2 is out. 22 r + 05/ 9 Teddi Longardt ( 10) Thank you! 23 F 05/ 9 Russell Hoover ( 21) Panix's Message of the Day to looking like this: 20 r T 05/09 [EMAIL PROTECTED] 50 Re: Receipt for payment 21 s 05/09 Thomas Roessler85 [Announce] mutt-1.2 is out. 22 r + 05/09 Teddi Longardt 10 Thank you! 23 F 05/09 Russell Hoover 21 Panix's Message of the Day If I change folders (or even 'change' into the same folder), the parens and zeros are re-added. I much prefer the display *without* the parens (less cluttered) and *with* the zeros -- the display I get when do the I 're-load .muttrc'. My question to the list is: How can I get the preferred display to show at all times, not just when I reload muttrc? I have 'reload .muttrc' mapped to ESCAPE-e: # Reload the .muttrc with ESC e: macro index\ee ":source ~/.muttrc\n""\"ESC e\" reloads the muttrc" macro pager\ee ":source ~/.muttrc\n""\"ESC e\" reloads the muttrc" and index_format set so: # Format of the lines in the index: set index_format="%3C %Z %[%m/%d] %-20.20n %3l %s" The zeros in the date (or lack thereof) would seem to have to do with the strftime on my system, but the strftime man says: %dis replaced by the day of the month as a decimal number [01,31]. In other words the manpage assumes that the leading zero is always already there. I'm using mutt-1.2i, S-Lang 1.4.1, procmail-3.14 and zsh-3.0.7 on NetBSD 1.4.2_ALPHA. Any takers? [panix6:~] mutt -v r4 Sunday 000521 07:25:24 Mutt 1.2i (2000-05-09) Copyright (C) 1996-2000 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: NetBSD 1.4.2_ALPHA [using slang 10401] Compile options: DOMAIN="panix.com" +DEBUG -HOMESPOOL -USE_SETGID +USE_DOTLOCK -USE_FCNTL -USE_FLOCK +USE_IMAP -USE_GSS -USE_SSL -USE_POP +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_PGP +BUFFY_SIZE -EXACT_ADDRESS +ENABLE_NLS SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/mail" SHAREDIR="/pkg/mutt-1.2/libdata/mutt-1.2" SYSCONFDIR="/pkg/mutt-1.2/libdata/mutt-1.2" ISPELL="/usr/local/bin/ispell" To contact the developers, please mail to [EMAIL PROTECTED]. To report a bug, please use the muttbug utility. -- // [EMAIL PROTECTED] //
Re: 'reload .muttrc' removes parens around no-of-lines in index
On Sun 05/21/00 at 09:12 PM +0300, Mikko Hänninen [EMAIL PROTECTED] wrote: Sounds like you have different settings for the $index_format in a stand-alone "set index_format" command and in folder-hooks. This was indeed the problem. Thanks. // [EMAIL PROTECTED] //
test
test -- // [EMAIL PROTECTED] //
Maildir support in Procmail 3.14 -- how?
Since procmail 3.14 supports the maildir mailbox format, I would assume that means, using it with mutt, that I can get rid of the maildir.c delivery program I've been using for the last couple of years, and that I can change my procmail recipes from one like this: :0 * ^TO.*mutt-(users|users-request) |maildir Mail/m/ to one like this: :0 * ^TO.*mutt-(users|users-request) ~/Mail/m/ and have things work smoothly. But when I get rid of maildir.c and remove "|maildir " from the recipes, all my messages end up in the ~/Mail/m/ directory *alongside* the cur/, new/ and tmp/ subdirectories, not *inside* any of them, as they should. So how do I get the new procmail to deliver to maildirs without the previously necessary add-ons? I know that I'm calling version 3.14 of procmail in my .forward file, and I use the trailing slash in all recipes. Also -- is it still necessary with the new procmail to generate a lines header? In other words, can I remove the following from my .procmailrc? # --- # Generate a "Lines:" header # (needed for maildir mailbox format) # Only msg-body lines are counted (not the hdrs): :0 bw LINES=|wc -l | tr -d " " :0 fhw |formail -a "Lines: $LINES" # --- Thanks. -- // [EMAIL PROTECTED] //
Re: Looking for a nice color scheme
On Sun 05/07/00 at 11:40 PM -0500, "Corey G." [EMAIL PROTECTED] wrote:
I am looking for what I would call a nice color scheme for Mutt. I
currently use the scheme listed below but I would like to see what other
people have come up with.
From my .muttrc:
color hdrdefault brightwhite black
color signaturebrightred black
color indicatorbrightyellowbrightred
color errorbrightred black
color status yellow blue# The 2 status bars are yellow *on
blue.*
color tree brightmagenta black # The thread-tree for threaded
mailboxes.
color tildebrightmagenta black
color message brightgreen black # Informational messages, *not mail.*
color normal white black # Plain text ("white" is set at silver,
# "brightwhite" is set at white).
color attachment cyanblack # 'Cyan' is set at purple.
color search brightwhite red # Highlights the search patterns
in the pager.
color header yellow black ^(From|Subject):
color header cyanblack ^(X-*|User-Agent*)
color body brightyellowblack "(ftp|http)://[^ ]+"
color body brightblue black \\*.*\\*
color body cyanblack \\_.*\\_
color body magenta black \\/.*\\/
color body cyanblack [-a-z_0-9.]+@[-a-z_0-9.]+
color markers red black # This is the '+' that indicates
wrapped pager lines.
color underlinewhite red
color body magenta color0 "(mailto:)?[^[ =^:#,+\t\n()@\"]+@[^]
=:/^#,\t\n)@\"\\*]+"
color index brightblue black(~[EMAIL PROTECTED]~[EMAIL PROTECTED])
color index brightblue black(~[EMAIL PROTECTED]~[EMAIL PROTECTED])
color index brightwhiteblack ~z15k # Subject headers of all mails larger
# than 15k are brightwhite in
# the index.
# Different colors for 8 levels of quoting:
color quoted brightgreen color0
color quoted1 color1 color0
color quoted2 brightyellow color0
color quoted3 brightblue color0
color quoted4 brightcyan color0
color quoted5 cyan color0
color quoted6 brightwhite color0
color quoted7 blue color0
# Setting by number can resolve color-name conflicts between mutt your term
# program:
# 0 = black 1 = red 2 = green 3 = yellow 4 = blue 5 = magenta
# 6 = cyan7 = white (usually lite grey) 8 = brightblack (us. drk grey)
# 9 = brightred 10 = brightgreen 11 = brightyellow 12 = brightblue
# 13 = brightmagenta 14 = brightcyan 15 = brightwhite
mono header underline ^(From|Subject):
mono quoted bold
--
// [EMAIL PROTECTED] //
Theologians reckon by eternity, philosophers in centuries, statesmen in
years, politicians in days, and generals in minutes, but the seducer
stands to lose everything if he isn't ready on a second's notice.
-- Malcolm de Chazal Sens-Plastique
Re: address book?
On Mon 05/08/00 at 01:34 AM -0500, Kelly Scroggins [EMAIL PROTECTED] wrote: Is there a default address book for mutt? I don't think there is. But the way you create it is this. Put these lines in your .muttrc: set alias_file=~/.mutt_aliases# Where I keep my aliases. source ~/.mutt_aliases # Don't forget to *source* the aliases file. Then create the file .mutt_aliases, and put your aliases there in this format: alias kelly Kelly Scroggins [EMAIL PROTECTED] -- // [EMAIL PROTECTED] // Red is the universal hinge of color. If the sun were a rose-window, red would be at the hub. -- Malcolm de Chazal Sens-Plastique
Re: address book?
On Mon 05/08/00 at 06:12 AM -0500, Kelly Scroggins [EMAIL PROTECTED] wrote: How do I get one of the addresses into a message I'm composing? After you strike "m" to compose a message, you'll be at the "To:" prompt. When you are there, strike TAB, and all your aliases will be visible. You can then do "t" to tag any alias(es) (or just hit RETURN) and that/those alias(es) will then be in the "To: field of your soon-to-be-outgoing-message's header. This is pretty basic stuff -- it's all in the manual at mutt.org, which you should take a look at. -- // [EMAIL PROTECTED] //
How far away is mutt 1.2?
Would anyone care to hazard a realistic estimate (or even an unrealistic one) as to when we might see the release of mutt 1.2? -- // [EMAIL PROTECTED] //
application/pgp-signature unsupported?
If I have this in my .mailcap file: application/pgp; cat; copiousoutput application/pgp-keys; pgp -f %s ; copiousoutput application/pgp-signature; cat ; copiousoutput and this in my .mime-typs file: application/pgppgp application/pgp-signature pgp gpg and if I have these in my .muttrc: set implicit_autoview # Always use the MIME-types defined in the ~/.mailcap # file to display MIME-attachments. # MIME-TYPES (listed in the .mailcap file for mutt's auto_view): auto_view application/octet-stream application/pgp application/pgp-signature \ application/postscript application/x-arj-compressed application/x-cpio \ application/x-csh application/x-gtar application/x-gunzip \ application/x-latex application/x-rar-compressed application/x-sh \ application/x-shar application/x-tar application/x-tar-gz \ application/x-tex \ application/x-troff application/x-troff-man \ application/x-troff-me \ application/x-zip-compressed \ image/* text/enriched text/html why have I begun to see this at the end of mail messages in mutt: [-- Attachment #2 --] [-- Type: application/pgp-signature, Encoding: 7bit, Size: 0.2K --] [-- application/pgp-signature is unsupported (use 'v' to view this part) along with the warning: mailcap entry for type application/pgp-signature not found??? -- // [EMAIL PROTECTED] //
Re: application/pgp-signature unsupported?
On Fri 05/05/00 at 02:07 PM -0400, Russell Hoover [EMAIL PROTECTED] wrote: why have I begun to see this at the end of mail messages in mutt: [-- application/pgp-signature is unsupported (use 'v' to view this part) along with the warning: mailcap entry for type application/pgp-signature not found??? It was working fine -- only began to see this recently. Anyone have any clues? (Forgot to add the following info): Mutt 1.0.1i (2000-01-18) Copyright (C) 1996-2000 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: NetBSD 1.4.2_ALPHA [using slang 10310] Compile options: DOMAIN="panix.com" -HOMESPOOL -USE_SETGID +USE_DOTLOCK -USE_FCNTL -USE_FLOCK +USE_IMAP -USE_POP +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR -BUFFY_SIZE -EXACT_ADDRESS +ENABLE_NLS SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/mail" SHAREDIR="/pkg/mutt-1.0.1i/libdata/mutt-1.0.1" SYSCONFDIR="/pkg/mutt-1.0.1i/libdata/mutt-1.0.1" ISPELL="/usr/local/bin/ispell" To contact the developers, please mail to [EMAIL PROTECTED]. NetBSD panix6.panix.com 1.4.2_ALPHA NetBSD 1.4.2_ALPHA (PANIX-USER) #0: Thu Dec 30 15:20:45 EST 1999 [EMAIL PROTECTED]:/devel/netbsd/ release/src/sys/arch/i386/compile/PANIX-USER i386 -- // [EMAIL PROTECTED] //
Re: BUFFY_SIZE option
On Mon 02/14/00 at 01:20 AM -0500, Russell Hoover [EMAIL PROTECTED] wrote: Could someone explain where or how the BUFFY_SIZE option got its name? Still hoping for an answer here. Does no one the list know why BUFFY_SIZE or xbuffy were given that name? Who wrote the xbuffy patch? I mean, there isn't a DRAGON option is there? I'm actually trying to respond to someone who asked this very question, absurdly accusing mutt of being influenced by pop-culture frivolity, and I know that the original xbuffy patch had nothing to do with this, yet I don't know why it *was* called that either . . . -- // [EMAIL PROTECTED] //
Re: BUFFY_SIZE option
On Tue 02/15/00 at 10:29 PM -0500, Russell Hoover [EMAIL PROTECTED] wrote: there isn't a DRAGON option is there? I mean a --VAMPIRES option . . . -- // [EMAIL PROTECTED] //
subscribe vs. lists
I could swear I read on this list not too long ago that the command "subscribe" would replace the "lists" command in the muttrc to define what mailing lists mutt should recognize the user as being subscribed to. I thought this change was going to take place in version 1.0.1, but AFAKCT it hasn't. Is this change still in the works, or has it been abandoned? -- // [EMAIL PROTECTED] //
BUFFY_SIZE option
Could someone explain where or how the BUFFY_SIZE option got its name? And does it cycle through incoming mailboxes only at the 'c' (change-folder) prompt? And is that it's only function? -- // [EMAIL PROTECTED] //
Re: mutt/vim/sigdashes question
On Tue 01/18/00 at 10:00 AM -0500, David T-G [EMAIL PROTECTED] wrote:
Since you reference lines 2/3 you are probably not using edit_headers and
wouldn't be interested in setting your editor variable to something like
set editor="vim +/^$"
to put the cursor at the first blank line. But it might help.
It did help. I decided to start using edit_headers because without them
I always wondered, as I was writing a mail, if I had the correct address on
the 'To:' header-line. I'd have to wait til I got into the compose menu,
after writing the mail, to see it. And sometimes I'd forget to look at it
before sending a mail.
But I'm still not sure how to make a mutt macro to automatically put me
into vim in insert mode. Right now I have this .muttrc macro:
(where '_A' is mapped to mutt's original 'm' command):
# Start cursor at line 8 (with edit_headers set)
# in vim's insert mode when composing new mails ('m'):
macro index m":set editor='vim +8'^M_A" "compose a new mail message"
macro pager m":set editor='vim +8'^M_A" "compose a new mail message"
The problem is that almost anything I put after 'vim ... is read as a
filename. Not sure how to get around that, any tips appreciated.
--
// [EMAIL PROTECTED] //
mutt/vim/sigdashes question
When I go to send a new mail with the 'm' command, how can I make it (by creating a macro or otherwise) so that I am instantly put into vim in insert mode, and with the sigdashes on line 3 instead of line 2? -- // [EMAIL PROTECTED] //
Re: Quotes in macros [Was: macros - is there any logic about when they work or not?]
On Mon 11/29/99 at 09:26 AM +, Chris Green [EMAIL PROTECTED] wrote:
So, for example, the following macros in my .muttrc file *don't*
work (though they all appear OK on the help screen):-
macro generic ,s "s{mailandnews.co.uk}"
macro generic ,c "c{mailandnews.co.uk}"
macro generic ^X ":source ~/.mutt/"
macro index ^X ":source ~/.mutt/"
But the following ones do work:-
macro generic \\b ":source ~/.mutt/muttrc\r"
macro generic \\d ":source ~/.mutt/demon\r"
macro generic \\c ":source ~/.mutt/cgreen\r"
macro generic \\i ":source ~/.mutt/isbd\r"
macro index ,s "s{mailandnews.co.uk}"
macro index ,c "c{mailandnews.co.uk}"
I believe that in your first two and last two macros above, the quotation
marks are unnecessary, since if I'm not mistaken quotes are only needed if
you have one or more spaces in whatever sequence you've defined. Though
apparently macros will function whether you have the quotes there or not.
But (sorry) I don't know why the top four macros won't work.
--
// [EMAIL PROTECTED] //
Re: The mbox_type variable [was Re: mbox2maildir]
On Mon 11/29/99 at 08:14 AM -0500, Subba Rao [EMAIL PROTECTED] wrote: Where do you set mbox_type="Maildir"? In .muttrc? Where? Well, I put it alphabetically, just after "set mbox..." and just before "set mime_forward..." Maybe I'm not understanding the question. You can put it anywhere you like, as long as it's somewhere in your .muttrc. Are the double quotes required? No. Here's what I have in my .muttrc: set mbox_type=maildir # Which of the 4 mailbox formats I use. (Anything you put to the right of the '#' is just a comment, or note to yourself, that will not be acted upon, command-wise.) What is the difference between mbox_type and $mbox_type in .muttrc? Don't use the dollar-sign in your .muttrc. That just means that it's a variable, when you're referring to it in discussion or whatever. -- // [EMAIL PROTECTED] //
User-Agent header still not in stable branch
Since the "User-Agent" header is now the RFC-defined standard (and not just "window-dressing"), could we please finally have it replace the "X-Mailer" header by default in the next stable, publicly-released version of mutt? "User-Agent" appears to have replaced "X-Mailer" in the last several development versions, but for some reason hasn't made it yet to the stable branch. I should think this would be a no-brainer -- the code is already there. It just has to be copied from the latest development version, no? -- // [EMAIL PROTECTED] // It is in no way obvious that the freedom to have a private conversation will survive. -- Whitfield Diffie
slrn-style header-coloration still not in mutt
Every so often on mutt-users, someone asks for slrn-style header-coloration (where the name of the header -- everything to the left of the colon -- can be defined as one color, and the value of the header -- to the right of the colon -- as another color). But this still has not been made possible in mutt. Forgive me if something more complicated is involved (I don't know much about C-language coding, though clearly it's time to learn), but this would seem to be another no-brainer -- a question of looking at how it's done in slrn and copying that code, perhaps with some minor modifications, into mutt. Can't this be put on the agenda for one of the next versions of mutt? -- // [EMAIL PROTECTED] //
Re: Colours of headers
On Sun 10/24/99 at 11:18 PM +0100, John Poltorak [EMAIL PROTECTED] wrote: I would like to change the colours of headers so that part of the line up to ':' is one colour and the rest a different colour. So would I, and a bunch of other folks, I'd suspect. (Anyone?) Like in slrn. This question has been raised periodically but seems to have been ignored by the developers, who maybe would like it too but are busy with other priorities for mutt. If so can I also do something like display certain X-Mailer lines in one colour and others in a differnt colour? Yes: color headercyanblack^(X-*|User-Agent*) -- // [EMAIL PROTECTED] // City cops state cops national guard bureau cops tv cops movie cops uniform plainclothes cops riot cops cops on top of cops on top of cops on top of cops: it's a world full of cops. --Paleface
Re: forwarding attachments
On Sat 09/04/99 at 07:30 PM -0400, erik [EMAIL PROTECTED] wrote: Why when i try to forward a message with an attqchment, it doesnt include it with the message. is there a way to make mutt do this? From the mutt manual: 6.3.40. forward_decode Type: boolean Default: set Controls the decoding of complex MIME messages into text/plain when forwarding a message. The message header is also RFC2047 decoded. This variable is only used, if Mime_forward'' is unset, otherwise Mime_forward_decode'' is used instead. 6.3.73. mime_forward Type: quadoption Default: unset When set, the message you are forwarding will be attached as a separate MIME part instead of included in the main body of the message. This is useful for forwarding MIME messages so the receiver can properly view the message as it was delivered to you. If you like to switch between MIME and not MIME from mail to mail, set this variable to ask-no or ask-yes. Also see Forward_decode'' and Mime_forward_decode''. 6.3.74. mime_forward_decode Type: boolean Default: unset Controls the decoding of complex MIME messages into text/plain when forwarding a message while Mime_forward'' is set. Otherwise Forward_decode'' is used instead.
Delivered-To: hdr on bounced mails?
From the 1.0pre2i manual: 6.3.19. bounce_delivered Type boolean Default: set When this variable is set, mutt will include Delivered-To headers when bouncing messages. Postfix users may wish to unset this variable. Why unset for Postfix users? My ISP uses Postfix (I use my ISP's mutt), and the headers on a bounced mail are the same whether I set bounce_delivered or not. In both cases, four "Resent: ___" headers are added, but there is no "Delivered-To:" header. (Just trying to understand how the new variable works.)
User-Agent: or X-Mailer: ??
What determines which of these two headers is displayed automatically?
("automatically" as opposed to being displayed because you've created
one or the other as a user-defined "my_hdr" in the muttrc.)
Re: User-Agent: or X-Mailer: ??
On Fri 09/03/99 at 02:14 PM +0200, Ralf Hildebrandt [EMAIL PROTECTED] wrote: What are you talking about? The sender uses "my_hdr" or "edit_hdrs" to add/edit arbitrary headers. The recipient can use "ignore" and "unignore" to hide/display the headers. Yes. Of course. I probably shouldn't have used the word "display." But beginning with mutt development version 0.96.1 (I'm pretty sure it's that one, that's when I first saw it), mutt began to create a "User-Agent:" header instead of an "X-Mailer:" header according to newer RFC specifications. Except that in messages on this list created with versions of mutt from 0.95.7 through all the 0.96.x development versions and through versions 1.0pre1 and 1.0pre2, I've sometimes seen the "User-Agent:" header and sometimes the "X-Mailer:" header. These headers are not created with a "my_hdr" command, nor manually via "edit_hdrs" editing (well, they _can_ be, but that would be in addition to whichever of the 2 is already there). They're not arbitrary headers. They're generated automatically by mutt. So what is it that determines which one is produced in the (full) header-list?
cursor craziness at launch of 0.956i
Has anyone else noticed that the cursor jumps wildly around the screen upon opening version 0.95.6? (0.95.5 didn't do this) -- // [EMAIL PROTECTED] // We know the halls of the eye like welcome visitors but we live in our mouth. -- Malcolm de Chazal Sens-Plastique
Re: slrn-style header-coloration still not in mutt
On Wed 11/03/99 at 10:08 PM -0500, I [EMAIL PROTECTED] wrote: Every so often on mutt-users, someone asks for slrn-style header-coloration (where the name of the header -- everything to the left of the colon -- can be defined as one color, and the value of the header -- to the right of the colon -- as another color). Can't this be put on the agenda for one of the next versions of mutt? After thinking about it a bit, I'm not so sure this is the best idea after all for the pager-headers, since it would make it hard to have (as is currently the case) an entire header line appear in one color to distinguish it from the others (for example to have the "Subject:" line stand out in its own color from the rest of the headers. You can pattern-match on an "X-" header, for example, or on "From:", "Subject:" etc, but I don't know how you'd be able to match on or define a color for the *value* of a header (the text to the right of the colon), since you don't know what it's going to be. The way mutt handles this now is preferable, I think, to slrn's article-header coloring, which is less flexible. -- // [EMAIL PROTECTED] //
