Re: Changing From header
* On Sun, 13 Oct 2002, Brian Bray wrote: > I've been looking around for a painless way to modify the From header based on > which account I am using. Maybe you just need to set $alternates and $reverse_name. -- John
Re: ISO cancel option in quit prompt from send-message
* On Tue, 08 Oct 2002, Ken Irving wrote: > Apologies for subscribing just to ask a question, and maybe for the > unclear subject. Too often I accidentally hit 'q' after editing a > message, and am presented with the choice to discard the message or not. > Usually I want to select a third option, cancel the quit operation > altogether, but instead have to carefully _not_ discard the message, > then hit 'm' to see a prompt to revisit pending messages. Maybe Ctrl-G is what you're looking for? -- John
Re: Sending mime encoded attachments with correct type
* On Sat, 05 Oct 2002, James Marsh wrote: > On Fri, Oct 04, 2002 at 06:44:58PM -0700, John Iverson wrote: > > >>I am however having a problem with sending attached images with the > >>correct mime types --- they're appearing as application/octet-stream > >>rather than image/jpeg. Have I missed something in the mailcap file? > > > >Maybe /etc/mime.types or ~/.mime.types instead, something like: > > > > image/jpeg jpeg jpg jpe > > Yes, that's what I thought too. Unfortunately it didn't work. My > ~/.mailcap currently looks like this [ ... ] But what about ~/.mime.types? Are you saying you have a line like the above in ~/.mime.types? -- John
Re: Sending mime encoded attachments with correct type
* On Sat, 05 Oct 2002, James Marsh wrote: > Hi all, > > I've been using mutt for the last week and am very impressed so far, > especially with the amount of helpful information and scripts > etc that are generally available. > > I am however having a problem with sending attached images with the > correct mime types --- they're appearing as application/octet-stream > rather than image/jpeg. Have I missed something in the mailcap file? Maybe /etc/mime.types or ~/.mime.types instead, something like: image/jpeg jpeg jpg jpe -- John
Re: move function
* On Wed, 02 Oct 2002, Jack Bates wrote:
> Does mutt include a command to move a message from one folder to
> another? Thanks,
The save command ('s' by default) is for that. To copy, use 'C'
(by default).
--
John
Re: List problems?
* On Wed, 02 Oct 2002, PeterKorman wrote: > It'z back. Not for me. Things seem fine.
Re: .procmailrc
* On Mon, 30 Sep 2002, savanna wrote: > A slightly offtopic question - I'm using procmail for my mail filtering, > just wondering what people are using to catch all of the mutt-users > email. I'm currently using: > > :0 : > * ^To:.*(mutt-.*) > mutt-users > > :0 : > * ^Cc:.*(mutt-.*) > mutt-users > > :0 : > * ^From:.*(mutt-.*) > mutt-users > > An better recipe out there? (procmail recipes aren't my strength). :0: * ^Sender: owner-mutt-users@mutt mutt-users Or, to catch both copies if someone CCs you as well as sending to the list: :0: * ^TO_mutt-users@ mutt-users -- John
Re: The browser
* On Thu, 26 Sep 2002, Johan Svedberg wrote: > Anyone experinced mutt going to the wrong mailbox when you're > in the browsers mailbox view and place the indicator on some > mailbox and press enter? This happens when you get new mail in the last mailbox you visited after going to the browser. Mutt thinks you should see the new mail in your 'current' mailbox instead of what you told it to do. Another problem is that the new mail indicator for that mailbox doesn't work in the browser. It's been discussed a couple of times, but I guess it's a side effect of Mutt's design. What I've done is create a macro to go to the browser, which first visits a mailbox that doesn't receive mail. This seems to be at least a work around for this behavior: macro index "=postponed?" "Browse folders" -- John
Re: List problems? - gbnet.net problem?
* On Mon, 30 Sep 2002, Sven Guckes wrote: > Mutt 1.4i: =IN/MUTT (threads) [69/47071] [NEW=40058] [~d 26/9/2002-] > > so - 69 messages since 26th September... I only see about 9 messages *after* Sep 26 and they're all addressed to gbnet. Do the online archives look okay to you? I got the message I'm replying to in my inbox, and not my mutt folder. I don't see the Sender: field. Maybe you bcc'ed me or something? > > To: [EMAIL PROTECTED] > > Mail-Followup-To: [EMAIL PROTECTED] > > i won't fall for this... no no... > > perhaps the problem is only with addresses > who subscribed to the gbnet.net addresses? I normally always use the mutt.org address and subscribed with it. I only used gbnet that time because I wanted it to make it to the list. I don't expect to get my copy of this message either, until the problem is fixed. -- John
List problems?
I am recently only seeing list messages that are (mis)addressed to <[EMAIL PROTECTED]>. And there is an error message at http://groups.yahoo.com/group/mutt-users/messages that says: Warning! Your group has exceeded its message storage limits of 64 MB by 0.0 MB. If you don't remove messages, older messages will be deleted to make room for new ones. -- John
Re: Coloring full line in header
* On Wed, 25 Sep 2002, Thomas Dickey wrote: > On Wed, Sep 25, 2002 at 03:34:58PM -0700, John Iverson wrote: > > * On Wed, 25 Sep 2002, D. J. Bolderman wrote: > > > > > I want to color my headers, but something goes wrong here. For > > > example: I have the subject colored white, with a blue > > > background, but the rest of the line stays black... I've > > > searched the archives but didn't find a proper solution. > > > > > > I'm using 'color index white blue "^Subject:" > > > > I think the consensus is that this is an ncurses issue. I fixed > > it for myself by compiling with s-lang instead of ncurses. > > uh no - it's a mutt issue. I stand corrected. However, I did experience the same problem of the coloring not extending to the end of the line, and the problem (or behavior or whatever) definitely went away when I switched to s-lang. -- John
Re: Coloring full line in header
* On Wed, 25 Sep 2002, D. J. Bolderman wrote: > I've searched the archives but didn't find a proper solution. See the "Header color" thread from July 25, 2002, for one discussion of this. -- John
Re: Coloring full line in header
* On Wed, 25 Sep 2002, D. J. Bolderman wrote: > I want to color my headers, but something goes wrong here. For > example: I have the subject colored white, with a blue > background, but the rest of the line stays black... I've > searched the archives but didn't find a proper solution. > > I'm using 'color index white blue "^Subject:" I think the consensus is that this is an ncurses issue. I fixed it for myself by compiling with s-lang instead of ncurses. -- John
Re: Multiple coloring
* On Thu, 19 Sep 2002, Johan Svedberg wrote: > Hi, all. > > I'm a little unsure of how to formulate this question so please poke on > me if you don't understand. :) > If I for example have this in my .muttrc: > > color index blue black "~D" > color index brightyellow black "~f winkle ~p" > > I would like all the mail I mark for deletion to be colored the same > way, so my question is this: > > Is it possible to set some kind of priority for which color mutt should > use in case a mail has both of these "conditions"? The last one that matches will determine the color, so you would need to reverse the order of the commands above. -John
Re: problem removing a macro
* On Sun, 08 Sep 2002, Chuck Tuffli wrote: > Hi - > > I'm using mutt with an IMAP server and have a macro defined for d that > saves a copy of the message to the Trash folder (i.e. macro index d > "s=Trash\r"). I wanted to change the behavior of the d key back to > its original meaning if I'm in the Trash folder (actually delete the > message on the server). > > When I tried to undefine the macro with 'bind index d noop', the macro > definition goes away but so does the ability to delete the message. > Trying things like 'bind index d delete-message' after the above warns > about a circular macro definition. Where am I goofing this up? Should > this work? Tnx! You need folder-hooks. Here's what I do: ## Move messages to trash rather than delete, unless ## we're in the trash folder. folder-hook . 'macro index d "=trash"' folder-hook . 'macro pager d "=trash"' folder-hook trash 'macro index d ""' folder-hook trash 'macro pager d ""' ## Delete old, non-flagged, non-new mail folder-hook trash 'push ~r>10d!(~F|~N)' -- John
Re: setting From dynamically
* On Sun, 08 Sep 2002, Gregory Seidman wrote: > Aldy Hernandez sez: > [...] > } For example, if someone mails me at [EMAIL PROTECTED], I'd like my return > } address to be set to [EMAIL PROTECTED] when I reply to the message. > > Check out the reverse_name variable. You'll need to also set $alternates. -- John
Re: mutt configuration: attachments
* On Mon, 02 Sep 2002, Rory Campbell-Lange wrote:
> I'd like to forward mails with attachments. At the moments
> these are forwarded inline.
If you're talking about forwarding a mail while including the
original as an attachment: See "mime_forward".
If you're talking about forwarding a message including its
attachments: (v)iew the attachments menu, tag the desired
attachments, and then do a tag-forward (";f" by default).
--
John
Re: Show unread mail
* On Thu, 29 Aug 2002, John Iverson wrote: > It seems like what is needed is something like a > command in addition to the (The correct command name is .) > I guess you could create a macro to do something close to this > by switching to a non-mailbox folder and then issuing a > "?" to get to the browser. FWIW, here's a macro that seems to provide a work-around for me: macro index ,b "=postponed?" "Browse folders" macro pager ,b "=postponed?" "Browse folders" -- John
Re: Show unread mail
* On Thu, 29 Aug 2002, John Keniry wrote: > On Thu, Aug 29, 2002 at 02:48:47PM +0200, Martin Man wrote: > > > filename), with mailbox you have to grep for '^Status: O' to > > see which messages are unread, and this could be quite CPU > > intensive, IMHO that's why it's still left out of mutt, would > > be nice to be able to switch it on/off on demand though > > It doesn't *sound* like an impossibility. > > If it has to grep, or whatever, then surely it also has to do > it when you enter a maillbox (in order to write the index). > Once it has that info could it not keep an internal count of > read/unread as you examine the messages. And if it could do > that couldn't it display the info in the browser. In my situation at least (Maildir), Mutt *does* know about new mail correctly and *is* re-scanning sometimes -- but it seems to leave a mailbox "open" when you go to the mailbox browser. It seems like what is needed is something like a command in addition to the command. Since "change" implies that you are going to pick a new mailbox from the browser right away, Mutt doesn't do anything to the mailbox you were in until you choose a new one (since you might want to [q]uit and go back to where you were). The "old" mailbox doesn't get synced until you pick the new one (which his why the %N in the browser_format maybe needs a new symbol for "current folder" in addition to "new mail" and "no new mail"). The command could be like restarting with "mutt -y" and would close/sync the open mailbox before going to the browser. I guess you could create a macro to do something close to this by switching to a non-mailbox folder and then issuing a "?" to get to the browser. -- John
Re: Show unread mail
* On Wed, 28 Aug 2002, Will Yardley wrote: > John Iverson wrote: > > >> With Maildir, the folder will continue to show up as having > >> new messages (I don't know if that, in and of itself is a > >> good reason to switch to Maildir). > > > I'm using Maildir folders, and I'm having the same problem. > > And it doesn't matter if the folder gets more new messages. > > The "N" marker never shows up for the mailbox you just came > > (to the mailbox browser) from. > > right, but once you enter another mailbox and go back to the > browser, it shows up as having new mail again. Yes, and then you have the same problem with the other mailbox. :-) > with mbox, it doesn't show up as having new mail again until > new new mail arrives. So I guess we should consider this a design limitation? Since things seem okay when I first start up with "mutt -y", maybe it shouldn't be too hard to create a command that closes a mailbox without having to switch to another one. -- John
Re: Show unread mail
* On Wed, 28 Aug 2002, Will Yardley wrote: > John Keniry wrote: > > On Wed, Aug 28, 2002 at 09:51:19PM -0700, Will Yardley wrote: > > > John Keniry wrote: > > >>> Is there a way to show on the browser page which folders > >>> contain unread mail other than opening them and looking for > >>> it? > > >> Define the folders you want checked in mailboxes; ie: > >> > >> mailboxes ! +foo +bar +lists:mutt +poop > > > I've done that, and ok when I press 'l' on the browser page I > > see the folders marked 'N'. > > > > Suppose I enter the folder, then leave it without reading all > > the new mail. Then the folder just looks like an ordinary > > folder (no 'N'). Do I simply have to remember where I have > > unread mail? > > With mbox, i'm afraid that's the case (until the folder gets > more new messages). > > With Maildir, the folder will continue to show up as having new > messages (I don't know if that, in and of itself is a good > reason to switch to Maildir). I'm using Maildir folders, and I'm having the same problem. And it doesn't matter if the folder gets more new messages. The "N" marker never shows up for the mailbox you just came (to the mailbox browser) from. -- John
Re: Problem with new mail notify
* On Wed, 28 Aug 2002, Mickaël Villers wrote: > I have few problems with new mails significations. Here is a > example: > > I read a mbox ( debian-french-user for example ) and when I > have finish, I go to the mailboxes list (c?) and > wait/check for new mails on others mbox (like mutt-users). I > receive a new mail in an other box (mutt) and it is notify and > during the same time one in my dfu-ml which is not notify, I > try to open the mu-ml but it opens dfu-ml because I receive > mails in it. > > Is it a bug or have I to do something before living like > synchronise mbox? This was mentioned (by me) in the "New mail notification problems" thread which started on Aug 18. It seems to be normal behavior -- no one has responded to say that they do not see this behavior. (Anyone?) I think you should be able to go to the mailbox browser screen and wait for new mail to arrive without worrying that the "N" indicator won't work for the mailbox you were in before you came there. Maybe we're missing something. Anybody know anything about this? -- John
Re: New mail notification problems
* On Mon, 19 Aug 2002, John Iverson wrote: > > The only known issue (afaik) about Mutt *not* reporting new > > mail is when the user has "unset mark_old" in their > > configuration. In this case a message that would ordinarily be > > marked as old is still new, but won't be detected with the file > > modification/access time heuristic. > > I don't know if it's related, but I've noticed the following > behavior which was briefly discussed here before: When you switch > from Mailbox A (index or pager view) to the folder list view, > Mutt won't show the N flag next to Mailbox A when there is new > mail in it. It doesn't seem to matter whether the new mail was > already there or if it arrives while in folder list view. If you > then switch to Mailbox B and back to folder view, the N flag for > Mailbox A works again (but now Mailbox B has the same issue). > > Can anyone say whether this is a feature or bug? I'm using > Maildir folders with "set mark_old=no", if that's relevant. How about this question, then: Does anyone's Mutt correctly indicate new mail in Mailbox A in the above scenario? If it's normal behavior and not a bug in my setup, I suspect Mutt considers that you are still viewing Mailbox A until you choose another one, and this has something to do with it. But the mailbox browser screen is misleading in this case, to me. Maybe a special "current mailbox" symbol next to Mailbox A would be better than just nothing, which wrongly indicates the lack of new mail. -- John
Re: New mail notification problems
* On Mon, 19 Aug 2002, Mike Leone wrote: > I use Maildir with IMAP, and I see *no* new mail notifications > on the folders at all. When I open the mailbox (maildir), yes - > the index or pager shows new messages. But using the "c" > command to switch folders only ever shows the name of the > folder, and not a new mail notification symbol. > > You're saying that you do see a new mail indicator on Maildir > (i.e., IMAP) folders? Maildir, but not IMAP (perhaps I misused a term somewhere). I'm referring to the mailbox browser screen which appears when you press "?" after pressing "c". Yes, I do see the new mail indicators, except for the mailbox I just came from. (Doesn't matter if I press to switch between mailbox and file views.) When I first start mutt with "mutt -y" (i.e. there is no last-visited mailbox), the new mail indicators for all mailboxes seem to work. Just curious if this is normal behavior or not. There did not seem to be a conclusion last time it was discussed, and I thought it possible that this is what the original poster was experiencing. -- John
Re: New mail notification problems
* On Mon, 19 Aug 2002, Michael Elkins wrote: > The only known issue (afaik) about Mutt *not* reporting new > mail is when the user has "unset mark_old" in their > configuration. In this case a message that would ordinarily be > marked as old is still new, but won't be detected with the file > modification/access time heuristic. I don't know if it's related, but I've noticed the following behavior which was briefly discussed here before: When you switch from Mailbox A (index or pager view) to the folder list view, Mutt won't show the N flag next to Mailbox A when there is new mail in it. It doesn't seem to matter whether the new mail was already there or if it arrives while in folder list view. If you then switch to Mailbox B and back to folder view, the N flag for Mailbox A works again (but now Mailbox B has the same issue). Can anyone say whether this is a feature or bug? I'm using Maildir folders with "set mark_old=no", if that's relevant. -- John
Re: Deleting mails older than 20 days after shutting mutt down
* On Mon, 12 Aug 2002, Sven Guckes wrote: > macro index q "~O ~d >20d\n+FOO\n" or (untested): macro index q "~r>20d!(~F|~N)" (Delete if received more than 20 days ago, except for flagged or new messages, and then quit.) -- John
Re: Header color -> color header fg bg regexp
* On Thu, 25 Jul 2002, Sven Guckes wrote: > * V_Suresh <[EMAIL PROTECTED]> [2002-07-25 08:09]: > > How do I set the bg/fg color for the whole line, for a particular > > header field?? Not just for the header alone, but the whole line > > should have the same bg color?? How is this possible?? > > color header fg bg regexp I think he means that this command is only coloring to the end of the last word in the header and not all the way to the end of the line on his screen. I noticed this behavior before, too, and when I switched from ncurses to s-lang, it started doing the whole line. It may depend on terminal settings or something else, too? -- John
Re: newbie question on binding
* On Thu, 11 Jul 2002, Rich wrote: > I have tried actually binding the keys while i am in mutt with > the command ":bind pager backspace previous-line" Try ":bind pager previous-line" -- John
Re: how to use the ISP''s smtp server directly
* On Thu, 11 Jul 2002, [EMAIL PROTECTED] wrote: > Hi, > I would like to use mutt without the sendmail server on my > machine. I find sendmail configuration quite abstruse. Can I > directly make Mutt connect to my ISP's outgoing SMTP server. Not with just Mutt by itself, but you might want to check out ssmtp. It's linked from mutt.org's links section, along with other choices. -- John
Re: replying to and quoting an HTML attachment
* On Wed, 10 Jul 2002, Eugene Lee wrote: > I looked in the archives and couldn't find a specific answer > this one. I receive several HTML messages that arrive as an > attachment with no plain text equivalent in the main message > body or another attachment. When I reply to these messages, > how do I configure Mutt to convert the HTML attachment into > plain text, quote it, and finally edit it? Or is this a > mailcap issue? Thanks in advance. I beleive these are the relevant settings I use: In .muttrc: alternative_order text/plain text # Favor plain text in multipart messages auto_view text/html # View html dumped to text in pager (see .mailcap) In .mailcap (choose one according to browser): # text/html; lynx -dump %s; copiousoutput; nametemplate=%s.html # text/html; links -dump %s; copiousoutput; nametemplate=%s.html text/html; w3m -dump %s; copiousoutput; nametemplate=%s.html -- John
Re: A few questions
* On Wed, 10 Jul 2002, Rocco Rutte wrote: > ,[ ~/.mutt/setup/macros ]- > | [...] > | ### remove ~N on all mail > | macro index ,n >"~NN~T" > "Remove ~N flag on all mail" > | [...] > `- You might want to replace the "N" above with "N", so it turns off the N flags instead of toggling, thus making it work in the (probably rare) case where it's run in a folder with no (N)ew messages. -- John
Re: set realname with folder-hook?
* On Tue, 09 Jul 2002, Mark Johnson wrote: > I'm trying set realname using a folder-hook. Tried this: > > folder-hook . set realname="Mark Johnson" > folder-hook in-mutt set realname="Mark" > > and variants, but can't seem to get it working. Try enclosing your set commands in single-quotes: folder-hook . 'set realname="Mark Johnson"' folder-hook in-mutt 'set realname="Mark"' -- John
Re: newbie: getting mail outta the box
* On Sat, 06 Jul 2002, Jeff Maxson wrote: > using debian sid (mostly), i386, exim, fetchmail. Using pine (the old > standby) I can send out mail (I'm using that now) and it actually arrives > at a final destination. Using mutt, I can get/read mail, but sending it > from mutt seems to drop the mail in the bitbox. Mutt seems to think that > it sent it (it says so, anyway), but I don't know if it is talking to exim > correctly. Like I said, pine is on speaking terms with exim. There's > bound to be something in the .muttrc that makes mutt work too. Any ideas > would be great. (I can send stuff to myself locally, btw). One idea: 6.3.198. sendmail Type: path Default: "/usr/sbin/sendmail -oem -oi" Specifies the program and arguments used to deliver mail sent by Mutt. Mutt expects that the specified program interprets additional arguments as recipient addresses. -- John
Re: mutt not sending mail
* On Sun, 07 Jul 2002, Sam Carleton wrote: > I am new to mutt. I have installed both mutt and qmail on my UNIX > machine. When I when to send mail via mutt, it ended up in > ~/Maildir/outbox/cur. Sounds like maybe that's where Mutt was told to save copies of outbound messages via the "copy" and "record" variables. > What am I doing wrong? Maybe you need to adjust the "sendmail" variable: 6.3.198. sendmail Type: path Default: "/usr/sbin/sendmail -oem -oi" Specifies the program and arguments used to deliver mail sent by Mutt. Mutt expects that the specified program interprets additional arguments as recipient addresses. -- John
Re: how to filter in procmail
* On Sun, 23 Jun 2002, John P Verel wrote: > On 06/23/02 12:16 -0700, Will Yardley wrote: > > how about: > > * ^Return-Path: > > > or: > > * ^Sender: owner-mutt-users > > I use: > > * ^TO_mutt > Mutt Which of the above methods you want to use depends on how you want to handle the situation when someone follows up on a post of yours to the list and also includes a cc: to your personal address (or vice versa): ^Sender method: The list copy goes into your Mutt folder and the personal copy into your inbox (or wherever procmail ends up putting it). ^TO_ method: Both copies will go into your Mutt folder, since they will both include "mutt" in the To: or Cc: header. I guess frequent posters might prefer the ^TO_ method? For infrequent posters or lurkers, it wouldn't matter much. -- John
Re: Globbing in 'mailboxes'
* On Mon, 17 Jun 2002, Magnus Therning wrote: > Is it possible to do? > > I am a bit tired of having a mailboxes line that spans two lines... You can use the output of a command (within backticks), such as: mailboxes ! `echo -n ~/Mail/*` or whatever filemasks you need. -- John
Re: Diff between 'd' and 'D~A'?
* On Tue, 11 Jun 2002, Ken Weingold wrote: > I have new mail colored brightcyan. Deleted is red. If I hit > 'd' to delete mail, it turns red. If I delete the pattern ~N, > they stay blue, You mean brightcyan? > but are marked as deleted. What's the difference here? Order seems to be significant with the "color index" commands. Put the ~D coloring command _after_ the ~N one if you want the ~D coloring to take precedence: color index ... ... ~N color index ... ... ~D -- John
Re: Color with folder-hooks and status changes
* On Fri, 07 Jun 2002, Joseph Ishac wrote: > Actually, I wasn't aware you could do that with the folder-hook > command. :) However, I did a quick copy/paste on the lines > below and it didn't remedy the problem. Works as intended here -- maybe you had other 'color index' commands which were interfering? > I think I'll stick with the four term expression with the use > of ~P (which I didn't know about either). Cool. > Thanks again for the help. No problem. -- John
Re: Color with folder-hooks and status changes
* On Fri, 07 Jun 2002, Joseph Ishac wrote: > No amount of reordering seemed to solve the problem, I've tried > N different combinations (likely missing the right one of > course :) What I was originally thinking was not just reordering what you had, but also moving the ~D, ~F, and ~T into your folder-hook -- something like (using ~P for "from me"): folder-hook . 'color index blue black ~P; \ color index black red ~D; \ color index red black ~F; \ color index magenta black ~T' folder-hook =sent 'color index white black ~P; \ color index black red ~D; \ color index red black ~F; \ color index magenta black ~T' Or did you try that? > However, I have run across something that does seem to work well. > > The 5 commands: > folder-hook . 'color index blue black "!((! ~f jishac)|~T|~F|~D)"' > folder-hook =sent 'color index white black "!((! ~f jishac)|~T|~F|~D)"' > color index black red ~D > color index red black ~F > color index magenta black ~T > > produce the desired effect. Mind you I didn't know how to AND > things together (and a simple A & B wasn't working) so I simply > applied good ol' DeMorgan's Law to "((~f jishac)&(! ~T)&(! > ~F)&(! ~D))" > > If there is a more elegant solution, feel free to share ;) That seems like a pretty good solution to me (maybe use the ~P as above?). > Now if only the command: > color indicator red white ~F > > would actually be possible ... See the "indicator color question" thread from a few days ago ... -- John
Re: Color with folder-hooks and status changes
* On Thu, 06 Jun 2002, Joseph Ishac wrote: > The desired effect would be to have the behavior of the hooks > as well as always changing color for status changes (such as > tagging, etc.) I beleive the color used depends on the *last* matching color index statement, so you might have to include the ~D, ~F, and ~T ones in your folder-hook *after* the ~f one. -- John
Re: indicator color question
* On Tue, 04 Jun 2002, Mike Schiraldi wrote: > It was put in CVS quite a while ago; i'm not sure what versions > of mutt include it, though. Doesn't seem to be in 1.3.99 or 1.4 (just upgraded). I tried commenting out all indicator color and mono commands. I'm using S-Lang -- would that matter? Is it part of v1.5? -- John
Re: Two questions
* On Mon, 03 Jun 2002, Adam Fields wrote:
> 1) Is there a way to open part of a folder? Say I have a folder
> with 2000 messages, and I want to only look at, say, 190-200?
Open the folder, then do a limit ('l' by default) using the
pattern "~m 190-200".
> 2) What's the right way to do batch refiling, particularly of mailing
>lists?
You could, for example, ('T' by default) all
messages over 2 weeks old using the pattern "~d >2w".
Then save (move) all tagged messages to another folder:
;s
--
John
Re: indicator color question
* On Sun, 02 Jun 2002, Ken Weingold wrote: > I am playing with more colors for the index. Way too cool. I > can't believe I didn't do this stuff earlier. Anyway, I wanted > to change the indicator, for example, for messages marked for > deletion. Can the indicator color not be changed like the > index and such? I don't think you can have the indicator color change based on the status of a message with a default setup, but there is apparently a patch (by Mike Schiraldi) to make the indicator bar display in the inverse colors of the index line. I believe there was some talk about this being incorporated into Mutt. Anyone know the status, or how to turn it on if it's there? -- John
Re: Strange multi-color quoting behavior
* On Fri, 17 May 2002, Gary Johnson wrote: > Actually, since it's just text in the quote, I like having them > in the same color as the rest of the quote, which is how I have > my quote_regexp configured. Are you referring to my quote of David's example, or the original? :-) > > But it looks to me like Mutt doesn't really know the depth of > > a quote as it works now. For example, if you have a message > > with _only_ "second-level" or higher quote prefixes (say "> > > > "), Mutt still seems to start with the first-level color. > > It starts with the first-level color because a second-level or > higher quote is part of a first-level quote. Having the first > quote character in one color lets you see the scope of the > entire quote. I understand that, but I think you're talking about a message with both first- and second-level quotes. My point was that if you view a message such as the following (with no other text): > > All lines in this message begin with at least *two* > > greater-than signs (or other quote_regexp-matching > > characters). ... then mutt uses the first-level color only, instead of the second-level color, which might be expected. Maybe "start with" was the wrong phrase to use. > It doesn't really matter to me which way mutt does it. Each > method has a logic behind it. It's more a matter of preference > and what you might be used to from other tools. True. And I think a lot of people use mutt in conjunction with Vim, which seems to go by quote depth only (haven't looked into reconfiguring this). -- John
Re: Strange multi-color quoting behavior
* On Thu, 16 May 2002, David Champion wrote: > I don't find that multiple quotation styles at the *same* > quotation depth is a very common occurrence. Much more common > is that I'm being mailed something that begins with a column of > '#' marks -- a shell script posted in reply to someone's > comments, say: > > > your script doesn't cover quite all cases. can you post a fix? > > OK, try this: > #!/bin/sh > # revision 2 > # by request > echo Hello, solar system! But in this case it's nice to have the "#" lines distinguished from the ">" lines by being a different color, isn't it? Maybe the solution is to make it an option to go by _depth only_ when coloring quotes. Or to be able to group some quote prefixes together as being "equivalent" for coloring purposes. But it looks to me like Mutt doesn't really know the depth of a quote as it works now. For example, if you have a message with _only_ "second-level" or higher quote prefixes (say "> > "), Mutt still seems to start with the first-level color. -- John
Re: Strange multi-color quoting behavior
* On Thu, 16 May 2002, David T-G wrote:
> You should probably continue to quoted5 or quoted6 to fill out
> your test, because ...
[ ... ]
> ... this appears to be looping except for the rematch on the
> last '>' line.
Yes, Mutt loops through the colors again if you go past the
defined quote levels. That's what I wanted.
> While they may be, it doesn't really make sense for there to be
> two first-level quotes with different delimiters, even if you
> might split them up for vparsing. A more practical example
> might be one reply to two originals, perhaps like
>
> Quoting John:
> % >he said this
> % he did??
> % >and then that
> % no!
>
> Quoting Bill:
> % # that was messier
> % # and I wouldn't want it
> % yeah, you said it
>
> or so. Now you would see the outer quotes (%) in color 1 and
> you might expect to see the inner quotes (> and #) both in
> color 2 but mutt would (correctly, IMHO) identify them as
> separate (after all, one is John and the other Bill) and color
> them as 2 and 3, respectively.
Right.
> % back to the first leading quote prefix ("> " above), resets
> it % again. (Vim, for example, seems to display this
> correctly, % although it uses different quote prefixes by
> default.)
>
> I'm interested in your definition of "correct", perhaps
> clarified through detailed description of an example. My
> definition of "correct" matches mutt's apparent performance.
Correct = How I thought it should work at the time ;-)
My original thinking was that the color should depend on only the
"level" of the quote, and when I saw that vim did it this way, it
reinforced my thinking that maybe Mutt was doing something wrong
or I had something configured wrong. But it's looking like Mutt
is right and now I think I prefer the way Mutt handles it.
--
John
Re: Strange multi-color quoting behavior
* On Wed, 15 May 2002, Rob 'Feztaa' Park wrote: > Alas! John Iverson spake thus: > > why do the following lines show up in different colors? > > Well, first of all, the colors don't match what you said (at > least for me). Even with the same color settings (3 levels, which repeat) and same (default) $quote_regexp? > But I believe that coloring them differently is correct > behavior. Since the quote character is different, it's a > different quote. It's not part of the same quote. Thus mut uses > a different color on it. I wondered if it was intentional behavior. It does make sense in a way, I guess. Just wondering if it's the same for everyone, or if someone has a definitive answer, since this particular behavior is not mentioned in the manual AFAICT. -- John
Re: Strange multi-color quoting behavior
* On Thu, 16 May 2002, Sven Guckes wrote:
> mutt behaves the way you expect it to,
> that is the follwoing lines show up in
> "blue on default":
>
> > This is in "quoted" color
> > This is in "quoted" color again
>
> the follwoing lines however
> are not shown in the colors
> you wrote:
>
> | This is in "quoted1" color
> : This is in "quoted2" color
> } This is in "quoted" color
> # This is in "quoted1" color
Did anyone using a similar $quote_regexp see strange coloring on
my original post? (I am seeing it on the above re-quoted lines
as well, so it's not just the first quote character that affects
it.)
> I'm sure there must be something else
> in your setup which changes this.
>
> > It seems when the _leading_ quote prefix changes,
> > the color sequence is not reset, but continues
> > where it left off, and going back to the first
> > leading quote prefix ("> " above), resets it again.
>
> any hooks involved? check your setup.
> or try again with *no* setup at all!
>
> mutt -F /dev/null
>
> does it work as expected now?
I started mutt as above and then manually entered the "color
quotedx" commands by hand at the colon prompt -- still the same
behavior.
> if not - did you compile with
> ncurses or slang? (see "mutt -v")
Is one preferred over the other? Here is the mutt -v output:
Mutt 1.3.28i (2002-03-13)
Copyright (C) 1996-2001 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: Linux 2.4.18 (i686) [using ncurses 5.1]
Compile options:
-DOMAIN
-DEBUG
-HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE
+USE_FCNTL -USE_FLOCK
-USE_POP -USE_IMAP -USE_GSS -USE_SSL -USE_SASL
+HAVE_REGCOMP -USE_GNU_REGEX
+HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET
+HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM
+HAVE_PGP -BUFFY_SIZE -EXACT_ADDRESS -SUN_ATTACHMENT
+ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET
++HAVE_LANGINFO_YESEXPR
+HAVE_ICONV -ICONV_NONTRANS +HAVE_GETSID -HAVE_GETADDRINFO
ISPELL="/usr/bin/ispell"
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/local/share/mutt"
SYSCONFDIR="/usr/local/etc"
EXECSHELL="/bin/sh"
-MIXMASTER
To contact the developers, please mail to <[EMAIL PROTECTED]>.
To report a bug, please use the flea(1) utility.
> > Vim, for example, seems to display this correctly,
> > although it uses different quote prefixes by default.
>
> comparing apples with oranges? ;-)
Probably, just thought that might eliminate some possible causes.
Maybe not.
--
John
Strange multi-color quoting behavior
With different colors set for different quote levels:
color quoted blue default
color quoted1 magenta default
color quoted2 red default
and using the default $quote_regexp and Mutt's built-in pager,
why do the following lines show up in different colors?
> This is in "quoted" color
| This is in "quoted1" color
: This is in "quoted2" color
} This is in "quoted" color
# This is in "quoted1" color
> This is in "quoted" color again
Shouldn't they all use the "quoted" (first level) color, since
they are all first-level quotes?
It seems when the _leading_ quote prefix changes, the color
sequence is not reset, but continues where it left off, and going
back to the first leading quote prefix ("> " above), resets it
again. (Vim, for example, seems to display this correctly,
although it uses different quote prefixes by default.)
--
John
Re: Please help me with getting a thread view
* On Fri, 10 May 2002, Ricardo SIGNES wrote: > On Sat, May 11, 2002 at 10:15:21AM +1000, [EMAIL PROTECTED] > wrote: > > when in a folder. Can someone please tell me how to get the > > threaded view where arrows are used to indicate a thread. I > > have seen some example pictures on the web, but I cannot find > > the appropriate settings in the muttrc file. > > Press 'o' in the message list to change the sort method. The corresponding .muttrc variable would be "sort", e.g.: set sort=threads -- John
Re: header patterns
* On Thu, 09 May 2002, Will Yardley wrote: > why does this work: > color index red default ~h"^X-Spam-Flag" > > but not this: > color index red default ~h"^X-Spam-Flag: YES" I think the quoting is wrong and there's no error with the first one because there aren't any spaces in the expression. This should work: color index red default '~h "^X-Spam-Flag: YES"' -- John
Re: Selecting a mailbox
* On Wed, 01 May 2002, [EMAIL PROTECTED] wrote: > Yep. This has been happening to me. Are you running a stable > release? I'm running a cvs version, "1.5.0i (2002-01-22)". I > figured the bug was just in the alpha version. (Re-directing back to the list) I'm running plain 1.3.28i with no patches, and I'm pretty sure I remember this behavior on earlier versions as well. I don't think Dean mentioned his version. Also, to clarify: You don't actually need to receive new mail in "mailbox 2" for this to happen. It's actually like this: - C(hange) from mailbox 1 to the folder list. - Mail arrives in mailbox 1. - Highlight a mailbox other than 1 and press . - Mutt takes you back into mailbox 1 to see the new mail. -- John
Re: Selecting a mailbox
* On Tue, 30 Apr 2002, Dean Richard Benson wrote: > However I have a weird problem (or maybe its a feature! ;) that > is bugging me. If a few folders have new mail in, I select one > that I am wanting to read first, and move the cursor down to > that folder and press enter. Most of the time that works, > except sometimes it seems to "jump" to the mailbox that also > has new mail in completely ignoring the line I had selected. > > Does anyone know a way around this, or have the same problem > too? I have seen something like this. Does it always jump to the last mailbox you had open? Here is how I remember it happening for me: - You switch from mailbox 1 back to the folder list. - You receive new mail in mailboxes 1 and 2. - You try to enter mailbox 2, but mutt takes you back into mailbox 1. Mutt seems to consider that you never really left mailbox 1, so it wants to show you the new mail in your "current" mailbox, I guess. -- John
Re: color depending on To:
* On Mon, 29 Apr 2002, Flavien wrote: > I must be missing something. It does not work here... :-( Actually, it was me who was missing something. I'm using "color index" to match my old addresses, not "color header". So I'm coloring the matched messages in the index, rather than coloring the headers in the pager. Sorry about that. I see the same problem you are having when I try "color header". It seems like mutt will color all the lines of a matching multi-line header, but the matching pattern must be in the first line. -- John
Re: color depending on To:
* On Sun, 28 Apr 2002, Flavien wrote: > I have som old addresses that some people still have in their > address-books. I'd like to spot these people by colorizing the headers > when matching one of those addresses. It works pretty well with : > > color header red black 'To:.*myoldlogin\@myoldaddress\.com' I use ~C for this and it seems to work fine, even when the address isn't on the first line of the To: header. Try this: color header red black "~C myoldlogin\@myoldaddress\.com" -- John
Re: macro: mark all new as read (was: toggle-read)
* On Fri, 26 Apr 2002, Im Eunjea wrote: > * John Iverson <[EMAIL PROTECTED]> [2002-04-25 13:40]: > > [...] > > > > > > > I'm using this: > > > > > > macro index "\Cx" \ > > > "~N*" \ > > > "Mark all boring new msgs" > > > > This malfunctions if there are no N(ew) messages by incorrectly > > setting N on the highlighted message. Note that you therefore > > can't run it twice in a row (unless you happen to get a new > > message in the interval). It will also set N on any non-N(ew) > > tagged messages. You should replace with > > N. > > why run twice? and I can see there N(ew) flag or not. (and you?) ;) You would not normally run it twice. I'm just using that to show that it fails when there are no New mails. The intention of the macro is to clear N flags (turn them off), not to toggle them. Also, if you have any tagged non-New messages when you run your macro, their N flags get turned back on. I'm sure it works with the way you use it -- I'm just suggesting how to make it more robust. > > I like Sven's version because it leaves the messages tagged so > > you can see which messages were affected, but no further action > > is required. The tags are cleared when you change mailboxes. > > > > that's why I using . I don't like leave tags there. I was talking about tagged messages, not the New (N) flag. If you just replace with N in your macro, it should work the same as before, without failing in the cases I mentioned. The * at the end will still clear the tags, right? -- John
Re: macro: mark all new as read (was: toggle-read)
* On Sun, 21 Apr 2002, Im Eunjea wrote: > * Sven Guckes <[EMAIL PROTECTED]> [2002-04-21 04:35]: > > [...] > > > > > copy+paste from vim? > > > > anyway - this can be wrong if 'T' means > > something else than .. :-( > > > > the following is a little longer - but should work > > even when the keys are bound to other commands: > > > > macro index \Cr \ > > "~N\nN" \ > > "Mark all new messages as read" > > > > Too bad there's no command. > > any takers? > > I'm using this: > > macro index "\Cx" \ > "~N*" \ > "Mark all boring new msgs" This malfunctions if there are no N(ew) messages by incorrectly setting N on the highlighted message. Note that you therefore can't run it twice in a row (unless you happen to get a new message in the interval). It will also set N on any non-N(ew) tagged messages. You should replace with N. I like Sven's version because it leaves the messages tagged so you can see which messages were affected, but no further action is required. The tags are cleared when you change mailboxes. -- John
Re: mutt maillist distribution via alias@domain
* On Fri, 19 Apr 2002, parv wrote: > > Why not Just use the regular OR operator?: > > when one has to debug complex recipe (as procmail doesn't say what > was actually matched), or during the creation of one, it's much > easier to work w/ weighted recpie as one can easily (un)comment & > test. Good point. > in addition, if both ^TO and ^TO_ had been used, it would be > easier to notice the difference in the weighted recipe. so, > maintainance is another issue. > > > and another reason: there is more than one way to do it. True. > > :0 * ^TOmutt(-dev|-users)?@(ns.)?gbnet.net|\ > > ^[EMAIL PROTECTED]|\ > > ^TOmutt(-dev|-users)?@.*(cs.hmc.edu|mutt.org|yahoogroups.com) > > IN.MUTT > > for trivial/short/simple conditions, i do prefer the above, but > then why use multiple ^TO's... Not needed, but this also might make it easier to comment out certain lines for testing, although you have to watch out for the "|\"s at the ends of the lines. -- John
Re: mutt maillist distribution via alias@domain
* On Fri, 19 Apr 2002, parv wrote: > all these can be easily combined as one OR'd recipe (assuming mbox)... > > :0: > # 000710 - catch messages from gateway address on sonytel.be > * 2147483647^0 ^TOmutt-users@mail\.sonytel\.be > # > # 981009 - catch messages from gateway address on gbnet.net: > * 2147483647^0 ^TOmutt(-dev|-users)?@(ns.)?gbnet\.net > # > # 000710 - added yahoogroups.com > * 2147483647^0 ^TOmutt(-dev|-users)?@.*(cs\.hmc\.edu|mutt\.org|yahoogroups\.com) > # > # below is the obvious combination of above two... > #* 2147483647^0 >^TOmutt(-dev|-users)?@((ns.)?gbnet\.net|.*(cs\.hmc\.edu|mutt\.org|yahoogroups\.com)) > # > IN.MUTT Why not Just use the regular OR operator?: :0 * ^TOmutt(-dev|-users)?@(ns.)?gbnet.net|\ ^[EMAIL PROTECTED]|\ ^TOmutt(-dev|-users)?@.*(cs.hmc.edu|mutt.org|yahoogroups.com) IN.MUTT -- John
Re: mutt maillist distribution via alias@domain
* On Fri, 19 Apr 2002, Rob Reid wrote: [ ... ] > Granted, this doesn't catch the other mutt lists (because I don't > need to), and IN.mutt would be a better name than muttin. > Return-Path works (for now anyway) and is "cheaper" than ^TO. My understanding is that some people prefer ^TO or ^TO_ to handle mail sent to both the list their personal address (See Fetzaa's posts above in this thread). Then the rule will catch both copies and put them both in the mutt folder. Now I'm wondering which of ^TO or ^TO_ is better to use? Being subscribed to only mutt-users, I am currently using "^TOmutt-". -- John
Re: Saving outgoing mail in current mailbox
On Sat 09 Feb 2002, David T-G wrote: > % The patch offers "^" as a shortcut to the current folder. > > ... so now you can just > > send-hook . "my_hdr fcc: ^" > > and there ya go. Cool, thanks for the info Michael and David. John
Saving outgoing mail in current mailbox
Hi, Is there a way to tell Mutt to save outgoing messages in whatever mailbox I'm working in? I'm currently setting "record" for each mailbox like this: folder-hook . "set record='=sent'" folder-hook box1"set record='=box1'" folder-hook box2"set record='=box2'" ... This works, just wondering if there's a shortcut I'm missing, maybe something along the lines of: folder-hook . "set record=." (which doesn't work). Thanks, John
