Re: SMTP Authorization
On 2002.02.23, in [EMAIL PROTECTED], Jerry Van Brimmer [EMAIL PROTECTED] wrote: . pop_authenticate: Using any available method. AUTH CRAM-MD5 + PDMyNzU3LjEwMjAyMjMxMjUzMzRAaXNwd2VzdGVtYWlsLmFjZXdlYi5uZXQ+ mutt_sasl_cb_authname: getting authname for pop3.ispwest.com:110 mutt_sasl_cb_pass: getting password for [EMAIL PROTECTED]@pop3.ispwest.com:110 amVycnl2YkBpc3B3ZXN0LmNvbSAxNGI0MjNiMmQ5ODQyNGNjYjY2OTNhZDM2MWM0MTBlMg== +OK jerryvb's mailbox has 665 message(s) (2526032 octets) SASL authentication failed. APOP [EMAIL PROTECTED] c6157f678c257df79923897ddf14ab04 -ERR unknown or invalid command in this state [APOP] APOP authentication failed. USER [EMAIL PROTECTED] -ERR unknown or invalid command in this state [USER] Login failed. USER: unknown or invalid command in this state [USER] This seems like a disagreement between what happens and what mutt expects to happen. You're authenticating using CRAM-MD5, and the POP server is validating the authentication. Then mutt thinks that is rejected it, so it tries other authentications, which the server does reject, since it's not expecting an authentication anymore. In other words, this looks like a mutt bug. You might try setting $pop_authenticators to work around this. The goal would be not to try authenticating with MD5 -- for example: set pop_authenticators=apop:user -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: SMTP Authorization
On 2002.02.25, in [EMAIL PROTECTED], David Champion [EMAIL PROTECTED] wrote: In other words, this looks like a mutt bug. You might try setting $pop_authenticators to work around this. The goal would be not to try authenticating with MD5 -- for example: set pop_authenticators=apop:user Oops, I mean that you want not to authenticate using SASL, so you could try this: set pop_authenticators=digest-md5:apop:user -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: SMTP Authorization
On 2002.02.23, in [EMAIL PROTECTED], Jerry Van Brimmer [EMAIL PROTECTED] wrote: Well, I thought Mutt was a terminal based email client that could as much or more than other email clients. So, I was hoping that I could just download all messages into my mailbox and the headers would be displayed in the index, sort of just like all others, i.e. Sylpheed. I thought Mutt was a downloader/reader all in one? Am I wrong? No, you're quite correct. Some people just prefer to use external programs to do the same thing. Since there's something apparently going wrong with mutt's built-in support, they're offering alternative approaches. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Deleting attachments from a message
On 2002.02.20, in [EMAIL PROTECTED], David Ellement [EMAIL PROTECTED] wrote: On 020220, at 18:00:45, Stefan Frank wrote It doesn't seem to work when dgc's attachment patch is applied. I checked this against an unpatched mutt - it stopped working after the patch was applied (mutt-1.3.23.dgc.attach.2 in my configuration). This was fixed in mutt-1.3.23.dgc.attach.3. Yes, this is correct. Unfortunately, I neglected to update my web page, so I'm not sure that anyone but David knew about it. :/ I've just done so: http://home.uchicago.edu/~dgc/mutt/#attach -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: locale for Sun
On 2002.02.20, in [EMAIL PROTECTED], Aaron Schrab [EMAIL PROTECTED] wrote: At 14:15 -0800 20 Feb 2002, Mun Johl [EMAIL PROTECTED] wrote: I tried another test and fired up mutt in dtterm instead of rxvt. dtterm displayed the umlauts correctly, so I don't understand why the characters get messed up in rxvt when I use the same locale settings. Sounds like rxvt is using a font for a different character set than that specified by your locale settings. For Solaris, I *highly* recommend the xterm source tree that Thomas Dickey maintains. http://dickey.his.com/xterm/ I've tried aterm, wterm, Eterm, native xterm, dtterm, rxvt, commandtool (et al.), gnome-terminal, and at least one other terminal app on Solaris (besides Terminal.app itself :)), and only this xterm has given me color with no pain. Well, except that it crashes whenever I try to use an xterm menu under en_US.ISO8859-15. That's a little weird, but I'm not too stuck on the euro symbol. And I see 15 new patch-levels since I last installed it, so emaybe that's resolved. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Any mailbox cleaner program?
On 2002.02.19, in [EMAIL PROTECTED], Justin R. Miller [EMAIL PROTECTED] wrote: If not, I'd just use a Mutt call with -f and push in a delete pattern to clear out the old stuff. This won't work from a crontab, though. When mutt has no terminal, it ignores -e actions and acts as a mailer, like /bin/mail. One so inclined could presumably write a little program to create a pty whose master is attached to /dev/null, under whose slave mutt could run with a terminal. It would actually be a pretty handy tool. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago Colons and slashes and dots, oh my!
Re: arrggh, print hell [little OT]
On 2002.02.14, in [EMAIL PROTECTED], Nick Wilson [EMAIL PROTECTED] wrote: I've just had to print an entire mbox file, it wasn't that many messages but it was a painful process as I didn't think of a way to only print the /actuall/ message bodies (and perhaps TO, From) I just did: $ lpr mymboxfile What might I have done? - open the mailbox in mutt - tag all (T.enter, I think? I don't use normal bindings.) - print all tagged items (;p) - quit Using mutt isn't necessary, of course, but it lets you apply mutt's header weeding. If $print_split is set, mutt will print each message as a separate job. If it's unset, the messages will be concatenated into your print command. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago Colons and slashes and dots, oh my!
Re: killing and scoring
On 2002.02.13, in [EMAIL PROTECTED], Andre Berger [EMAIL PROTECTED] wrote: My setup (below) tells procmail to source the addresses in ~/.procmail/spam, and add the message to my spam/ Maildir: Looks like you have a file (~/.procmail/spam) containing e-mail addresses of people you want to block. So... Now, couldn't I extend the macro somehow to also add the sender to ~/.mutt.score, like score '~f [EMAIL PROTECTED]' - ^^^sender at the same time the address is added to ~/.procmail/spam? ... I'd create a script like this: $ cat muttscore.sh #!/bin/sh cat $HOME/.procmail/spam | while read addr; do echo score '~f $addr' - done ... and source that from your muttrc: source muttscore.sh| -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago Colons and slashes and dots, oh my!
Re: Wish about mutt's file browser
On 2002.02.04, in [EMAIL PROTECTED],
Charles Jie [EMAIL PROTECTED] wrote:
- If you code something to achieve it, you lose the COLORs.
But losing the colors is a *good thing*. :) color_ls hurts my eyes.
Ouch.
*3. Mutt's file browser - also mix up directories and files, which hurts
eyes.
- We also want an option to IGNORE the cases of file/folder names in
sorting.
- any patch can help?
Here's a simple patch that makes the browser's string collation sort
according to the user's locale. (It just defines a mutt_strcoll() and
makes the browser's string collator use it instead of strcmp().)
This will probably do what you want, and it's probably the right thing
for mutt to do here, IMO.
Patch is against mut 1.3.27 but probably applies nicely on many
versions, since it affects relatively stable code.
--
-D.[EMAIL PROTECTED]NSITUniversity of Chicago
Colons and slashes and dots, oh my!
diff -Pur mutt-1.3.27-base/browser.c mutt-1.3.27/browser.c
--- mutt-1.3.27-base/browser.c Tue Dec 18 09:12:48 2001
+++ mutt-1.3.27/browser.c Mon Feb 4 11:49:24 2002
@@ -75,7 +75,7 @@
struct folder_file *pa = (struct folder_file *) a;
struct folder_file *pb = (struct folder_file *) b;
- int r = mutt_strcmp (pa-name, pb-name);
+ int r = mutt_strcoll (pa-name, pb-name);
return ((BrowserSort SORT_REVERSE) ? -r : r);
}
diff -Pur mutt-1.3.27-base/lib.c mutt-1.3.27/lib.c
--- mutt-1.3.27-base/lib.c Mon Feb 12 04:30:08 2001
+++ mutt-1.3.27/lib.c Mon Feb 4 11:49:24 2002
@@ -584,6 +584,11 @@
return a ? strlen (a) : 0;
}
+int mutt_strcoll(const char *a, const char *b)
+{
+ return strcoll(NONULL(a), NONULL(b));
+}
+
const char *mutt_stristr (const char *haystack, const char *needle)
{
const char *p, *q;
diff -Pur mutt-1.3.27-base/lib.h mutt-1.3.27/lib.h
--- mutt-1.3.27-base/lib.h Thu Jun 7 15:00:05 2001
+++ mutt-1.3.27/lib.h Mon Feb 4 11:49:24 2002
@@ -107,6 +107,7 @@
int mutt_strcmp (const char *, const char *);
int mutt_strncasecmp (const char *, const char *, size_t);
int mutt_strncmp (const char *, const char *, size_t);
+int mutt_strcoll (const char *, const char *);
int safe_open (const char *, int);
int safe_symlink (const char *, const char *);
int safe_rename (const char *, const char *);
Re: [feature requests] bcc and sent mailbox
On 2002.02.01, in [EMAIL PROTECTED], Will Yardley [EMAIL PROTECTED] wrote: William Wu wrote: sometimes, I send some mails with bcc field filled, but in the sent mailbox the recipients are not showed, that's why it's called Bcc (blind carbon copy) This sort of dodges one solution, though, which is to retain the bcc: header on locally-filed copies (while leaving it out of those pumped into the MTA). I actually prefer this approach, having gotten used to it on some other mailer I used to use. Mutt can do it, too: set write_bcc in your .muttrc. But note that this makes mutt send the Bcc: header to your MTA, too. If your MTA filters it out, that's ok, but if it does not, you might want to wrap your MTA in a script or just avoid this setting. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: coloring ~N by way of external file query?
On 2002.01.31, in 20020201045411.GB18136@ganymede,
Brian Clark [EMAIL PROTECTED] wrote:
IOW, I'm trying to replace these (a lot more than 3):
color index yellow default ~f feefee ~N
color index yellow default ~f geegee ~N
color index yellow default ~f heehee ~N
With one line that gets the list from a file (via grep?).
How about:
$ cat addrs.txt
feefee
geegee
heehee
$ cat dynacolor.sh
#!/bin/sh
awk '{printf(color index yellow default \~f %s ~N\\n, $1);}' addrs.txt
$ tail -1 .muttrc
source dynacolor.sh|
--
-D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Kill mails automaticly
On 2002.01.27, in [EMAIL PROTECTED], Sven Guckes [EMAIL PROTECTED] wrote: * JASH [EMAIL PROTECTED] [020127 17:46]: Is it possible to kill the last oldest messages in Maildir automaticly, for example if mails past 1000 already? yes. but mutt won't do this unless you start it yourself. besides of this - mutt is not the tool for this. hint: maildir format + cron + fileutils I'm not sure about this. The mtime on a maildir message file does not have to be the same as the delivery date of the message, Unixly speaking. Does the maildir specification (ahem) or mutt's implementation actually guarantee this to a point sufficient to delete mail without worry? P.S. I always forget which GNU programs fileutils are. Perhaps that's because they're not installed on my computer, but it seems more useful to mention them by name, either way. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Stripping Sigs
On 2002.01.24, in [EMAIL PROTECTED], matthew pritchard [EMAIL PROTECTED] wrote: Is it possible to strip signatures when replying to mails? Slrn seems to automatically do this for me 'out of the box' (There's a strip_sig_regexp variable). I've searched on google, and the best I could come up with is a vi macro: map _qs G?^^M?^ -- $^Md} but this isn't what I'm after really. I want mutt to do it for me. set editor=vi '+/^-- $/;,$d' You should post this kind of question to [EMAIL PROTECTED] instead . Reply-To: set . -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Stripping Sigs
On 2002.01.24, in [EMAIL PROTECTED], David T-G [EMAIL PROTECTED] wrote: Matthew, et al -- ...and then David Champion said... % % set editor=vi '+/^-- $/;,$d' Note that this will actually strip your signature and not that of the original email. Given your macro example above, I deduce that your $indent_string= and so your $editor command should probably look about like set editor=vi '+/^ -- $/;d}' Oops. Mea culpa; pre-frontal cortex on holiday. I'm not sure that this command will work, though. (It doesn't in straight vi, because d} is vi syntax, but initialization commands need to be ed or ex commands.) I'm liking set editor=vi '+/^[%] -- $/;,/^[^%]*/d' right now. It handles David's quotation character, too. :) + begin vi init command /^[%] -- $/search for a quoted signature indicator ; separate first init command from second , create a range from the current location up to... /^[^%]*/ ... the next occurrence of an unquoted line d then delete that range -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: macros or hook?
On 2002.01.24, in [EMAIL PROTECTED], Nick Wilson [EMAIL PROTECTED] wrote: * and then Maarten den Braber blurted Maybe it's A Good Thing to give an example to ;-), here it is: bind index r noop bind index m noop What's a noop? No-op: no operation [on this cycle :)]. macro index m :set editor=\vim -c ':0;/Subject'\\\nmail macro index r :set editor=\vim -c ':0;/^$'\\\nreply Hmmm Yeah, I getcha. How does mutt know how to reply/compose as well though? Is that them noop buggers? The \n terminates the :set editor command. It's the same action as pressing the ENTER key. mail inside a macro tells mutt to execute the mail function. This is bound to m by default. Most people probably write their macros with keystrokes -- like : for enter-command, and m for mail -- but using the binding names makes your macros more universal, should you wish to share them or to change your own bindings later in life. You could also write these macros as: macro index m enter-commandset editor=\vim -c ':0;/Subject'\entermail macro index r enter-commandset editor=\vim -c ':0;/^$'\enterreply (to use binding names for all special keystrokes), or as: macro index m :set editor=\vim -c ':0;/Subject'nm macro index r :set editor=\vim -c ':0;/^$'nr to use keystrokes and no binding names. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Why sign posts on mailinglists?
On 2002.01.24, in [EMAIL PROTECTED], Mike Schiraldi [EMAIL PROTECTED] wrote: also, since most people on the list don't know you in real life, all they know is that you're the same person who has always been writing email under that name and with that PGP key. there's no real advantage to doing this IMHO in most cases. I disagree -- if Thomas didn't sign all his messages, i could write a message to this list, pretending to be him, and say, Hey, there's a problem with mutt. You should all immediately apply the following patch. And don't worry about checking to make sure that it's not a trojan horse; after all, i'm Thomas. You can trust me. Thomas *doesn't* sign all his messages. I'm happy with that; he signs patches and other messages which regard potential threats to mutt's code base. PGP certainly should be used when the message requires some trust. I don't think you'll find many people (if any) arguing with that. What's at issue is: when is trust required? Some feel that it's always required to ever be useful; others think it's only required on occasion. But we've been over it many times on this list, and perhaps it's time to talk about Mutt. I apologize for posting on this subject, but the incorrect information seemed to be a bit of a threat. :) (I'd sign this message, but my key is currently expired.) -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Editing a set of Subject lines
On 2002.01.22, in [EMAIL PROTECTED], Jim [EMAIL PROTECTED] wrote: Is there a graceful way to change the Subject: lines on a set of tagged messages? Often folks will change the ... I tried the '|' pipe function, ;|... piping to: sed 's/^Subject: .*$/Subject: Re: This Thread.../' You could try writing a macro that sets $editor to a shell script that: a. filters its $1 argument through a suitable sed command (I'd prefer formail, personally), then replaces the original $1 file; b. invokes edit c. sets $editor back to its default value Your script could even prompt for the new subject line. Hmm -- something like: macro index Z enter-commandset editor='mutt-subject-munge'entereditenter-commandset editor='the-one-true-editor'enter % cat $HOME/bin/mutt-subject-change #!/bin/sh umask 077 echo Enter the new subject: \c read subject formail -i Subject: $subject: $1 $1.2 mv -f $1.2 $1 All untested, of course. No warranties. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: saving messages to a file
On 2002.01.23, in [EMAIL PROTECTED], Richard G. Ball [EMAIL PROTECTED] wrote: #!/bin/sh mutt -nz -F $HOME/.mutt/mutt.archiving -f test-folder -e push 'T~d -01/01/02 ;s archivetest q' but it isn't *quite* working. The file to which the messages are written isn't archivetest but rather archivetest prepended with the user address from the first selected message. I tried turning the various variables associated with filenames off (in mutt.archiving): Looks like your push sequence is just appending to the default name already in the edit buffer. One way around this would be just to put a kill-line as the first binding after the ;s. mutt -nz -F $HOME/.mutt/mutt.archiving -f test-folder -e \ push 'tag-pattern~d -01/01/02\ entertag-prefixsave-messagekill-linearchivetest' (I've replaced your keystrokes with the binding symbols, for portability.) -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: multipart/alternative
On 2002.01.23, in [EMAIL PROTECTED]>, "Nick Wilson" [EMAIL PROTECTED]> wrote: > 'ello > What kind of monster is would a message containing multipart/alternative > be? Is there somewhere that gives idiots guides to mime types? It's a multipart type that provides multiple alternative views of what the sender alleges to the the same content, using two different presentation types. For example, I can send you a message in text and HTML by using a multipart/alternative part containing within its envelope a text/plain part and a text/html part. (But, as you see, Ican hoodwink you by placing different material in one part than in the other.) -- -D. [EMAIL PROTECTED] NSIT University of Chicago
Re: how to change xterm title depending on current mailbox
On 2002.01.22, in [EMAIL PROTECTED], John Buttery [EMAIL PROTECTED] wrote: By the way, is there any way to get mutt to start composing _after_ the quoted text instead of before it when replying? set editor=vi '+$;?^?;+' + begin vi initialization commands $ go to end of file ; end of first command ?^?search backward for line beginning with ; end of second command + move ahead one line -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Bold text
On 2002.01.21, in 20020121164625.GB2845@neuromancer, giorgian [EMAIL PROTECTED] wrote: On Mon, Jan 07, 2002 at 12:35:15PM -0600, David Champion wrote: This message is in enriched text. Here's some text in boldfaced type. Here's italic. You can also do formatting -- you can everything works for me (mutt 1.3.25) but the italic (i saw it underlined) and justified text (which was left justified)... Hmm. I'll have to try this out after I upgrade, but I suppose it's possible that it doesn't work for me for the same problem that RFC2047-encoded headers completely whack out my display, and multibyte characters sometimes spin the pager into an infinite loop from which only GDB can recover. (It appears that something has changed in the OS I'm running, and I don't have the savoir-faire to figure out what or why or how to fix it. If anyone reading this does, I'd still appreciate pointers on what to look for.) -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: mailinglist-prefix in index_format
On 2002.01.19, in [EMAIL PROTECTED], Thomas Hurst [EMAIL PROTECTED] wrote: * Michael Elkins ([EMAIL PROTECTED]) wrote: Hanspeter Roth wrote: Some mailinglists prefix every subject with the name of the list. Is it possible to suppress this prefix in the index_format? How? Or is this a case for procmail? It's more efficient to do it with procmail since you only have to do the operation once at delivery time. Some of us are alergic to subject mangling like this (and there's no knowing what the mailing list will do if we strip it entirely); and Unfortunately, there's no knowing what the list will do if you keep it, either. Some of them misbehave then, too. So I strip it; the lists cope. I strip the labels on such messages as they arrive in my inbox, copying the original Subject: to Old-Subject:, but I keep the pristine message in the list archive's copy of the message. My procmail also copies a short expression identifying the list to the X-Label: header of my inbox, so that my index display shows it, and I can easily search on it, etc., without having the awful mess in the subject line itself. I also take out the [2] in Re[2]: prefixes. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: virus
On 2002.01.17, in 20020117164300.GB3131@knute, Knute [EMAIL PROTECTED] wrote: response to one I posted from [EMAIL PROTECTED] that had a virus attached to it (.mp3.pif). LOL... That's not even a virus, it's a shortcut to the executable! Viruses/worms can be embedded in a .pif file. The point of using .pif is that Windows software frequently considers it to indicate executable content that should be automatically executed when double-clicked. Irregularities in the PIF data can cause the OS to run other code. SIRCAM rides this horse, in addition to others. I just got a .scr file from the same address. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Ispell is too quiet when run from the Compose menu
On 2002.01.13, in [EMAIL PROTECTED], David T-G [EMAIL PROTECTED] wrote: I don't necessarily agree that mutt should spit out a message, though I can see that this could be confusing. What I would do would be to go ... % Feedback is an important element of any user interface, GUI or % text-based, UNIX or not. Yes, but so is providing only the right amount, rather than too much or too little. Consider running mutt on a remote server that you're connected to over a slow or high-latency line, or one prone to dropping link. You press 'i'; did [ia]spell complete with no errors, or has it not run yet? It might be hard to tell: if the link is indeed slow, it can take more time yet to get a response to other activity, and instigating this activity just to check the status of ispell is a larger waste of precious bandwidth than a mere No spelling errors found message. The key here is usability. Adherence to the so-called Unix philosophy is false if it makes the tool in question less usable. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: nntp in mutt
On 2002.01.12, in [EMAIL PROTECTED], Rob 'Feztaa' Park [EMAIL PROTECTED] wrote: Which manual? The man page for the muttrc just says that %g expands to the newsgroup if mutt is compiled with nntp support, there is nothing else about nntp in there. The mutt man page shows: -G Start Mutt with a listing of subscribed newsgroups. The manual (manual.txt) shows NNTP information in section 2.7, 3.18, and in several 6.3.x sections concerning variables containing nntp and news in their names. 6.3.106 talks about the URL-like syntax supported as a folder naming syntax: nntp[s]://news.server.name/news.group.name -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Mutt: aliasing IMAP servers?
On 2002.01.09, in 1010610421.2294.0.camel@panucho, Ilkka Tuohela [EMAIL PROTECTED] wrote: =company/business which will be translated to imap://imap.company.com/Mail/business =private/brother and a folder like imap://isp-imap.isp.com/Mail/brother ... Of course this would have to mask folders private and company in local folder space, maybe we could use for example $ instead of = or something like that. If you're willing to do that, maybe you're willing to use macro editor '$company' 'imap://imap.company.com/Mail/' macro editor '$private' 'imap://isp-imap.isp.com/Mail/' -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Can't send mail from my profile
On 2002.01.08, in [EMAIL PROTECTED],
Nick Wilson [EMAIL PROTECTED] wrote:
Sounds fine to me Sam, I don't know what VISUAL is though?
I presume it's a config var, I'll go look it up on the manual.
Is that why I sometimes see headers with X-editor: Vim?
How will other apps know what I prefer if this is a mutt thing?
To add a little to this: EDITOR and VISUAL are common environment
variables, and are not particular to any program, application, or suite.
They're just traditional variables for specifying your preferred editor
in. Traditionally, EDITOR should specify a line editor, and VISUAL
should specify a full-screen editor. Not many people use ed, ex, and the
line anymore, though, so it's common to use them interchangeably for
full-screen or graphical editors now.
A common Bourne shell idiom is this:
editor=${VISUAL:-${EDITOR:-vi}}
...
${editor} ${filename}
which illustrates the relationship: first use $VISUAL if it is defined,
because a full-screen editor is usually preferred; then use $EDITOR if
$VISUAL is not defined or is empty. If neither is set, fall back on vi,
because one can almost always rely on its being present even when other
screen editors are not.
But many programs refer to these variables for your editor preferences,
so if you pretty much always want the same editor, it's promising to set
$VISUAL and $EDITOR to your favorite.
--
-D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Deleted Messages
On 2002.01.08, in [EMAIL PROTECTED], Todd Kokoszka [EMAIL PROTECTED] wrote: I want messages to disappear after I mark them deleted or saved. Is there a way to do this in Mutt? When the view limit is set to !~D, deleted message are present, but not visible in the index view. Unforunately, the limit is only applied when you set a limit, not continuously, so you need to re-apply the limit with each deletion. macro index d delete-messagelimit!~Denter You'll still need to sync-mailbox ($) to remove them from the folder, but using limit is much faster than synchronizing after each delete. I like my deleted messages to fade away, too, but using a limit is a little more trouble than I want (I can't really use other limits this way) and I sometimes want to find messages marked for deletion again before I sync. So I just use colors, instead. color index brightblack default ~D My terminal background color and my brightblack are similar colors, so deleted messages take extra effort to find -- they effectively vanish from casual view, while remaining present if I really want to find them. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Bold text
On 2002.01.07, in [EMAIL PROTECTED]>, "Nick Wilson" <[EMAIL PROTECTED]> wrote: > Yes I mean /like/ HTML, but *not* HTML as I dump anything of nature > also. I guess my understanding of real ASCII text is mistaken. I thought > that because I saw bold text in mails sent to me (back when I was > exclusively using Eudora under Win) that I could do the same. I guess > they were some kind of HTML thing. You could use enriched text. It's documented in RFC 1563: ftp://ftp.isi.edu/in-notes/rfc1563.txt It's HTML-like, without being HTML, and it could be what you've seen in Eudora. Eudora used to send enriched text when you applied styles, I think. Now it just sends HTML (badly), but it still can interpret enriched text (badly). This message is in enriched text. Here's some text in boldfaced type. Here's italic. You can also do formatting -- you can center text, and right-justify it, and align it evenly to both sides, although the line breaks get a little quirky. I suppose you need enough text to fill out at least two whole display lines to make this example work to any visible effect. Here's a little more noise, just to take up extra space for demonstration purposes. You can also do color: red text, and green text, and blue text -- all eight ANSI text colors are supported in mutt, at least. (Actually, I'm not entirely sure that mutt's enriched handler is handling this correctly. Colors and bold/italics work, but only with an external pager, not with the builtin pager. Left, center, and right alignments work in either, but full-flush alignment does not. Thomas, this seems like a bug, but this is the first time I've played with enriched text, and I could be off base. I'm using 1.3.24 at the moment.) Watch what happens if you resize your viewing window and re-display the message! All enriched text is flowed by default. I'm not sure what the best way to *create* enriched text is, though. Presumably you'd want some kind of graphicky editor, but I don't know squat about those. -- -D. [EMAIL PROTECTED] NSIT University of Chicago
List noise [was Re: signed emails, why ?]
On 2002.01.07, in [EMAIL PROTECTED], Benjamin Reed [EMAIL PROTECTED] wrote: Gary Johnson [[EMAIL PROTECTED]] wrote: - there's just too much noise I don't know what to do about that, except to post less often myself. And, ironically, he mailed the list to tell us why he's unsubscribing instead of just unsubscribing. =) I don't think it's ironic, just excusably off-topic. But it's true, and it needed to be said sometime. I've considered unsubscribing a number of times, myself, but I'm not quite to that point yet. However, when my 550-600 messages per day finally gets to be too much, which list will fall off first? That's right, the one with 50-75 messages per day, seemingly a third of which are social in nature, or questions about vim or other software that is not mutt. Indicating that a problem exists hardly comprises noise in itself. I expect this will be my only complaint on the subject, but I've long felt that the issue deserved a little attention. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Send-hook is Lazy
On 2002.01.07, in 20020107113541.GA629@shanti, Franco Vite [EMAIL PROTECTED] wrote: before my browser was 1 r L 29 dic [MaX] 0,3K Archivi ML PPC? 2 F 30 dic [Franco Vite] 0,8K Now is 1 r L 29 dic [MaX] 0,3K Archivi ML PPC? 2 F 30 dic [To Linuxppc Use] 0,8K Why? PS Linuxppc User is the name of mailing list Have you changed your value of $alternates? If the sender's name matches $alternates, and your $index_format has %F in that slot, it will expand to the recipient's name instead of to your name. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Cross folder macro
On 2002.01.07, in [EMAIL PROTECTED], Michael Montagne [EMAIL PROTECTED] wrote: I have a macro that deletes older messages in the current folder. macro index F2 T~d2w !~FenterD~Tenter Does anyone have any idea how I might apply this to all my folders with one blazingly fast keystroke? I usually do things like this: cd $HOME/Mail for folder in *; do mutt -f =$folder -e push 'tag-pattern~d 2s !~Fenterdelete-pattern~Tentersync-mailboxyexit' done YMMV, depending on the settings of certain variables. Best to try it out on a single folder first. Since you already have it bound to a keystroke, you could probably shorten it a lot. :) -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: help a now confused mutt newbie
On 2002.01.03, in [EMAIL PROTECTED],
rhad [EMAIL PROTECTED] wrote:
1) understand how exactly mutt recieves email. In my first several
attempts, I slowly gathered the impression that mutt wanted me to configure
at least sendmail and fetchmail in addition to mutt. I.e.: that mutt acts
only as a viewing agent to the standard unix mail programs. In the
successive attempts to understand sendmail and fetchmail (neither of which I
have ever used--at least knowingly) I have become slightly lost. The mutt
manual delves, IMHO, more into mutt configuration and uses, than actually
explaining how the heck to get it to recieve email.
I find it easier to think in simpler terms, just looking at definitions
and relationships. Mutt reads mail folders (it doesn't receive mail from
SMTP), and it hands off new mail to an MTA (it doesn't inject mail into
SMTP). A folder can be stored on your local filesystem, or it can be
stored on a networked mail server and read via a mail access protocol
(POP3 or IMAP) -- not the same as mail delivery!
To get new mail into your folders, you need other software. That
software can be a common unix mail delivery agent like mail.local,
procmail, deliver, maildrop, etc. Or it can be a program for downloading
mail via an access protocol, like fetchmail. (There are other favorites,
but I always forget their names.) Or it can be the delivery software
on your mail server, which feeds your POP and IMAP folders themselves.
So, to get new mail, you need at least one of three things:
1. A mail delivery agent (MDA) to pass messages from the mail
transport agent (MTA) to a folder;
2. A program like fetchmail to pull messages down from a POP3 or
IMAP server;
3. A mutt configuration that allows mutt to read messages directly
from POP and IMAP message stores.
Chances are that you already have at least one of these available, if
you've ever used a mail program on the same system as mutt is on.
2) Is there somebody out there who would not mind a potentially lengthy
email-fest to help me figure this out? I have (what I consider) to be a
rather weird setup:
I want mutt to handle three email accounts: this one, at my university, and
2 yahoo accounts. I do not live at the university, but am on DSL in the
surrounding area. Therefore, I have one dedicated outgoing mail server for
all of the accounts (swbell-DSL), and 3 pop servers for incoming mail. I
use suse linux 7.3, and I keep all my machines behind a NAT-based router
with a static IP.
My workstation has an SMTP server on which I receive most of my mail.
It uses sendmail plus procmail to deliver mail into a wide assortment
of folders in my home directory. I also have one IMAP account and seven
POP3 accounts. I check the IMAP account only occasionally, but I want
the POP3 accounts to give me mail on fairly short order. Here are some
ideas that come from my setup.
Reading from local folders
--
Normally I just run mutt with defaults:
$ mutt
Mutt starts up on my local inbox, which is where all the new mail I care
to read lands. Procmail stores some messages elsewhere, but I don't
generally worry about those until some external stimulus makes me.
When that happens, I read the other folder:
$ mutt -f =ignore
or I change to it from inside mutt by pressing c and entering
=ignore.
Direct IMAP
---
I use a relatively recent 1.3 version of mutt, so the IMAP and POP
support is a little different from 1.2.5's. My mutt setup reads mail
from my inbox ($MAIL -- /var/mail/username) by default, since most of my
incoming mail lands there. When I want to read mail from IMAP, I just
run mutt with different arguments:
$ mutt -f imap://imap.server.name/
or
$ mutt -f '{imap.server.name}'
(Actually I use it via SSL:
$ mutt -f imaps://imap.server.name/
but that doesn't matter -- I mention it only because it's great that
mutt supports it.)
POP3 via Fetchmail
--
To read my POP3 messages, I have fetchmail configured to download my POP
messages from all servers every 10 minutes. Fetchmail hands them off
to sendmail and then procmail so that they get processed by the same
procmail rules as my SMTP mail. Lines from my .fetchmailrc file look
like this:
poll pop.mail.yahoo.com protocol pop3 username USER password PASS \
smtp localhost
I have a line similar to that for each server I want fetchmail to
handle. And in my crontab, I have this:
0,10,20,30,40,50 * * * * /opt/bin/fetchmail /dev/null 21
This cron task makes my new POP mail come down every 10 minutes from any
of the seven POP3 accounts.
Direct POP3
---
In truth, I have more POP3 accounts, but I don't want these messages
saved to my workstation's disk -- I want to browse them remotely. So,
when I compiled mutt, I used the --enable-pop switch to enable POP3
browsing mode. (I also use --enable-imap, --with-krb5, and --with-ssl,
by the way.) With POP3 browsing,
Re: Working with mbox
On 2002.01.04, in [EMAIL PROTECTED],
Rob 'Feztaa' Park [EMAIL PROTECTED] wrote:
Alas! Cameron Simpson spake thus:
| I'm pretty sure I've seen this done somewhere, but I can't find it.
Well, it's indirect, but you could wrap mutt in a script which said:
#!/bin/sh
( cd $HOME/mail
when=`date +%Y-%m`
for mbox in *
do echo mbox-hook =$mbox \=archives/$when-$mbox\
done $HOME/.muttrc-auto
)
exec real-mutt-program ${1+$@}
and just source .muttrc-auto from .muttrc. Ugly but would work.
Interesting idea. I'm sure I've seen a better way to do it, though.
Perhaps I'll have to search the archives :)
I'm into overkill today.
You could put that in a script such as the one I've attached, and run
it from .muttrc like this:
source `$HOME/bin/mutt-prep folders=$HOME/mail`
This approach lets your mutt-prep script write anything muttrc-ish on
its stdout, and mutt will absorb it with no shell wrappers. The cmdline
eval lets your source line configure the script's parameters easily.
(You could do it with prefixed variables or /bin/env, but this makes
them local instead of environmental, fwiw, and it might be easier to
read.)
It's fundamentally the same idea, but you don't have to mess with
wrappers, at least. It feels a little neater, in some way I can't
explain.
--
-D.[EMAIL PROTECTED]NSITUniversity of Chicago
#!/bin/sh
##
## This emits muttrc commands on stdout. call it with
## source `/path/to/mutt-prep`
## in your .muttrc file.
##
## Set variables from cmdline.
eval $@
## Set defaults -- these can be overridden on the cmdline.
file=${file-$HOME/.mutt-runtime}
folders=${folders-$HOME/Mail}
## All output goes to $file. echo the filename first, so mutt can source it.
echo $file
exec $file
## Set mbox-hooks.
when=`date +%Y-%m`
(cd $folders
ls | sed -e 's#\(.*\)#mbox-hook =\1 =archives/\1-'$when'#'
)
## Set mailboxes (could be merged above).
(cd $folders
ls | sed -e 's#\(.*\)#mailboxes =\1#'
)
## Something to source an rc file if present.
try_source () {
for rc in $@; do
if [ -f $HOME/.mutt-$rc ]; then
echo source $HOME/.mutt-$rc
fi
done
}
## Source an NNTP config file if mutt has NNTP support.
if mutt -v | grep NNTP /dev/null; then
try_source nntp
fi
## Source a muttrc for this host or domain, if one exists.
try_source `hostname` `sed -e '1s/.* //;q' /etc/resolv.conf`
## Dynamically convert my pine addressbook to mutt format.
if [ -f $HOME/.addressbook ]; then
cat $HOME/.addressbook \
| awk '-F ' '/^[^ ]/{printf(alias %-20.20s %s %s\n, $1, $2, $3);}'
#^^^ that's a tab character
fi
## Add other runtime tasks as you like.
Re: Send-hook is Lazy
On 2002.01.03, in [EMAIL PROTECTED], Thorsten Haude [EMAIL PROTECTED] wrote: Well done, David, now I'm back to step one, $from-wise. Why is 'set from=' different from 'my_hdr From: '? $from was introduced in pre-1.0 times to work around problems with hooks and my_hdr. Something about setting my_hdr From: in hooks and being able to use $reverse_name properly. Once I understood it all, but these days I have to check the ChangeLog and trust in whatever it says. That's progress! :) Tue Jul 20 20:09:13 1999 Thomas Roessler [EMAIL PROTECTED] * init.h, send.c, alias.c, globals.h, init.c: As Aaron Schrab noted, patch-0.95.6.tlr.reverse_name.1 broke the use of my_hdr from send-hooks. This patch introduces a new variable $from which can be used to use a default sender address; to make this possible, a new variable class DT_ADDR is defined. We now have the following algorithm for determining the from address: - $from is used as the default from address, if defined. Otherwise, the local user name and (if the user wishes so) the local domain are used. - This address can be overridden by $reverse_name, if set. - Now, send-hooks are evaluated. - Afterwards, user headers are evaluated. In this step, the from header can be overridden using my_hdr From:. - When there is no real name, $realname is used for it. Note that, when the default from header is used and $from defines a real name, it takes precedence over $realname. A later change makes $from's value default to the value of the EMAIL environment variable. This modifies the first step of this algorithm. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Hope the patch for X-label editing can be merged into mutt soon
On 2002.01.01, in [EMAIL PROTECTED], David T-G [EMAIL PROTECTED] wrote: % % But because it's a sourcer-level patch that I need to % patch-compile-install. I'm afraid that might cause trouble with my % current installation from rpm package by Mandrake 8.1. Hmmm... That may cause you some problems. If you're feeling adventurous, you could download the SRPM and add the patch to that, then just use rpm --rebuild, or whatever. It's been several years since I made RPMs, so I'm not sure that's right. % % I'll wait some while for that rpm comes. Thank you. Don't hold your breath... From Mr. Champion's patch download page: ... Although the basic X-Label idea and code were absorbed into 1.3, these extended features were not, so you should expect to re-apply this patch each time you upgrade Mutt. Thomas's feeling was that the x-label editing was superfluous, since you can edit the field with edit-message and an editor macro. But the Mandrake people might be willing to include patches in their RPM -- perhaps you could write to them and ask. (BTW, I'll note that the '%y' expando conflicts with a recent patch from Mike Schiraldi, and the 'y' binding conflicts with catchup or something from Vsevolod Volkov's NNTP patch. Such is life -- just be forewarned.) -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Possible to add a user-defined field Keyword to read message before/when save?
On 2001.12.28, in [EMAIL PROTECTED], Charles Jie [EMAIL PROTECTED] wrote: Obviously I don't mean 'e' (edit) command count. The purpose of it is that I want to give keywords or category to read messages so that I can search them easier later. If I can add this field easily when I save it or before I press 's' with ease, I don't bother to save messages into that many folders. :) The X-Label: header is regonized for this purpose. %y expands it in the index view, if you like, and ~y searches on it. It's supported in the 1.3 series, but you need a patch for 1.2. The basic support in 1.3 only provides recognition of the header, not editing. (You edit it using edit-message.) Another patch provides a binding (edit-label, 'y') to edit the header within mutt, with no external editor. I find this much easier to use, personally. All patches are at http://home.uchicago.edu/~dgc/mutt#x-label -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: colorize messages in index older then x days
On 2001.12.29, in 20011229142045.GA78483@noname, Paulius Bulotas [EMAIL PROTECTED] wrote: Hello, Is it possible to change colour of messages which are older by x days then today? If yes, then how it's done? Section 4.2.3 of the manual tells you. For example: color index blazing-red murky-green ~r 5d -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: OT: procmail recipe for two actions for a message?
On 2001.12.09, in [EMAIL PROTECTED],
Matej Cepl [EMAIL PROTECTED] wrote:
However, emails in this list have mungled Reply-To: directing to
the list. Could it be possible to ask procmail (or how to ask
procmail) that before moving the message to the listy folder, it
would run a message through grep -v '^Reply-To:'? And, BTW I do
not want just
:0:
* ^TOcstex
| grep -v '^Reply-To:' $MAILDIR/listy
because I would like to make it to work even when I would change
my mind and switched to maildir format. Therefore, I would
prefer, if the actual delivery would be done by procmail.
Maybe you've already decided on another approach, but I'd do it this
way. I use essentially the same formula for some list-munging of my own.
## No : needed, since there's no file to lock here
:0
* ^TOcstex
{
## First rewrite the reply-to using a known, safe mail-munging
## tool. Rename (don't remove) the header so there's a record of
## this event.
:0 f
| formail -R Reply-To Old-Reply-To
## Next append to the mail folder, with locking.
:0 :
listy
}
--
-D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: displaying name of attachment in title bar
On 2001.12.06, in [EMAIL PROTECTED], Prahlad Vaidyanathan [EMAIL PROTECTED] wrote: Hi, On Thu, 06 Dec 2001 Eric [EMAIL PROTECTED] spewed into the ether: Well I am not sure what you call that information bar above the pager. But would it not be useful if the names of the attachments of the current email were listed there - or is there another view in mutt that may achieve this. There is a patch (patch-1.3.23.dgc.attach.2), which you can find here : http://mutt.justpickone.org/mutt-build-cocktail/ That will give you the option of putting the number of attachments into the index. I've updated all my current patches, including this one, for 1.3.24. It can be found at its home site: http://home.uchicago.edu/~dgc/mutt http://home.uchicago.edu/~dgc/mutt#attach These patches include PATCHES file support, which was (re-)introduced in 1.3.23.2. FWIW, I apply patches in this sequence: patch-1.3.24.vvv.nntp mutt-1.3.24.dgc.attach.2 patch-1.3.24.rr.compressed mutt-1.3.24.dgc.xlabel_ext.4 mutt-1.3.24.dgc.deepif.1 mutt-1.3.24.dgc.isalias.1 mutt-1.3.24.dgc.markmsg.2 mutt-1.3.24.dgc.unbind.1 mutt-1.3.24.ats.mark_old.1 ...considering how to support Eric's idea in attach.3, without getting too far off the beaten-till-dead path -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Strange attachement
On 2001.11.27, in [EMAIL PROTECTED], Thomas Roessler [EMAIL PROTECTED] wrote: This probably depends on the particular uudecode implementation you are using... I've seen uudecode only decode the _first_ attachment. Some uudecodes even choke if there's any material in the input stream before the begin line. These wouldn't accept a full mail message very nicely. OTOH, it's been a long time since I noticed one of these; maybe they're all extinct. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Strange attachement
On 2001.11.26, in [EMAIL PROTECTED], Patrik Modesto [EMAIL PROTECTED] wrote: There is no Content-Type header. There is: ... then few empty lines and then the encoded file above. I can get to the PC that sends this attachments so I will check it's MSOE setup. It's not naturally MIME, but if you can always assume that uuencoded content from MSOE is supposed to be an attached document, you can probably fake something up with procmail. Something like this: :0 fBH * X-Mailer: Microsoft Outlook Express * ^begin [0-7][0-7][0-7] [A-Za-z0-9] | formail -I Content-Type: application/octet-stream \ -I Content-Transfer-Encoding: x-uuencode That should make it a document containing one inline component that mutt can decode and view using whatever your application/octet-stream viewer is. (By default, mutt tries to treat it as text.) With a slightly fancier bit of scripting, you could extract the filename from the begin line, and add that to the MIME description, and you could ensure that ONLY uuencoded material was processed, and make it attached instead of inline... etc. But this should suit your most fundamental need. The MIME isn't exactly perfect, but it's sufficient for this sole purpose. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Mailbox History
On 2001.11.16, in [EMAIL PROTECTED], Thorsten Haude [EMAIL PROTECTED] wrote: Hi, this one bothers me for some time: I use macro index d save-message=admin/trash\n Move mail to trashcan to get mail out of the way. If I change the mailbox after that, the first entry in the mailbox history is '=admin/trash'. Is there a way of changing that, short of patching the source? Sure. macro index d save-message=admin/trash\nenter-commandmacro editor up 'history-uphistory-upenter-commandmacro editor up \history-up\\\n'\n Move mail to trashcan ... or something like that. You get the idea. :) -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: line length
On 2001.11.13, in [EMAIL PROTECTED],
Will Yardley [EMAIL PROTECTED] wrote:
mutt doesn't have an editor, so this is a function of your editor. in
vim you can use :set tw=74 or :set textwidth=74
nvi and other vi clones should be the same, but you can't use 'gqip' or
'gqap' to format lines (maybe install par).
There is no tw/textwidth in vi -- use wm/wrapmargin instead. Set it to
the width of your right-hand margin to auto-wrap text. (For example: set
wm=8 to wrap at 72 columns on an 80-column screen.)
vim and other vi clones should be the same. :)
You can also use fmt to format lines instead of gq-whatever -- there's
no need to install par, though it is more powerful than fmt.
For example, in your .exrc:
map v {j0!}fmt -w72ctrl-v ctrl-m
This makes v reformat the current paragraph to 72 columns. It ought to
work on any variety of unix or a unix clone, with vi or any vi clone.
--
-D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: line length
On 2001.11.13, in [EMAIL PROTECTED], Rob 'Feztaa' Park [EMAIL PROTECTED] wrote: Hmmm, I tried that with vim... it kinda screws up the quoting. It works great for my own writing, though. Example: Yes, that's one of the ways that par's abilities exceed fmt's. Par is fairly tolerant of and fairly smart about quotation symbols, comment markers, and other such tokens. Its manual is an atrocity, though. Voodoo is probably a better overall tactic than to RTFM. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Auto CC the From: when reply in mailing list
On 2001.11.02, in [EMAIL PROTECTED], Will Yardley [EMAIL PROTECTED] wrote: hit whatever key you have bound to group-reply (i think g by default?)... however you should generally avoid doing this. if people want to be cc'd or replied to privately, they will probably have 'set-followup-to' or 'reply-to' set to their address. I don't find that to be true. Many people are aware that they can do that, and they do, but many more (in my experience) do not. Rather, they just say in the text of their message that they'd like private replies or carbon copies. it's generally considered rude to send to both a list and to someone on the list, so you should only do this if the person has specifically indicated that they want to receive a cc. I don't think that's *generally* considered rude, either. I consider it an aspect of using e-mail in the contemporary environment. I suspect that most people expect this behavior. with other mutt users at least (are there any other MUAs that set 'mail-followup-to' correctly??) if they're not 'subscribed' to a mailing list, their 'mail-followup-to' will probably include both their address and the list address, so list-reply will cc them automatically. This is the thing you can count on. I always group-reply in lists that I know have an open posting policy, because I cannot assume that the sender is on a list, and because there is a way (m-f-t) to indicate that you don't want a copy, and because my mailer respects that. YMMV! -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: 2 Q's (my wishlist)
Ah, mutt -- making the world smaller again. On 2001.10.26, in [EMAIL PROTECTED], Jeremy Hankins [EMAIL PROTECTED] wrote: First of all, I'd like to see the hostname portion of the Message-ID in the index (assuming there is one, of course). I find that quite useful on occasion (e.g., mail from root crontabs from a cluster of machines all using a smarthost -- the message id is an easy way to tell which I'd recommend setting the MTA to pass mail from root literally, and setting each machine's root GECOS in /etc/passwd to kimbark root, etc., but anyway host the message is from). Unfortunately, I haven't been able to find a way to do this. I guess I could set up a procmail recipe to put it in the subject or something, but that seems rather ugly. The first thing to come to mind is a procmail recipe to find the hostname component of the m-id and store it in the X-Label: header. X-Label is completely meaningless; it's only there for mutt to be able to display arbitrary header information stored by procmail. :) Use %y (or %?y?%y?, etc) to show it in the index_format. The other problem I have is that I keep a message archive mirroring the layout of my folders. E.g, if there's a =foo =bar, I also want an =Archive/foo =Archive/bar that reflect the past contents of those folders. Since I use procmail, the obvious solution (which I'm currently doing) is to send messages both to the folder itself and to the archive folder when sorting incoming mail. Unfortunately that (a) leads to an ugly procmailrc, (b) completely loses state info (read/unread/replied, etc) and (c) fails to account for messages that are mis-sorted by procmail which I then manualy put into the right folder. I do this, but instead of having two folders, =foo is a symlink to =Archive/foo-`date +%Y%m` or somesuch. That makes the same folder information occupy both namespaces, and I remake the symlinks each month. It also actually *simplifies* the procmailrc, at the cost of requiring a monthly rotation script. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Console mail notifiers/displayers
On 2001.10.25, in [EMAIL PROTECTED], Rob 'Feztaa' Park [EMAIL PROTECTED] wrote: On Thu, Oct 25, 2001 at 10:21:30AM -0400, David T-G (dis)graced my inbox with: Note that I have found, from recent discussion, that gkrellm (and perhaps other new mail programs) improperly handle new and old-but-unread messages (which many folks might consider new, though mutt correctly doesn't, but which may fit within the design spec of gkrellm's counting unread messages purpose) in Maildirs. I still say mutt is wrong - 'unread' is synonymous with 'new' :) Except when it's synonymous with oh, heck, I don't want to deal with this now. That's when I want something to be old instead of new or read, and to stay old between instances of mutt -- but for unread messages to stay unread, without becoming old. Oh, well, I can't have everything I want. :) -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: limit header size
On 2001.10.24, in [EMAIL PROTECTED],
R . Leponce [EMAIL PROTECTED] wrote:
Hello all mutt-users !!
Is there a way to limit the size of CC and To field when receiving an email also
sent to
many users ?
I had this problem with mail forwarded from my VMS account; its mail
facility expanded groups to a big list on the header lines. I came up
with this procmail rule:
FORMAIL=/path/to/formail
TO=`${FORMAIL} -zx To:`
CC=`${FORMAIL} -zx Cc:`
:0 f
* ^A1-type:
| ( \
if [ `echo $TO | wc -l` -gt 5 ] ; then \
${FORMAIL} -R To: X-VMS-Long-To-Header: | \
${FORMAIL} -I To: X-VMS-Long-To-Header:;; \
else \
cat; \
fi; \
) | ( \
if [ `echo $CC | wc -l` -gt 5 ] ; then \
${FORMAIL} -R Cc: X-VMS-Long-Cc-Header: | \
${FORMAIL} -I Cc: X-VMS-Long-Cc-Header:;; \
else \
cat; \
fi; \
)
This saves the original to: and cc: headers to X-VMS-Long-??-Header:,
and strips out the corresponding ??: header, whenever the list occupies
more than 5 lines. This might not work for you if your header lines are
all in one long line, but if they're properly continued rfc822 headers,
it should be ok.
You'd want to adapt it a little, of course.
--
-D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: maildir and compressed folders
On 2001.10.18, in [EMAIL PROTECTED], Manuel Hendel [EMAIL PROTECTED] wrote: Is it possible to use the compressed folders patch with maildir. What happens than. Does every mail gets compressed, or how does this work with maildir? This patch really isn't particular to compression; it creates hooks for commands to execute before opening and after closing a folder. The default hooks are for compression of an mbox file, but it seems you could reset them as a tar+gz command instead, and store your maildir as a compressed tarball. (You could also compress each message within, but I'd personally favor the tarball.) It's just a matter of writing the correct open/close hooks. One of these days I'm going to get around to using it for encrypting certain folders. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: sending sent
On 2001.10.05, in [EMAIL PROTECTED], Tim Whitehead [EMAIL PROTECTED] wrote: I have emails that I want to resend from ~/Mail/sent. Is there a key binding for this? resend-message, esc-e. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: alias file perms error
On 2001.10.03, in [EMAIL PROTECTED],
René Clerc [EMAIL PROTECTED] wrote:
I thinkt the problem lies with the $; I think it needs to be
escaped.
I think $EDITOR is not defined. To be fully traditional, you should have
${VISUAL:-${EDITOR:-vi}}, or something like that -- it escapes the case
of not having the variable set by providing suitable failover.
--
-D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: difference between hdr_format and index_format
On 2001.10.03, in [EMAIL PROTECTED],
Benjamin Michotte [EMAIL PROTECTED] wrote:
hi,
if I look in the mutt manual, I can find the definition of index_format
but not hdr_format.
They seems to do the same but what's the difference between them ?
They're synonymous. From init.h:
{ hdr_format, DT_SYN, R_NONE, UL index_format, 0 },
It used to be called hdr_format, but it got renamed somewhere near 1.0,
I think.
--
-D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: editing headers in vim + clear text signing
On 2001.10.01, in [EMAIL PROTECTED], Frederik Vanrenterghem [EMAIL PROTECTED] wrote: I'm trying out some ways to clear text sign a message in mutt, using :%!gpg -eas Unfortunately, all headers (including to) are signed, effectively making these headers useless. Is there a way to specify to this filter only to sign/encrypt the actual message body? I can do it in vi thusly: :1 [to top of file] /^$ [find header/body boundary] j [down 1 line to body proper] !Ggpg --clearsign [pipe/replace from here to EOF into gpg] I suppose that vim ought to work the same way. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: mutt and screen: display problems
On 2001.09.22, in [EMAIL PROTECTED], Vincent Lefevre [EMAIL PROTECTED] wrote: I've seen spaces appended to the end of lines in mutt when cutting and pasting, but it went away when I switched to vt100, I think. I don't want to use vt100 because * I want to know (by testing $TERM) if I'm in a screen window or not; test -n $STY * I want colors. vt100 has never stood in the way of my colors Maybe because I'm using slang, which seems to pay less than due attention to terminfos? I won't argue that changing your $TERM is the right solution, but it's a fair workaround if you can't find the right one. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: rot13 capability?
On 2001.09.19, in [EMAIL PROTECTED], David T-G [EMAIL PROTECTED] wrote: % $ grep rot-13 ~/.mailcap % text/rot-13; tr '[A-Z][a-z]' '[N-Z][A-M][n-z][a-m]' %s; copiousoutput Hey, that's slick. I just might have to try that one! You need to lose the extra brackets, though, to make it text/rot-13; tr '[A-Z][a-z]' '[N-ZA-M][n-za-m]' %s; copiousoutput Actually, mine is what works on Solaris (well, on Solaris 9, anyway). I tried your approach and one other (thinking that they were correct) before I realized that GNU is Just Different once again. :) The content-type should probably be text/x-rot-13, though. I don't know that text/rot-13 has been registered. or even simply lose them entirely; your version breaks for me here under Linux (though I don't know about under Solaris, which would definitely support both of my versions). Must be using GNU textutils. :) -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: rot13 capability?
On 2001.09.19, in [EMAIL PROTECTED], David T-G [EMAIL PROTECTED] wrote: Actually, I don't think so; that's what's so interesting. I'd love to see the results of same experiment under 2.6 and 8; Weird: I find that 7 behaves as 9 does -- '[A-Z][a-z]' '[N-Z][A-M][n-z][a-m]' works, but the others give bad string errors. On Solaris 8, this also works, but the other forms do not give bad string. They just include the brackets in the ranges. (IOW, it seems that they require congruent ranges.) I don't have anything less than Solaris 7 anymore. Except... hmm. Yes, SunOS 4.1.4 wins this contest. It'll take any number of ranges on either side, the Way Things Ought To Be. Guess someone just can't make up their minds. I wonder whether it's Sun or a standards agency. I wish I still had other platforms Well, the lesson is that tr usage varies wildly among platforms, just like expr, but we already knew that. :) So maybe it's best just to have your .mailcap call that rot13 shell script, and adapt the script to cope with unames appropriately. Or use perl. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Knowing when something is a thread when it is collapsed
On 2001.09.17, in [EMAIL PROTECTED], Cliff Sarginson [EMAIL PROTECTED] wrote: Hello I like to have threads collapsed by default. However I would like some indication in the index display that a message is the first in a thread. Anyone know how I can do this ? Use %M, or %?M?%M?, or %?M?%M%4c?, something like that. It's documented under the $index_format section of the manual. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: OT: Shell scripting [was: Re: Fix for PGP copyright thing...]
On 2001.09.16, in [EMAIL PROTECTED],
David T-G [EMAIL PROTECTED] wrote:
% Quoting FreeBSD's man sh [from the listing of special parameters]:
% | @ Expands to the positional parameters, starting from one.
% | When the expansion occurs within double-quotes, each
Aha! I don't use BSD (yet), so I don't have access to that, or at least
hadn't thought to search the web for a copy of the freebsd sh man page.
My linux system doesn't even have a man page for sh, preferring info or
whatever it is, and Solaris doesn't mention it at all.
Solaris does, just differently. The section on ${parameter} says first
that if the parameter is * or @, all positional parameters are
substituted. Later, in the section on quoting, it says that if $@
is encased in double-quotes, then the pos'nal params are quoted, and
separated by unquoted spaces. Searching the manual for @ shows this.
% (Prominent example: just now while writing this mail, i saw for the
% first time how ${1+$@} works. Ingenious approach, even if a bit
I see that $@ protects argument expansion; what does the 1 mean? And I
don't have a Solaris box handy to look in a man page to reference what +
means; I only use :- on a regular basis.
From Solaris's sh(1):
${parameter:+word}
If parameter is set and is non-null, substitute word;
otherwise substitute nothing.
...
If the colon (:) is omitted from the above expressions, the
shell only checks whether parameter is set or not.
:+ is the flipside of :- -- :- substitutes if parameter doesn't
have a non-null value, but :+ substitutes if it does.
So ${1+$@} means to substitute all args, quoted, if there is a first
argument (null or not). It's equivalent to $@ alone on most systems
I've seen. ${1:+$@} is not equivalent.
% redundant. Most probably in the context of the tip you found it in it
% was a workaround for a shell that didn't handle a plain $@ correctly?)
It's possible that some shells might issue an error evaluating $@ if
no arguments are present. csh(1) does this by design when evaluating
any variable. This is the kind of behavior I wouldn't be surprised to
see in older versions of AIX, for example; it's sometimes been fairly
strict in its response to undefined conditions. Most systems substitute
nothing if there are no args. UNIX98 requires this, but I can't say with
certainty that prior versions of this standards family require anything
particular, so ${1+$@} might well be needed for backward compatibility
to POSIX or XPG or something. I don't know where to find these standards
online; the Open Group no longer offer previous editions to SUS.
--
-D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Scoring .. what is it's purpose
On 2001.09.09, in [EMAIL PROTECTED], Cliff Sarginson [EMAIL PROTECTED] wrote: - What is the purpose/use of scoring of mail messages? I'm sure that people use it in different ways, but fundamentally, it's just a ratings system. You can value/devalue messages according to the results of one or more matching operators, and then act on the message according to the sum of those ratings. You can look at it as a way of combining lots of different matching operations disjointly - rather than saying if (a and b and c) then mark as important if (a and b and d) then mark as junk if (a and b and e) then mark as ordinary ... plus many other combinations you can say if (a) then increase score by 25 if (b) then increase score by 25 if (c) then increase score by 50 if (d) then decrease score by 100 if (e) then decrease score by 5 if (score 0) then mark as junk if (score = 100) then mark as important You can use scoring to filter out suspected junk mail, or to prioritize messages from co-workers over those from friends, or to make messages from Outlook Express users disappear under a limit, all by tying rules together rather than by writing more complex rules. Another, simpler summary: it's a stateful property of a message that can be manipulated by any number of successive rules. - Can i mark a message as undeletable (and reverse that) As far as I know, not without some severe shenanigans. You could bind your 'd' key to some function that deletes the message, then filters it to a program that evaluates the message's X-No-Delete: header, say, and copies it to a file if it's delete-locked, then appends that file to your current folder. Other bindings would insert/remove an X-No-Delete: header into/from the current message. That would do it, I think, but I'd reconsider how badly you want this functionality before trying it. Or ask someone for a patch. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Color
On 2001.09.06, in [EMAIL PROTECTED], Denis Perelyubskiy [EMAIL PROTECTED] wrote: also, neither do i know if this is an *official* bash way, but things like these work in my startup files, even though maybe they disgust people who really know bash :) What bothers me about this approach, in general, is that it's not supposed to depend on your shell -- you're not supposed to need to make tests and reset $TERM accordingly at all. The point of terminfo/termcap and the $TERM variable is that the terminal emulator application should tell the shell what terminal it's emulating by means of $TERM, and everything should work. If it doesn't, then something is wrong with your terminfo library or your termcap file, or your terminal emulator is lying. needs new options or resources. That said, I occasionally change my $TERM from xterm to something I like, just to get rid of the alternate (application-mode?) screen setting. But there are better ways of doing this (xterm -ti vt100, or modifying a private copy in $TERMINFO); I'm just lazy. I suspect that there's always a better approach than shell-rc case switching. If not, then your terminal emulator needs new options or resources. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Color
On 2001.09.06, in [EMAIL PROTECTED], Thomas Dickey [EMAIL PROTECTED] wrote: There's also Enable Alternate Screen Switching. Just glancing at the changelog, it appears I added that around patch #90. Hmm, I'm using patch 150, but I don't see that in my menu. I did find the titeInhibit resource, though: good enough for me. sure - but in the cases where it breaks, it's usually on someone else's network (I can't fix those ;-) OK, fair enough. I get a warped viewpoint from owning all the systems I have user rights on. :) -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: viewing attachments automatically?
On 2001.09.06, in [EMAIL PROTECTED], Denis Perelyubskiy [EMAIL PROTECTED] wrote: the problem with outlook is that it also sends a plain text copy along with html one. so i DO NOT WANT to start any kind of browser, dump some output, then look at it in my pager if i can somehow train mutt to recognize that there is also a text/plain attachment, and make it view it first. Mutt can be told the order of preference for multipart/alternative messages. I use this: alternative_order text/enriched text/plain text/html This says that if text/enriched is available as one presentation of the same content, then I want to see it; otherwise, if text/plain is present, I would prefer it over text/html. Mutt will show only one of these alternatives. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: automatically prepend the '=' (default location) to mailbox input
On 2001.08.29, in [EMAIL PROTECTED], Eric Smith [EMAIL PROTECTED] wrote: How can I configure mutt to implicitly prepend the '=' or '+' to a user specified mailbox like in change-folder. I can remap the 'c' command for example to print the '=' for me so then I only need enter the folder name but this clobbers the suggested folder name - which is frequently useful. What is it that you want to happen? I'm not sure you'll find a useful compromise. You can bind c like this: macro index c change-folderbol=eol Change folder That should insert = at the beginning of the buffer without erasing the buffer, but I'm not sure that you'll find it satisying. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Flag entire thread?
On 2001.08.26, in [EMAIL PROTECTED], peter horst [EMAIL PROTECTED] wrote: I'd like to be able to flag an entire thread with !: is this possible? When I tried esc-t'ing a thread, then using ;w, it didn't work--it gave me the Set flag? (D/N/O/r/*/!): message that I expected, but when I entered !, nothing happened. Maybe I don't have to do this to end up with the result I want, which is the ability to limit the index view to threads I've found interesting. Any help? BTW, it's 1.2.5i. This works for me under 1.3.19, but it's not immediately obvious that it worked: the whole thread is flagged, but it remains tagged, so the '!' indicator is not visible. After untagging the thread, it's plain that everything worked. I no longer have a working 1.2.5, so I can't compare, but maybe you have the same obstacle. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: make warning
On 2001.08.08, in [EMAIL PROTECTED], Ken Weingold [EMAIL PROTECTED] wrote: Now sure if I should be worried about it, but I get this on the last line from running make on 1.3.20i: muttlib.c:73: warning: mktemp() possibly used unsafely; consider using mkstemp() It's just gcc pretending it knows what's best. Nothing to worry about. I think it's generally preferred that questions specifically about 1.3.x (or any other development version) go to [EMAIL PROTECTED], rather than mutt-users. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: mailing list improvement
On 2001.08.07, in [EMAIL PROTECTED], Brian Salter-Duke [EMAIL PROTECTED] wrote: macro index \Co pipe-messageaddlist ~/.mutt/listsenter Scan a message for mailing lists to add macro pager \Co pipe-messageaddlist ~/.mutt/listsenter Scan a message for mailing lists to add To get these to work I had replace ~/.mutt etc with a full path to the file. ~ does not seem to work in mutt macros for me. The perl script Interesting. I haven't actually used the script inside mutt, just with some saved messages, since I don't really need this function. Should that be considered a bug, Thomas? would be better if it tested whether the open statement actually worked. I don't think it much matters. The only critical open is the formail, whose success is tested. The subscribe file open shouldn't alter behavior on failure, since it's allowed not to exist. The others will cause a no-op on failure. I guess it depends how noisy you want it to be, but absolutely quiet is what I prefer. I guess the open on /dev/tty should check -- else it will add all addresses found. Oh well. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Reformatting text using elvis/par
On 2001.08.06, in [EMAIL PROTECTED],
Ailbhe Leamy [EMAIL PROTECTED] wrote:
Hi
I've been reformatting text using par, before editing it in vi.
Basically, I've changed my editor to a script that pipes the message
through par and then opens it in vi. The only trouble with this is that
it also reformats my signatures at the bottom of the mail.
I'm not sure exactly how you're running par, but I'd think it's possible
to add in something to set its range.
Two thoughts:
1. Invoke par not as a pipeline, but as an argument to vi. E.g.,
set editor=vi '+/^/;!}par %s
My vi doesn't do what I'd expect here, but I hope that's a bug in
my vi. I don't know; I'll play with this some more just because
I'm curious.
2. Use something more complex as your editor filter. Perl or awk should
be able to split up the incoming document nicely. I've attached an
example. This script filters the draft message, then runs the editor
on it, leaving no temporary files behind.
--
-D.[EMAIL PROTECTED]NSITUniversity of Chicago
#!/usr/bin/perl
$new = $ARGV[0] . .2;
open (IN, $ARGV[0]);
open (OUT, $new);
while (IN) {
last if (/^/);
print OUT $_;
}
close (OUT);
open (OUT, |par $new);
while (IN) {
last if (/^-- /);
print OUT $_;
}
close (OUT);
open (OUT, $new);
print OUT $_;
while (IN) {
print OUT $_;
}
close (OUT);
close (IN);
rename($new, $ARGV[0]);
system(vi \$ARGV[0]\);
exit ($?);
Re: mailing list improvement
On 2001.08.06, in [EMAIL PROTECTED],
Mike Erickson [EMAIL PROTECTED] wrote:
All that would be necessary is a maillist_file setting in my .muttrc
just like alias_file, and add a command to add addresses to it. Although
it'd be a nice bonus, it's not even necessary to autoparse the addresses
out of an email. Just being able to maintain that list from within mutt
would be good enough.
You can have the first part of this, of course, by adding
source ~/.mutt/lists
or somesuch to your .muttrc file. I have .muttrc functionalities split
out into several such files, all sourced from .muttrc.
The rest can be tricky; there's no sure-shot way to determine which
address from the header (if any) is a mailing list address. For every
rule you can make up, some list (or list manager) does it differently.
Here's a possibility, though. I'm in a perl-thwacking mood today, I
guess. Save this attachment in your path as addlist, and try executing
it via macro something like this:
macro index \Co pipe-messageaddlist ~/.mutt/listsenter Scan a message for
mailing lists to add
macro pager \Co pipe-messageaddlist ~/.mutt/listsenter Scan a message for
mailing lists to add
The argument to addlist should be the file you store mutt's lists and
subscribe lines in.
This program will use formail to look for likely list names in the
message you're viewing or that's highlighted in the index. It will check
for what list patterns already are defined in your lists file, and if
any addresses it discovers in the message are not matched by a lists or
subscribe command, it will ask you whether it should add such a line to
the lists file, and then do it.
No particular reason for ^O except that it was available in my
configuration. No warranty, use at your own risk, c.
--
-D.[EMAIL PROTECTED]NSITUniversity of Chicago
#!/usr/bin/perl
require ctime.pl;
if ($#ARGV != 0) {
print STDERR usage: $0 /path/to/lists/file\n;
exit (1);
}
# Remember how to clean up the terminal
$sane = `stty -g /dev/tty`;
chomp $sane;
# Clean up on exit.
sub sanitize () {
`stty $_[0] /dev/tty`;
}
for $sig (INT, QUIT, HUP, TERM) {
$SIG{$sig} = \sanitize($sane);
}
# Find usable addresses from the mail headers. Formail receives our stdin.
open (FORMAIL, formail -xTo: -xCc: -xList-ID: -xSender: |) || exit (1);
while (FORMAIL) {
chomp;
s/^ *//;
s/ *$//;
s/.*([^]*).*/$1/;
s/-(admin|owner|request)\@/\@/;
s/^owner-//;
s/\./\@/ unless (/\@/);
$uniq{$_} = $_;
}
close (FORMAIL);
# Check extant lists file, and discover addresses already in it.
open (LISTS, $ARGV[0]);
while (LISTS) {
chomp;
s/^\s+//;
next unless /^(lists|subscribe)/;
s/#.*//;
s/\s+$//;
s/.*(lists|subscribe)\s*//;
map { $already{$_} = $_ } split(' ', $_);
}
close (LISTS);
# Exclude matching addresses from new list.
for $addr (keys %uniq) {
for $exist (keys %already) {
delete $uniq{$addr} if ($addr =~ /$exist/);
}
}
# Go into raw mode for the prompts.
`stty raw /dev/tty`;
# Prompt whether to add each address discovered.
$| = 1;
open (TTY, /dev/tty);
for $addr (sort keys %uniq) {
while (1) {
print Add $addr as a list [y/n]? ;
sysread (TTY, $ch, 1);
print \r\n;
if (lc($ch) eq n) {
delete $uniq{$addr};
last;
}
last if (lc($ch) eq y);
}
}
# Clean up terminal.
sanitize($sane);
# Append to lists file, if necessary.
@_ = keys %uniq;
$n = $#_ + 1;
if ($n 0) {
open (LISTS, $ARGV[0]);
$date = ctime(time);
chomp $date;
$s = s if ($n 1);
print LISTS # $n list$s added by $0 at $date\n;
map {
print LISTS subscribe $_\n;
} sort keys %uniq;
print LISTS \n;
close (LISTS);
}
print \n;
print $n lists added to $ARGV[0].\n;
print \n;
exit (0);
Re: +, T, C and another suggestion or does it exist?
On 2001.08.03, in [EMAIL PROTECTED], John Wright [EMAIL PROTECTED] wrote: Just talking to someone about mutt flagging mail with + when it's to you and T when it's to you and other, etc, and we were just wondering if mutt either does or could have a flag for emails which are from someone in your aliases list. Doing strictly what you're asking could be done, but it's not there now. I've made a patch that's similar, though: http://home.uchicago.edu/~dgc/mutt/#isalias It's a little odd in syntax -- it takes the form of a modifier on standard ~ matching expressions, rather than being a ~ expression, itself. This patch is for the development (1.3.x) series. You can't use this to set the indicator character, but you can use it in other ways. You might embolden or brighten index lines that are @~f ., for example. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: viewing collapsed threads
On 2001.08.01, in [EMAIL PROTECTED], Michael P. Soulier [EMAIL PROTECTED] wrote: Hey people. When a thread is collapsed, is there a way to tell that there are replies beneath the top-level message? I've been playing with collapsing threads, but after it's collapsed, I can't tell if there's anything to expand or not. Maybe there's an extra char that's not showing up in my terminal? The %M expando in $index_format tells you this. I use something like %?M?%2M%4c? where most people place the message size token. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: mailcap aggravation
On 2001.07.30, in [EMAIL PROTECTED],
Andrey R. Urazov [EMAIL PROTECTED] wrote:
Actually, it's not hard to write it. And it's what was supposed while writing mutt
manual.
it could look something like:
ps -e|grep -q netscape
Not if you left netscape running on your console when you left your
computer, and you're logged in remotely to use mutt. I do this every
day The safest check is to talk X. You can might be able to
find standard shell tools (xlsatoms, xlsclients, etc.) that return
well-defined exit statuses under known conditions on all platforms, but
I wouldn't count on it.
Since I'm not sure this is in the archive enough times, I'll include a
one here. :) It's more friendly than is necessary.
gcc -o RunningX RunningX.c -lX11
--
-D.[EMAIL PROTECTED]NSITUniversity of Chicago
#include stdio.h
#include stdlib.h
#include string.h
main(int argc, char *argv[])
{
char *d;
if (argc == 2) {
if (!strcmp(argv[1], -h)) {
fprintf(stderr, usage: %s [display-name]\n, argv[0]);
exit(1);
}
d = argv[1];
} else {
d = getenv(DISPLAY);
}
if (d)
exit(!XOpenDisplay(d));
exit(2);
}
Re: External editor question
On 2001.07.29, in [EMAIL PROTECTED], Simon Collyer [EMAIL PROTECTED] wrote: Hi All, I'm trying to do something not so simple here it appears. What I am trying to do is load the external editor in a new window, eg trying to be able to reply to multiple seperate messages while composing and reading other mail. Launching your editor so that it detaches from mutt isn't the goal -- if you do that, mutt will just think that you've made no changes to the file, and abort the reply. The fundamental problem is that mutt cannot react to two message operation pipelines at the same time. In short, it's not possible to do this using only one instance of mutt. You might be able to do sneaky things like binding a key to launch mutt on the message and push a reply operation into the input queue... something like this: macro index \Cr copy-message/tmp/mutt-replyentershell-escapexterm -e mutt -f /tmp/mutt-reply -e 'push replyshell-escaperm /tmp/mutt-reply\enterexit' enter Reply asynchronously in a new xterm ...but that's just an idea. I've never tested it, and I cannot test it right now. It probably doesn't work without some significant alterations, and what's more, it can only run one asynch reply at a time since there's no means of sharing a unique file name between mutt and the shell. Perhaps something cleverer could be done by setting $editor to a shell sequence to save the reply template (with edit_headers) to a file and run mutt -H (draft mode) on it. In fact, I think I or someone else might have posted such a value for $editor in the past. Check the archives. It might be something like: set editor=cat /tmp/mutt.$$; xterm -e sh -c 'mutt -H /tmp/mutt.'$$' -e push \'enter-commandset editor=\vi\enter\'; rm -f /tmp/mutt.$$' (Or it might not.) -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: About quoting text, about emacs.
On 2001.07.25, in [EMAIL PROTECTED], Jens Paulus [EMAIL PROTECTED] wrote: On Wed, Jul 25, 2001 at 10:44:11AM -0700, Dominique Pelle wrote: How about attaching another mail to the email you want to send? I know about this attach-message function. The disadvantage is that the attached text is not in the current text and thus cannot be edited or cut or referred to sentence by sentence. Also, the attach-message function includes the message's header whether you want it or not. If it wouldn't, it won't be a message anymore. What if there were a merge-components function in the compose menu, such that you could tag 2 or more components (attachments), call this function, and have those tagged components merged as one? Would this (a) solve the immediate problem, and (b) be more generally useful? -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Problems with vvv port on FreeBSD
On 2001.07.17, in [EMAIL PROTECTED], Suresh Ramasubramanian [EMAIL PROTECTED] wrote: Louis LeBlanc [mutt-users] 17/07/01 23:51 -0400: Hey all. I am trying to get the vvv port for FreeBSD built, but it keeps dying on some wchar code. Any ideas what the hangup is there? I personally had no problems. However, there is a note which says vvv can't coexist with Roland's compressed folders patch in that port. Did you enable both? I'm not sure what that note's about, and I'm only assuming that vvv is the nntp patch (vs the other patches on his site), but I'm using VVV's nntp with the compressed folders patch. I don't think I understand the meaning of a *BSD port at all. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: xterm colored Mutt
On 2001.07.18, in [EMAIL PROTECTED], Ed Robitaille [EMAIL PROTECTED] wrote: Ed Robitaille wrote In order to turn on color in xterm enter the following line in ~/.Xdefaults *customization: -color This will turn on color in all apps that use color in an xterm window. Oops ! You'll have to re-start 'X' or or enter the command that re-init's 'X' to see this go into effect. Or: % xrdb -merge ~/.Xdefaults -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: reconstituting mangled quotes
On 2001.07.17, in [EMAIL PROTECTED], Suresh Ramasubramanian [EMAIL PROTECTED] wrote: Biju Chacko [mutt-users] 17/07/01 12:56 +0530: If you can easily run external programs from it, then look into 'par'. Or fmt - which, as part of the GNU textutils package you can reasonably expect to find on most unix systems. I don't think that its being in textutils is what places it on most unix systems. :P Par is much better, of course ... And, specifically, par can reformat with respect to quotation prefixes, while fmt cannot. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: reconstituting mangled quotes
On 2001.07.16, in [EMAIL PROTECTED], Chris Fuchs [EMAIL PROTECTED] wrote: Then, when you'd like to reformat text, highlight it in visual mode and hit 'gq' and it should wrap nicely. That's what I do, anyway... Thanks, looks like I'll add vim to my mutt learning curve. Are you already using vim? No reason to start, just to get word wrap. par (under vi) handles this, and I'd be shocked -- shocked, I tell you -- if emacs does not. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: archiving mail folders
On 2001.07.14, in [EMAIL PROTECTED], Mark Ferlatte [EMAIL PROTECTED] wrote: I use a procmail rule for that: :0 c : $MAILDIR/Archive/`date +%Y-%m` Which copies all incoming mail into a -DD mbox format mailbox, and then lets the message continue through any other rules that I have. This and other approaches are covered several times in the archive. Look there for other ideas. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Printing in Vim: Solved via Oualline's book
On 2001.07.14, in [EMAIL PROTECTED], John P. Verel [EMAIL PROTECTED] wrote: Am I the only one who'd been stymied at how to print from within vim? Am I the only one who's never wanted to print from inside... hmm, which is more portable: (el|n)?vi(s|m|per), or (el|n)?vi[sm(per)] I'm not sure that there's a difference in which standards are required (extended, at least, and I think that's all), but perhaps one executes faster than the other? -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Printing in Vim: Solved via Oualline's book
On 2001.07.14, in [EMAIL PROTECTED], Brendan Cully [EMAIL PROTECTED] wrote: On Saturday, 14 July 2001 at 18:58, David Champion wrote: On 2001.07.14, in [EMAIL PROTECTED], John P. Verel [EMAIL PROTECTED] wrote: Am I the only one who'd been stymied at how to print from within vim? Am I the only one who's never wanted to print from inside... hmm, which is more portable: (el|n)?vi(s|m|per), or (el|n)?vi[sm(per)] I too have never wanted to print from inside either elviper or nvis. From nviper on the other hand... Leave out one ? and the wolves are all over you :) -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: auto save to diff. folders
On 2001.07.13, in [EMAIL PROTECTED], Szabo Attila [EMAIL PROTECTED] wrote: Hi, On exitting mutt is it possible to save messages automatically dependig on headers to different folders. For example: mails from mutt-users go to the mutt folder??? Sure. For example: macro index q tag-pattern~C mutt-users@entertag-prefixsave-message=muttfolderentersync-mailboxexit -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: auto save to diff. folders
On 2001.07.13, in [EMAIL PROTECTED], David Champion [EMAIL PROTECTED] wrote: On exitting mutt is it possible to save messages automatically dependig on headers to different folders. For example: mails from mutt-users go to the mutt folder??? macro index q tag-pattern~C mutt-users@entertag-prefixsave-message=muttfolderentersync-mailboxexit If you have many such selections, it might work to store them in a separate file: % cat .mutt/exit-actions push tag-pattern~C mutt-users@entertag-prefixsave-message=muttenter push tag-pattern~C dinner-club@entertag-prefixsave-message=dinnerenter push tag-pattern~C gnupg-users@entertag-prefixsave-message=gnupgenter And to write your quit macro differently: macro index q enter-commandsource ~/.mutt/exit-actionsentersync-mailboxexit I think that should work, anyway. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Elvis and par as editor
On 2001.07.11, in [EMAIL PROTECTED],
Ailbhe Leamy [EMAIL PROTECTED] wrote:
simple ESC+q. However, I found par, and now I need to know how to make
elvis use it. Oh, and make it use a ~/.exrc file, so I can have pretty
colours while editing.
Par lines from my .exrc. Note literal control codes in this message.
(I use vi, so this should generally work with clones.)
Likewise, reformat the current paragraph
map v mz{j0!}par w72Th
'z
With justification
map V mz{j0!}par w72Thj1
'z
Reformat to 64 columns -- for block quotations
map K mz{j0!}par w64Th
'z
With justification
map mz{j0!}par w64Thj1
'z
--
-D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Max Size for Attachment
On 2001.07.10, in [EMAIL PROTECTED], Eugene Lee [EMAIL PROTECTED] wrote: On Wed, Jul 11, 2001 at 06:41:05AM +0700, Efata wrote: : : I have fetch email from my friend with attachment file 2.8 MB. And I read : this email with mutt and I view attachment and save it. But after I save the : size change only 2M. It is right or not? This is normal. Attachments are often encoded to prevent data corruption when sent via email. But this encoding process often inflates the size of attachments by 30-40%. So with you, an inflated size of 2.8 MB and an actual size of 2 MB is quite normal. This is typically (probably always) a base-64 encoding, meaning that every 3 bytes are encoded as 4, so your attachment inflates by exactly 33%. (The original file is 75% the size of the encoded attachment.) % echo 2.8 .75 \* p | dc 2.10 Your detached file should be about 2.1 MB. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: sourcing different config files
On 2001.07.09, in [EMAIL PROTECTED],
Will Yardley [EMAIL PROTECTED] wrote:
Is it possible to source different mutt config files somehow based on a shell
script type thingie?
I guess I could have my .zshrc copy the appropriate mutt config file to
.muttrc based on where i'm logging in from but this seems kind of silly.
basically i use the 'SSH_CLIENT' env variable to set $MY_LOCATION to 'home',
'work' or 'other'. I'd like to use different .muttrc's for each location so
Something like
source `case $MY_LOCATION in; home) echo ..muttrc.home;; work) echo .muttrc.work;;
esac`
Or, better,
source `echo .muttrc.${MY_LOCATION:-generic}`
(That's a muttrc directive, not a shell rc one.)
--
-D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: solaris + linux
On 2001.07.05, in [EMAIL PROTECTED], Thomas E. Dickey [EMAIL PROTECTED] wrote: On Thu, 5 Jul 2001, Jesper Holmberg wrote: Suresh: thanks, vt100 seems to work the best. I haven't figured out how to get color out of an xterm under Solaris anyway, so the black and white means to loss of quality. you can install a terminfo entry in your home directory using $TERMINFO to point to it (see the tic and terminfo manpages). I'd use infocmp on Linux to dump a copy of the terminfo and use tic on Solaris to install it. Sun's xterm simply doesn't support color, as far as I've been able to tell. Using TERMINFO=/path/to/ncurses-5.0/share/terminfo doesn't help, in particular. After trying many alternative terminals (rxvt, aterm, wterm, eterm, gnome-terminal, dtterm, etc.) and having serious objections to each, I've happily settled on what I should have tried first: a newer xterm. http://dickey.his.com/xterm/ Thanks, Thomas. I'm sort of surprised you didn't mention that solution, yourself. :) -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: matching random headers in score/color commands
On 2001.06.24, in [EMAIL PROTECTED], Jason A. Fager [EMAIL PROTECTED] wrote: I'm trying to figure out how to make changes to color and/or scoring based on the contents of the Importance: header (this seems to be what Outlook uses to flag messages as high/low priority). It seems that the color and score commands can't use ~h, however. Is there any way around this limitation? I can understand why matching the Procmail. ### ## If the mail seems important, make sure that Mutt knows # :0 f * ^(Importance: High|Priority: Urgent) | formail -I X-Status: F message body might be verboten, but I thought mutt had to read the whole message header anyway; does it only store parts of the header in memory? I'd gladly live with the increased memory requirements if I could match arbitrary header fields. Mutt reads whole headers when the mailbox is scanned, but retains only certain fields indefinitely. It would be nice to be able to configure a list of searchable (and cached) header fields, though. For example: cache_header priority: received: x- could allow header searches to match Priority:, Received:, X-Foo:, and X-Bar: headers by caching any fields which match in a linked list off the ENVELOPE structure -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: mutt 1.2.5i with imap, ssl, and kerbers5, on solaris2.6
On 2001.06.20, in [EMAIL PROTECTED], Brendan Cully [EMAIL PROTECTED] wrote: yeah, don't use kerberos 1.0 with openssl. There's a namespace collision on the crypto library. If you can't upgrade your kerberos, you could try merging the openssl and krb5 crypto libraries into one (as advised by whoever added the old MIT detection code to configure.in), I recommend upgrading your Kerberos intstallation, esp. since (iirc) there's at least one major security-related flaw in 1.0.6. At one time, though, that was not feasible for me, so I understand that it might not be for others. In that case, I suggest the workaround described in configure.in in case (like me) you have multiple projects that will want Kerberos and SSL. or renaming the kerberos crypto library to k5crypto. ... but this is obviously simplest, and preferable if you're more comfortable with copying/renaming important library files than with archiving and unarchiving them, or if you're concerned with the purity of shared objects. :) However, if you're using shared versions of the k5 libraries, be sure that renaming libcrypto.so doesn't invalidate the dynamic loading of other programs that are already compiled against your Kerberos libcrypto.so. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Mutt-1.2.5i compilation problem on Solaris 2.8
On 2001.06.02, in 20010602072318.A375@bloatware, Thomas Dickey [EMAIL PROTECTED] wrote: On Fri, Jun 01, 2001 at 04:19:41PM -0700, Phil Stracchino wrote: I recently added a Sparc Ultra1/170 running Solaris 2.8 (aka Solaris 8) to my network. I have gcc-2.95.2 installed on it, and I'm now trying to compile mutt. Comilation fails with the following error: The most common cause I've seen for problems with the builtins for stdarg/varargs is a misinstalled compiler (gcc is getting confused between Sun's header files and its own - note that gcc has a copy of several header files modified for its own use, e.g., under /usr/local/lib/gcc-lib; if it cannot find these files, it will use the standard ones under /usr/include). Yes, I wonder whether fixincludes was run when gcc was installed. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: How to call an external program against an attachment - without mime?
On 2001.05.28, in [EMAIL PROTECTED],
Louis LeBlanc [EMAIL PROTECTED] wrote:
Hey all. I have an unusual request here.
I noticed that for any message, if you look at the attachments menu
('v'), you will always see the message itself as an attachment (which
makes perfect sense if you understand even a little about RFC 822).
Anyway, it gave me an idea. What if I wanted to call an external
program against the text in that attachment - regardless of the mime
type? How could that be done?
You can use pipe-entry (|) from the attachments menu. Is that about
what you mean?
--
-D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Color Errors on Solaris
On 2001.05.24, in [EMAIL PROTECTED], adam morley [EMAIL PROTECTED] wrote: If you look on Sun's site, there is a link to a company that is doing the porting work for GNOME to Solaris. Last time I looked they hadn't quite got 1.4 packaged, but it was expected real soon now. also, something i forgot to mention is that sun is ditching cde for gnome. and some funky webdesk stuff, but thats another story. im guessing at a release date of gnome 2.0/solaris 9 timeframe. heard their desktop group actually has ppl on the gnome team...also heard something about star office and open office getting together. This porting work is actually just for the fully-integrated version Sun wants to ship in the future. It's fully possible to compile and run it yourself, if you don't particularly want your windowing environment to support all the little things your OS does uniquely. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: configuring headers in Muttrc/ssmtp.conf
On 2001.05.20, in [EMAIL PROTECTED], Joane Lispton [EMAIL PROTECTED] wrote: What I would like to do is have the mail coming from [EMAIL PROTECTED] instead of [EMAIL PROTECTED] I figure the place to do this is either in Muttrc or ssmtp.conf. Just set host= beechtree.its.com in your /etc/ssmtp/ssmtp.conf. If you ever need a different user name in your email address (e.g., your username is kmastin but you wish to use the address [EMAIL PROTECTED]), what you need is to add a line to /etc/ssmtp/revaliases. The comment on the top of that file shows you how you can do it: local_account:outgoing_address:mailhub This is something that's always bugged me about ssmtp. I'm root@domain, where the domain has thousands of unix machines that I don't operate. People setting up ssmtp *usually* don't take care to make exemptions for root and other system accounts when they set up with host = domain. This causes no end of trouble. Please, if you use ssmtp with host masquerading in such an environment, make sure to deal appropriately with all system accounts that might send mail. You probably should exempt any account that was in your passwd file before you started adding users. I'd like to see ssmtp have some way of handling this for the most common cases by default. I don't use it, though, so I'm not sure what the right way to do it would be. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: strange config problem (1.2.5i)
On 2001.05.06, in [EMAIL PROTECTED], Tim Legant [EMAIL PROTECTED] wrote: Nope, it's working the way it should. Comments are stripped first. This is true of just about every programming / configuration language in the world. I say just about because someone will probably point to one that doesn't work this way, but it would be the odd exception. Well, I'm all set up to look silly for mentioning it, but Sh doesn't work this way, for example, and I figure that this general syntax of using line termination, '#' comment markers, and '\' line continuations is *nominally* based upon -- or at least popular because of -- sh's model. In such a syntax, there are three ways of dealing with the relationship of comments to line continuations, and I don't really think there's a strong balance toward a single one of them among all syntaxes in the world. You can parse comment delimiters before line continuation (like sh), or line continuation before comments (like mutt), or you can offer a hybrid where comments end with an EOL *or* a line continutation marker, which is what Arnaud Launay expected. The hybrid is also what I, as a programmer, usually choose, since it seems to be the most flexible. I don't think it would be silly to ask about changing the order in which mutt parses these. I'd certainly vote for a change. But it would perhaps mess with too many people's configuration files, so I'm not sure it's worth it. I just want to disagree that this behavior is somehow naturally correct. :) -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: How to give color to parent message
On 2001.05.06, in 1lgg_B.A.r8G.Qoe96@mostproper, Mr. Wade [EMAIL PROTECTED] wrote: Efata wrote: How I give sign or color to message (message have child only) in collapse thread? I think you are asking how to specify index colors for a message that is part of a collapsed thread. Assuming your terminal supports color, this can be done using something like the following in ~/.muttrc or a another sourced file: color index red black ~v You can also use the approach of setting index_format to contain %?M?%2M%4c? This will display the number of hidden children in a collapsed thread instead of the message size whenever a displayed message is a thread leader. I prefer this, since it gives more information and uses less color. (I save my colors for other things.) (Actually, my index_format the shows the number of children if there are collapsed children, or else the number of attachments if there are attachments, or else the message size. Quite a space-time-saver. :) ) -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: How to give color to parent message
On 2001.05.06, in 6_VECC.A.XuH.KQf96@mostproper, Mr. Wade [EMAIL PROTECTED] wrote: I'd be interested, though, in how he managed to get the index_format to display the number of attachments if there are attachments as he said. A patch: http://home.uchicago.edu/~dgc/mutt/#attach It lets you configure pretty flexibly what attachment means, but suits most people's interests out of the box. I use this with the patch following it on that page, which simulates if/else-if/else constructions. The combination lets me show any of three different things in the same location, depending on circumstances. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: how do I color all mails with attachments?
On 2001.04.23, in [EMAIL PROTECTED], Eric Smith [EMAIL PROTECTED] wrote: like this: colour index brightred black ~? Check this thread: http://groups.yahoo.com/group/mutt-users/message/16502 -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: too many messages saturates slow link
On 2001.03.30, in [EMAIL PROTECTED], "Suresh Ramasubramanian" [EMAIL PROTECTED] wrote: Carlos Puchol proclaimed on mutt-users that: Reading /var/spool/mail/me... 1869 (33%) this saturates my modem line for a little while. is there some way to turn it off or just make it show the XX% part (assuming it is not printed at every message)? That's because mutt has to read the contents of your mbox format mailbox. Switch to (say) maildir. Much faster (and better, if you handle large amounts of mail). I get a lot of mail, and don't need to use maildir for performance reasons. Mbox works fine. Changing to maildir won't solve this problem, either, unless for some odd reason maildir switches out the progress report. What you probably want is to set the read_inc variable, or to make it larger than it is already. $read_inc indicates how often to update the status report line whlie reading a mailbox. For example, setting it to 50 makes the status line update every 50 messages, instead of with each message. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Fwd: Using mutt to sort mailboxes by thread
On 2001.03.26, in [EMAIL PROTECTED], "Andre Majorel" [EMAIL PROTECTED] wrote: I have large mailboxes (archives of Usenet groups) that I would like to sort by thread. Thought of tagging all articles in the box and saving them to another mailbox (otT^;C) but how do you do that from a shell script (not interactively) ? mutt -f old-folder -e 'push "tag-pattern.entertag-prefixcopy-messagenew-folderenterexit"' The words in angle-brackets are the key binding symbols for the operations you wish performed. Using them is more readable, more portable, and often easier to type than entering the binding keystrokes. If you need to translate from keystrokes to binding symbols, you can look up the keystrokes in your interactive help menu. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Mark all messages in folder read
On 2001.03.18, in 20010318211124.A574@madmachine, "phaust" [EMAIL PROTECTED] wrote: Hi. On Sun, Mar 18, 2001 at 07:47:58PM +0100, Stefan Schwandter wrote: Hello all, is there a way to quickly mark all messages in a mail folder (similar to do a catch up in a newsreader) ? Yes, of course. Tag all messages (T .*), and then remove N flag from all of them (W N). Here's macro binding it to .c sequence: macro .c "T.*\nWN" "Cath up" Just a small tip: in a large mailbox, tagging "~A" is noticeably faster than "." or ".*". The latter performs a regular expression match against all messages, while the former just selects everything with no further criteria. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
