speeding up open mailbox
I recently moved to maildir/Evolution, but Evolution is still somewhat unstable. So I finally got around to be a Mutt user. I have to say it's love at first sight. One thing I haven't figured out yet is how to speed up the opening of very large mailboxes. My debian-users mailbox contains some 3500 messages. It takes about 60 seconds to open. Are there any tricks to speed this up, some caching mechanism or something. I'm already using ReiserFS and maildir. regards o polite. -- o polite http://plusseven.com/gpg/
Re: speeding up open mailbox
On Sun, Mar 17, 2002 at 12:12:41PM +0100, [EMAIL PROTECTED] wrote: Are there any tricks to speed this up, some caching mechanism or something. I'm already using ReiserFS and maildir. Oops. sorry, about that. I read the manual but I forgot to google. I'll try the maildir cache patch (http://www.cs.hmc.edu/~me/mutt/patch-1.5.0.me.hcache.8) -- o polite http://plusseven.com/gpg/
Re: speeding up open mailbox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This one time, at band camp, [EMAIL PROTECTED] wrote: very large mailboxes. My debian-users mailbox contains some 3500 messages. It takes about 60 seconds to open. Are there any tricks to speed this up, some caching mechanism or something. I'm already using ReiserFS and maildir. Yes: mailto:[EMAIL PROTECTED]?subject=unsubscribe mailto:[EMAIL PROTECTED]?subject=subscribe -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjyUmbgACgkQ/R32uxik1HZ0hwCfV81gz9W1Hy5a99rCNTM91UhW PGoAoMmvjFypn8pIvjUcdNan9UUGNpnE =8yf6 -END PGP SIGNATURE-
Re: speeding up open mailbox
* Shawn McMahon [EMAIL PROTECTED] [03-17-02 08:31]: This one time, at band camp, [EMAIL PROTECTED] wrote: very large mailboxes. My debian-users mailbox contains some 3500 messages. It takes about 60 seconds to open. Are there any tricks to speed this up, some caching mechanism or something. I'm already using ReiserFS and maildir. Yes: mailto:[EMAIL PROTECTED]?subject=unsubscribe mailto:[EMAIL PROTECTED]?subject=subscribe And YOU, of course, will never request aid on this list, or present a query someone else thinks is inappropriate/unnecessary. I HOPE. -- Pat Shanahan Registered Linux User #207535 Registered at: http://counter.li.org 8:52am up 2 days, 11:40, 7 users, load average: 0.00, 0.02, 0.01
Re: speeding up open mailbox
This one time, at band camp, MuttER wrote: mailto:[EMAIL PROTECTED]?subject=unsubscribe mailto:[EMAIL PROTECTED]?subject=subscribe And YOU, of course, will never request aid on this list, or present a query someone else thinks is inappropriate/unnecessary. I HOPE. That was a perfectly valid and workable answer to his query, and one that will use less RAM than the one he found on his own. And, BTW, more direct than the answers I got to one of my queries, that told me to use certain patches without providing URLs. I gave him working point-and-click URLs. (But thanks, David, for the answer anyway, because I found the patch I wanted and solved the problem.) Opening 3500 emails is slow. You can make it faster, but you cannot make it fast, not without sacrificing something. Opening one email is faster. msg25631/pgp0.pgp Description: PGP signature
Re: speeding up open mailbox
At 6:12 AM EST on March 17 [EMAIL PROTECTED] sent off: I recently moved to maildir/Evolution, but Evolution is still One thing I haven't figured out yet is how to speed up the opening of very large mailboxes. My debian-users mailbox contains some 3500 messages. It takes about 60 seconds to open. Are there any tricks to speed this up, some caching mechanism or something. I'm already using ReiserFS and maildir. My freshmeat folder has about that many messages, but it only takes a few seconds to open (never timed it), and I'm using mbox on ext3, so your setup *should* be faster according to the hype. Are you reading from NFS, IMAP, POP, or a 386 or something? Have you tried using hdparm to tune your hard drive? Is mutt being any slower than Evolution was? -- Tuesday Night at the Movies will be seen on Saturday this week instead of Monday. - television announcer Robert I. Reid [EMAIL PROTECTED] http://astro.utoronto.ca/~reid/ PGP Key: http://astro.utoronto.ca/~reid/pgp.html
Re: speeding up open mailbox
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: I recently moved to maildir/Evolution, but Evolution is still somewhat unstable. So I finally got around to be a Mutt user. I have to say it's love at first sight. One thing I haven't figured out yet is how to speed up the opening of very large mailboxes. My debian-users mailbox contains some 3500 messages. It takes about 60 seconds to open. Are there any tricks to speed this up, some caching mechanism or something. I'm already using ReiserFS and maildir. Maildir is slower at being opened; the simple act of opening a file, scanning the first few bytes, then closing it 3500 times is always going to be slower than simply opening one file and seeking through it, unless your filesystem is really incredibly good at organising it to minimise seeking and give a miniscule overhead to the extra syscalls. That's without mentioning having to take directory listings of two directories beforehand. The solutions are: 1. Switch to mbox and trade off individual mail modification speed and corruption resistance for initial opening speed. 2. Use a maildir caching patch to limit scanning of new messages to operations on a dbm. 3. Make use of the low cost of moving messages from the start of the maildir to archive old messages. Leave your working folder as maildir with a maximum of a couple of days mails and keep mbox archives or so. 4. Find a filesystem which keeps lots of small files in the same dir consolidated together with the metainformation it needs to find them to cut down seeks and small reads. 5. Get tonnes of memory and try to keep as much as possible of it cached. On FreeBSD this tends to cut opening time to about 10% slower than mbox. I do 1, but could conceivably do 2, 3 and 5 in future. -- Thomas 'Freaky' Hurst - [EMAIL PROTECTED] - http://www.aagh.net/ - Lackland's Laws: (1) Never be first. (2) Never be last. (3) Never volunteer for anything
Re: Displaying all mail after a limit command
Martin Karlsson [EMAIL PROTECTED] wrote: Limit to ~A (all) does it for me. Or why not to . (a dot)? Fewer keystrokes :-) As I understand it, Mutt internally translates the search pattern . into ~A, so they are one and the same. -- David DeSimone | The doctrine of human equality reposes on this: [EMAIL PROTECTED] | that there is no man really clever who has not Hewlett-Packard | found that he is stupid. -- Gilbert K. Chesterson Richardson IT|PGP: 5B 47 34 9F 3B 9A B0 0D AB A6 15 F1 BB BE 8C 44
Re: speeding up open mailbox
On Sun, Mar 17, 2002 at 06:45:32PM +, Thomas Hurst wrote: 2. Use a maildir caching patch to limit scanning of new messages to operations on a dbm. After a nice walk in the park I've spent the evening patching and compiling mutt. The tricky part was figuring out which packages to install to satisfy the dependencies. The patched version works very nicely. Opening the 3500 messages mailbox took 79 seconds with the prepacked mutt. It takes less then a second with the patched version. op -- o polite http://plusseven.com/gpg/
Re: speeding up open mailbox
This one time, at band camp, [EMAIL PROTECTED] wrote: The patched version works very nicely. Opening the 3500 messages mailbox took 79 seconds with the prepacked mutt. It takes less then a second with the patched version. Guess I was wrong, then; switching to the digest wouldn't have been measurably faster. :-) msg25636/pgp0.pgp Description: PGP signature
Re: speeding up open mailbox
* [EMAIL PROTECTED] [EMAIL PROTECTED] [03-17-02 14:35]: On Sun, Mar 17, 2002 at 06:45:32PM +, Thomas Hurst wrote: 2. Use a maildir caching patch to limit scanning of new messages to operations on a dbm. After a nice walk in the park I've spent the evening patching and compiling mutt. The tricky part was figuring out which packages to install to satisfy the dependencies. The patched version works very nicely. Opening the 3500 messages mailbox took 79 seconds with the prepacked mutt. It takes less then a second with the patched version. Much better than a previous suggestion. Good luck. -- Pat Shanahan Registered Linux User #207535 Registered at: http://counter.li.org 2:36pm up 2 days, 17:24, 7 users, load average: 0.00, 0.01, 0.00
Re: speeding up open mailbox
* Shawn McMahon [EMAIL PROTECTED] [03-17-02 14:40]: This one time, at band camp, [EMAIL PROTECTED] wrote: The patched version works very nicely. Opening the 3500 messages mailbox took 79 seconds with the prepacked mutt. It takes less then a second with the patched version. Guess I was wrong, then; switching to the digest wouldn't have been measurably faster. :-) And I was 2 sec.s late opening my BIG mouth. bg :^) -- Pat Shanahan Registered Linux User #207535 Registered at: http://counter.li.org 2:41pm up 2 days, 17:29, 7 users, load average: 0.00, 0.01, 0.00
Re: ~/Mailbox oddness?
J. Scott Dorr [EMAIL PROTECTED] wrote: The only problem with this is that if I let other apps do it, then my status line in mutt won't be accurate, and mutt won't offer ~/Mailbox as an option to change to when I hit 'c'. There's something strange about all this... A program other that Mutt should really end up checking your mailbox in the same way that Mutt does. That is, other programs (I'm pretty sure tf does it this way) will simply look at the time stamps on the mailbox, and if the write time is later than the read time, it reports new mail. If the latter is later (??), then it's assumed that some other program read the mail, so mail is no longer reported for that mailbox. The thing is, checking the time stamps will not cause other programs to see things any differently. That is to say, all the programs that check mail in this manner should see things the same way, without interfering with each other. The only thing that messes up this scheme is when a program not only wants to tell you that you have new mail, but also wants to show you something about that mail. For instance, a program that wants to notify you of new mail, AND tell you whom the new mail is from, and what the subject is... well, that program needs to OPEN the mailbox and read it, and that causes the last read timestamp to change, and this will cause other programs (like Mutt and tf) that only look at the time stamps, to stop reporting new mail. So you need to take a look at how each program that detects mail for you is doing the detection, and if you don't like the way they are doing it, maybe there is some way you can put a stop to it. -- David DeSimone | The doctrine of human equality reposes on this: [EMAIL PROTECTED] | that there is no man really clever who has not Hewlett-Packard | found that he is stupid. -- Gilbert K. Chesterson Richardson IT|PGP: 5B 47 34 9F 3B 9A B0 0D AB A6 15 F1 BB BE 8C 44
Re: speeding up open mailbox
On Sun, Mar 17, 2002 at 12:22:24PM -0500, Rob Reid wrote: My freshmeat folder has about that many messages, but it only takes a few seconds to open (never timed it), and I'm using mbox on ext3, so your setup *should* be faster according to the hype. Are you reading from NFS, IMAP, POP, or a 386 or something? Have you tried using hdparm to tune your hard drive? Is mutt being any slower than Evolution was? The file system is ReiserFS and it's local, however the machine is fairly new but it's a laptop so the hdparm figures are pretty lousy. Evolution would open the folder in a snap. I guess there's some caching going on there to. I have another partition with ext3. An operation like find mailfolder| wc -l would be noticeably slower on ext3 then reiserfs I moved to ReiserFS for my maildir after reading the hype at http://www.jedi.claranet.fr/qmail-reiserfs-howto.html, and at least at my computer the hype holds true. op -- o polite http://plusseven.com/gpg/
Re: speeding up open mailbox
At 3:20 PM EST on March 17 [EMAIL PROTECTED] sent off: On Sun, Mar 17, 2002 at 12:22:24PM -0500, Rob Reid wrote: My freshmeat folder has about that many messages, but it only takes a few seconds to open (never timed it), and I'm using mbox on ext3, so your setup *should* be faster according to the hype. Are you reading from NFS, IMAP, POP, or a 386 or something? Have you tried using hdparm to tune your hard drive? Is mutt being any slower than Evolution was? The file system is ReiserFS and it's local, however the machine is fairly new but it's a laptop so the hdparm figures are pretty lousy. Evolution would open the folder in a snap. I guess there's some caching going on there to. I have another partition with ext3. An operation like find mailfolder| wc -l would be noticeably slower on ext3 then reiserfs I moved to ReiserFS for my maildir after reading the hype at http://www.jedi.claranet.fr/qmail-reiserfs-howto.html, and at least at my computer the hype holds true. I think a previous reply had the right answer: maildir isn't faster than mbox for all operations. I also get ridiculous delays by just typing 'ls' in a directory with thousands of files. -- In Paris in December 1997, just before being convicted of the murders of two counterespionage agents, international terrorist Carlos the Jackal was sentenced to 10 days' solitary confinement for calling a prison guard a gnu. - News of The Weird That _is_ weird. Didn't the guard know it was a compliment? Robert I. Reid [EMAIL PROTECTED] http://astro.utoronto.ca/~reid/ PGP Key: http://astro.utoronto.ca/~reid/pgp.html
Re: speeding up open mailbox
Thomas Hurst wrote: * [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: Are there any tricks to speed this up, some caching mechanism or something. I'm already using ReiserFS and maildir. The solutions are: 1. Switch to mbox and trade off individual mail modification speed and corruption resistance for initial opening speed. yum. we use Maildir on our office mailserver so i've just ended up using this. it *is* pretty slow though, particularly on ext2fs. 2. Use a maildir caching patch to limit scanning of new messages to operations on a dbm. i've been doing this, and i find that it can definitely make a difference, although since the only large mailboxes i have are ones i don't enter frquently, it often still takes a while to open the mailbox while the cache data is being updated (the actual caching itself seems to take a while sometimes; it took me 13 seconds to initially open a Trash folder i hadn't opened in a while; the second try was only like 1.5 seconds. however unpatched mutt was consistently around 6 seconds). 3. Make use of the low cost of moving messages from the start of the maildir to archive old messages. Leave your working folder as maildir with a maximum of a couple of days mails and keep mbox archives or so. yup. personally i don't see the need of keeping that many messages around. i prefer to only save messages i find interesting, which means most of my folders have between 20 and 150 messages in them (and my inbox rarely has more than 15). i know a lot of people are the opposite, but i don't understand it. i go through and archive trash folders and such every once in a while (into bzipped tarballs), and other than that, i look something up in the mailing list archives if i can't find it. that's what online archives are for; admittedly it's sometimes easier to search your own, but i don't like keeping thousands upon thousands of extra emails around just in case i might need to use them. i do keep separate inbox trash folders (and separate trash folders for work mailing lists). that way i can archive those for longer than regular list mail, spam, cron related stuff, etc. 4. Find a filesystem which keeps lots of small files in the same dir consolidated together with the metainformation it needs to find them to cut down seeks and small reads. i know one person who put her mail on a separate partition (ffs) and used tunefs to change the average filesize (smaller) and average number of files in a directory (bigger). she also was using soft-updates (which i've heard isn't really the greatest idea for mail, since it's conceivable that you could lose mail)... in any event, she said this increased performance, however i'm not sure if there is any equivalent to tunefs for reiserfs. i have no experience with reiserfs personally, but i have heard that it's pretty slow. one other option would be to try using mutt over IMAP with an IMAP server like courier. i think that might speed things up since there's a lot of caching going on server side. -- Will Yardley input: william @ hq . newdream . net .
Re: Installing Mutt - Can't fix mutt_dotlock's permissions
Vincent Lefevre wrote: When installing Mutt in my home directory, I get the following error: [...] This is normal, but anyway, mutt_dotlock is already installed in /usr/bin. In fact, I just want to install the mutt binary. The problem is that Mutt has installed a mutt_dotlock with incorrect permissions in my home directory. They are incorrect only if your mails are delivered into /var/spool/mail/. mutt_dotlock will work perfectly if, for instance, procmail puts them directly somewhere where you have sufficient rights (~/Mail/). -- Cedric
Re: [Announce] Mutt 1.3.28 (BETA) is out.
David T-G wrote: Yippee! My list of patch maintainers for my cocktail is currently [...] Cedric Duval [...] so all of you folks should get to work to make sure that your patches work under 1.3.28 :-) The previous versions should apply cleanly, but anyway I've updated them all for 1.3.28: http://cedricduval.free.fr/mutt/ -- Cedric
Re: different hooks for Email/Usenet
* Andre Berger [EMAIL PROTECTED] [2002-03-17 02:05]: What I'm trying to accomplish is more or less the same Jerome (the original poster) wants. We use mutt with nntp-patch and want to set headers according to the fact if we are mailing or posting. i got that. however, you did not describe what the goal of *your* setup should be. What I want is to test if there is a To-header or not - if there is one, I'm mailing, if there is none, I'm posting. hmm.. ok. i think. (i do not know what else the NNTP patches offer.) If I'm mailing, add a Bcc header (I'm Bccing all mail to myself to keep track of it). If not, do not add this header because this results in an ugly To: undiclosed recipients ; line in my postings. If you just want mutt to keep a copy of all your messages depending on Email or Usenet then why not set FCC instead? Why *send* a copy? I've tried an otherwise empty .muttrc file and send-hook . unmy_hdr * send-hook '~t ..*''my_hdr Bcc: mail' send-hook !'~t ..*''my_hdr Bcc: news' fcc-hook'~t .' +MAIL fcc-hook '! ~t .' +NEWS Isn't this easier? Testing the settings: 1. (mail) no bcc 2. (mail) bcc: mail 3. (news) bcc: mail 4. (news) bcc: news So it seems to work, but the send-hook is one message late. huh? Sven -- Sven Guckes [EMAIL PROTECTED] http://www.math.fu-berlin.de/~guckes/mutt/setup.html
1.3.28: still not possible to compile without iconv
I asked about this when 1.3.25 came out and got the answer that this should be fixed / will be looking into it. However, 1.3.28 still can't be configured without iconv. Any chance for a change? I've attached a patch that seems to work. It's a bit of hack, a clean solution would be to have an iconv.h substitute that defines the prototypes of the replacement functions which are in charset.c and also defines iconv_t and EILSEQ. This would localize the changes instead of spreading them out over many files. diff -c -r mutt-1.3.28/charset.c mutt-1.3.28-/charset.c *** mutt-1.3.28/charset.c Tue Jan 22 17:02:39 2002 --- mutt-1.3.28-/charset.c Sun Mar 17 15:53:57 2002 *** *** 31,37 --- 31,39 #include unistd.h #include errno.h + #ifdef HAVE_ICONV #include iconv.h + #endif #include mutt.h #include charset.h diff -c -r mutt-1.3.28/charset.h mutt-1.3.28-/charset.h *** mutt-1.3.28/charset.h Tue Feb 13 14:06:14 2001 --- mutt-1.3.28-/charset.h Sun Mar 17 15:46:58 2002 *** *** 19,25 --- 19,29 #ifndef _CHARSET_H #define _CHARSET_H + #if HAVE_ICONV #include iconv.h + #else + #define iconv_t int + #endif int mutt_convert_string (char **, const char *, const char *, int); diff -c -r mutt-1.3.28/gnupgparse.c mutt-1.3.28-/gnupgparse.c *** mutt-1.3.28/gnupgparse.cWed Aug 1 07:06:58 2001 --- mutt-1.3.28-/gnupgparse.c Sun Mar 17 15:54:48 2002 *** *** 44,50 --- 44,52 #include mutt.h #include pgp.h #include charset.h + #ifdef HAVE_ICONV #include iconv.h + #endif /* for hexval */ #include mime.h diff -c -r mutt-1.3.28/rfc2047.c mutt-1.3.28-/rfc2047.c *** mutt-1.3.28/rfc2047.c Mon Oct 15 13:18:32 2001 --- mutt-1.3.28-/rfc2047.c Sun Mar 17 15:50:10 2002 *** *** 24,30 --- 24,32 #include ctype.h #include errno.h + #if HAVE_ICONV #include iconv.h + #endif #include stdio.h #include stdlib.h #include string.h diff -c -r mutt-1.3.28/sendlib.c mutt-1.3.28-/sendlib.c *** mutt-1.3.28/sendlib.c Wed Nov 7 02:51:29 2001 --- mutt-1.3.28-/sendlib.c Sun Mar 17 15:53:39 2002 *** *** 649,654 --- 649,657 } /* Define as 1 if iconv sometimes returns -1(EILSEQ) instead of transcribing. */ + #ifndef EILSEQ + # define EILSEQ EINVAL + #endif #define BUGGY_ICONV 1 /*
Re: 1.3.28: still not possible to compile without iconv
* On 2002.03.17, in [EMAIL PROTECTED], * Claus Assmann [EMAIL PROTECTED] wrote: I asked about this when 1.3.25 came out and got the answer that this should be fixed / will be looking into it. However, 1.3.28 still can't be configured without iconv. Any chance for a change? Lars Hecking posted a patch to mutt-dev over a month ago. It's still awaiting testers before it can be merged into the tree for 1.4. It seems to work for him, but very few truly iconv-less people have tried it and reported back. See http://groups.yahoo.com/group/mutt-dev/message/13851 -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: 1.3.28: still not possible to compile without iconv
On Sun, Mar 17, 2002, David Champion wrote: * On 2002.03.17, in [EMAIL PROTECTED], * Claus Assmann wrote: I asked about this when 1.3.25 came out and got the answer that this should be fixed / will be looking into it. However, 1.3.28 still can't be configured without iconv. Any chance for a change? Lars Hecking posted a patch to mutt-dev over a month ago. It's still awaiting testers before it can be merged into the tree for 1.4. It seems to work for him, but very few truly iconv-less people have tried it and reported back. See http://groups.yahoo.com/group/mutt-dev/message/13851 Thanks, I found the message in a different archive (groups.yahoo.com wants cookies...) Feedback: it compiles fine on my machine (OpenBSD 2.8) and it seems to work (only basic testing). So please merge it before 1.4. Thanks! (sorry, I don't read mutt-dev anymore, I'm getting more than 500 mails a day (obviously I can only skim through the subjects and read only a subset...))
Re: 1.3.28: still not possible to compile without iconv
* On 2002.03.17, in [EMAIL PROTECTED], * Claus Assmann [EMAIL PROTECTED] wrote: (sorry, I don't read mutt-dev anymore, I'm getting more than 500 mails a day (obviously I can only skim through the subjects and read only a subset...)) Lars doesn't read mutt-users anymore for the same kind of reason, so that makes a problem. :) -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
display of flagged message in collasped thread
i am currently using v1.3.27i. is it possible to show the flag-message indicator for a collapsed thread? currently i see when threads are collasped... 44 Mar 14 15.21 Maxim Sobolev5 cvs commit: ports/www/mozilla... 49 Mar 15 09.08 Matthew Reimer! Re: cvs commit: ports/www/moz... ...when uncollasped... 44 Mar 14 15.21 Maxim Sobolev cvs commit: ports/www/mozilla... 45 Mar 14 15.36 Christopher Masto `- 46 Mar 14 21.03 Michael J Estes ! `- 47 Mar 15 02.25 Maxim Sobolev ! `- 48 Mar 15 08.55 Christopher Masto `- 49 Mar 15 09.08 Matthew Reimer! Re: cvs commit: ports/www/moz... ...what i wish is... 44 Mar 14 15.21 Maxim Sobolev5! cvs commit: ports/www/mozilla... 49 Mar 15 09.08 Matthew Reimer! Re: cvs commit: ports/www/moz... ...i didn't find anything in muttrc(5) or when searched for (flag-message|flagged) in the manual. has this feature already been implemented or is in the plans? - parv --
Re: different hooks for Email/Usenet
* Sven Guckes [EMAIL PROTECTED], 2002-03-17 18:26 -0500: * Andre Berger [EMAIL PROTECTED] [2002-03-17 02:05]: [...] If you just want mutt to keep a copy of all your messages depending on Email or Usenet then why not set FCC instead? Why *send* a copy? [...] fcc-hook'~t .' +MAIL fcc-hook '! ~t .' +NEWS Isn't this easier? I'm working on different computers at work and want to save my mail on none of them. Bcc is a convenient mail to keep track of all my mail in one place, my compi at home. Where I use fcc-hooks BTW. Testing the settings: 1. (mail) no bcc 2. (mail) bcc: mail 3. (news) bcc: mail 4. (news) bcc: news So it seems to work, but the send-hook is one message late. huh? [sigh] this means I'm trying to send 4 messages for test purposes (mail, then mail, then news, then news). Send-hooks trying to set Bcc headers do not effect the current but the next message! -Andre msg25651/pgp0.pgp Description: PGP signature
Re: speeding up open mailbox
On Sun, Mar 17, 2002 at 12:46:10PM -0800, Will Yardley wrote: 1. Switch to mbox and trade off individual mail modification speed and corruption resistance for initial opening speed. yum. we use Maildir on our office mailserver so i've just ended up using this. it *is* pretty slow though, particularly on ext2fs. Consider switching to ext3. It has (except for the better integrity) a directory speedup patch. -- Ralf Hildebrandt (Im Auftrag des Referat V A) [EMAIL PROTECTED] Charite Campus Virchow-Klinikum Tel. +49 (0)30-450 570-155 Referat V A - Kommunikationsnetze - Fax. +49 (0)30-450 570-916 Sometimes it pays to stay in bed in Monday, rather than spending the rest of the week debuging Monday's code.-Dan Salomon
1.3.28i etc.
Hello, I have a few questions I was unable to find answers for in the docs/web: 1. How can I disable the 'L' flag in 1.3.28i? It's redundant for me since I already use procmail to sort my list-mail into folders. 2. How can I match match both '[EMAIL PROTECTED]' and '[EMAIL PROTECTED]' in a subscribe line? Right now I just have two entries, but I'd like to figure out the rules for whatever pattern pragma mutt uses. In perl, it'd be: /(freebsd-)?questions\@freebsd.org/ 3. In folder-view, is there a way to bind a key to move down to the next folder with unread mail? I don't think this is possible, but you mutt gurus have suprised me before. tia, mike msg25654/pgp0.pgp Description: PGP signature
Re: Mutt 1.3.28 + ncurses 5.2 + xterm = blank screen
Hi, Thomas! I've compiled mutt-1.3.28i in the default configuration on RedHat Linux 7.2 (i386) with all updates. If I run it in xterm (from XFree86-4.1.0) or in rxvt-2.7.6, it shows a blank screen. I can quit by pressing Ctrl-C and Enter. The same executable runs on the Linux console just fine. what $TERM value? xterm both under xterm and rxvt. I forgot to mention that I was running xterm from rxvt. I have found that if I run xterm from the window manager the problem goes away! When I run rxvt, it sets the following environment variables beginning with COLOR: COLORFGBG=default;0 COLORTERM=rxvt Both xterm and rxvt are using black background. From .Xdefaults: XTerm*background: black XTerm*foreground: gray85 Unsetting COLORFGBG fixes the problem. My interpretation is that mutt uses black text on black background. Probably ncurses interprets default in COLORFGBG as black whereas S-Lang uses the foreground from the X resources. Shouldn't ncurses ignore COLORFGBG if it has unsupported keywords (let's move this discussion elsewhere if you want to continue). Not exactly mutt problem, but may be useful thing to know if other people ask. -- Regards, Pavel Roskin
