Re: Using MH folders
On Sun, Sep 14, 2008 at 09:33:58AM -0400, Peter Davis wrote: I'm using MH folders with Mutt 1.4.2.3i, but there are some inconsistencies: 1) Mutt seems to assume the unseen sequence is always called unseen, though this can be set in the .mh_profile. If I set it to unseen, mutt seems to know which messages in a folder are unread. If I call it unread, however, mutt has no idea. 2) Mutt seems to use one mechanism for recognizing which folders contain new messages, and a different mechanism for actually identifying the new messages. Mutt will tell me there's new mail in folder xxx, but when I change to folder xxx, none of the messages are marked as new. 3) Mutt doesn't seem to recognize some folders as mail folders at all. In MH, a mail folder is just a folder under the top mail folder which contains files whose names are message numbers: 1, 2, 739, etc. Sometimes when I try to change folders to one of these, mutt tells me it's not a mail folder. Well, it appears that mutt 1.5.18 fixes issues 2 and 3. I haven't tested whether it fixes #1 because, frankly, I don't much care if the unseen sequence is called unread or unseen. Thanks! -pd -- Peter Davis Funny stuff - http://www.pfdstudio.com Ideas Great and Dumb - http://www.ideasgreatanddumb.com Art/Tech Fusion - http://www.arttechfusion.com The Tech Curmudgeon - http://www.techcurmudgeon.com
Re: Using MH folders
Sun, 14 Sep 2008 09:33:58 -0400 kirjutas Peter Davis [EMAIL PROTECTED]: | | 3) Mutt doesn't seem to recognize some folders as mail folders at | all. In MH, a mail folder is just a folder under the top mail folder | which contains files whose names are message numbers: 1, 2, 739, etc. | Sometimes when I try to change folders to one of these, mutt tells me | it's not a mail folder. MH folder is a folder that contains (empty) .mh_sequences file. BR., -- Axel Palm [EMAIL PROTECTED]
Re: Using MH folders
On Mon, Sep 15, 2008 at 09:45:26AM +0300, Axel Palm wrote: Sun, 14 Sep 2008 09:33:58 -0400 kirjutas Peter Davis [EMAIL PROTECTED]: | | 3) Mutt doesn't seem to recognize some folders as mail folders at | all. In MH, a mail folder is just a folder under the top mail folder | which contains files whose names are message numbers: 1, 2, 739, etc. | Sometimes when I try to change folders to one of these, mutt tells me | it's not a mail folder. MH folder is a folder that contains (empty) .mh_sequences file. Ok. MH itself doesn't require a .mh_sequences file, but if mutt does, that should be straightforward to arrange. Thanks! -pd -- Peter Davis Funny stuff - http://www.pfdstudio.com Ideas Great and Dumb - http://www.ideasgreatanddumb.com Art/Tech Fusion - http://www.arttechfusion.com The Tech Curmudgeon - http://www.techcurmudgeon.com
Using MH folders
I'm using MH folders with Mutt 1.4.2.3i, but there are some inconsistencies: 1) Mutt seems to assume the unseen sequence is always called unseen, though this can be set in the .mh_profile. If I set it to unseen, mutt seems to know which messages in a folder are unread. If I call it unread, however, mutt has no idea. 2) Mutt seems to use one mechanism for recognizing which folders contain new messages, and a different mechanism for actually identifying the new messages. Mutt will tell me there's new mail in folder xxx, but when I change to folder xxx, none of the messages are marked as new. 3) Mutt doesn't seem to recognize some folders as mail folders at all. In MH, a mail folder is just a folder under the top mail folder which contains files whose names are message numbers: 1, 2, 739, etc. Sometimes when I try to change folders to one of these, mutt tells me it's not a mail folder. Any clues on any of these? Thanks, -pd
MH folders
I am trying Mutt as a replacement for my current MUA. So far, I'm very happy with it but have run into one small challenge. My old MUA uses MH format for the folders and I have lots of folders. I have put .xmhcache into each folder so I can read them with Mutt. I use procmail to sort my mail into various folders; work e-mail into my work folder, mutt-user e-mails in my mutt folder, etc. I have defined my different folders as mailboxes within my .muttrc. The problem is that Mutt doesn't seem to know when there are new e-mails in these folders. Is there anything I can do? Thanks. -- Michael Herman msg30437/pgp0.pgp Description: PGP signature
Re: Performance of Maildir -vs- mbox (was Re: Message attributes, MH folders)
Brett Coon [EMAIL PROTECTED] wrote on Tue, 20 Jun 2000: Hmm, to the extent that MH format is like Maildir, my experience is contrary to your claim that saving changes is faster in a one-message-per-file format. I found that closing mutt took several times longer with MH than with mbox. My suspicioun was that mutt updates the access times for every message file so it can detect new messages, and this updating is slow (at least on Solaris). If this is true, then this wouldn't be slow-down with Maildir. The "newness" of a file is determined by it's location, if it's in the "new" subdir inside the Maildir, it's new. If it's in "cur", it's been read. Other message flags may be stored in the filename, so status changes wouldn't theoretically need to even rewrite the file, just renaming it. I do think Mutt does update the X-Status header though when you flag a message or something... Anyway, the performance hit you get with deleting messages might also be because of the .mh_sequences file? I don't know in detail how that works though, I just know it's there. Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy scifi, the Corrs / "Why care about the weather? It always ends in dark." -- Big Country
Re: Message attributes, MH folders
On Mon, 19 Jun 2000 17:01:42 +0300, =?iso-8859-1?Q?Mikko_H=E4nninen?= wrote: Brett Coon [EMAIL PROTECTED] wrote on Mon, 19 Jun 2000: 2. The feature I *really* want in a mailtool is the ability to (conveniently) put various attributes on messages, such as "answer within 1 week", "delete after 2 weeks", etc, and have the mailtool act accordingly on messages with these attributes. I think the current dev version has support for user-editable X-Label, which can then be matched with some operator (I forget what, maybe it was ~y? It's free at least). You can't really make Mutt remind you of things automatically (eg. you can't put "answer within 1 week" and then have Mutt remind you at the end of that week if you've not yet replied to the message), but you could use it to mark messages as "reply to this" and such, and then use appropriate limit operations (perhaps with macros). This is the dev version though, it will be awhile until it makes its way to the next stable. Not that the dev version is really unreliable or anything. So, it sounds like I could define my own set of fields and flags for X-Label, create some mutt macros to allow me to manipulate the X-Label flags, and then setup mutt to use patterns in these X-Label fields to display and organize messages. If X-Labels contained a field meaning something such as "delete in N days", or "reply in N days", it should be a simple task to create a perl script to scan the X-Label headers for overdue messages and insert flags that the mutt patterns understand. -Brett __ Brett Coon - [EMAIL PROTECTED] - http://www.rahul.net/brett Randy Watson: Let's hear for my band, Sexual Chocolate! [185] "Coming to America" (1988)
Re: Message attributes, MH folders
Brett -- ...and then Brett Coon said... % % So, it sounds like I could define my own set of fields and flags % for X-Label, create some mutt macros to allow me to manipulate ... % or "reply in N days", it should be a simple task to create a perl % script to scan the X-Label headers for overdue messages and % insert flags that the mutt patterns understand. Sounds awesome. Would you mind sharing the package when it's eventually done? :-) % % -Brett % % __ % Brett Coon - [EMAIL PROTECTED] - http://www.rahul.net/brett % Randy Watson: Let's hear for my band, Sexual Chocolate! % [185] "Coming to America" (1988) :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.bigfoot.com/~davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! The "new millennium" starts at the beginning of 2001. There was no year 0. Note: If bigfoot.com gives you fits, try sector13.org in its place. *sigh* PGP signature
Re: special flags (was Re: Message attributes, MH folders)
Gerhard den Hollander [EMAIL PROTECTED] wrote on Mon, 19 Jun 2000: Speaking of which, how can I get my hands on the latest dev ? There's just a new snapshot out on the ftp site (1.3.4). If you want to live with the CVS, then read the info in doc/devel-notes.txt. Regards, Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy scifi, the Corrs / Favourite Windows error message: "Could not read drive C:, disk is not full."
Re: Message attributes, MH folders
On Mon, 19 Jun 2000 20:59:23 +0200, Gerhard den Hollander wrote: I've converted my mailboxes to maildir once, it turned out to be slower than mbox, so I converted back to mbox now. Dunno about MH, but I'm guessing it's about the same speed as maildir since it resembles maildir. are your files on a network? Actually, I think the problem is due to the huge number of files in your subdirs .. depending on the OS (w/ Linux I think the turn around point is between 1000 and 2000 entries per dir) soo many files in your directory makes all directory access slower .. sticking all files in a big folder will improve speed .. a lot of small files in a dir vs a big file containing a lot of small messages shows that the big file is faster (this is at least partly due to the fact that the caching helps ..) I haven't bothered doing much experiments with this, but on a few tests mbox format is the fastest (for me at least). And as clemens said, NFS (or whatever) will add to the bottle neck .. In my case, the files are NFS mounted from a fairly overloaded server, so file accesses are generally slow. I just tried running mutt on my (NFS-mounted) inbox, and it took it about 5 minutes to open the folder and over 15 minutes to close it. Clearly that's not usable. My folder is in MH format with 1090 messages, and another 1000 old messages (which I'm deleting as I type this). I copied the inbox directory to my local filesystem, and found mutt startup times improved to about 3 seconds. Exit time dropped to a little under 5 minutes, which is still painfully slow, however. What is mutt doing that takes so long? Does it rewrite every single message file? At these speeds, I don't find it to be usable for me. I'll try converting to mbox format and see how much that helps. WOW, I tried mbox format on a local directory, and quit time dropped to about 10 seconds. I can live with that. Putting the mbox file on our Mail NFS server slows down startups by a couple seconds, while mutt exit time increases by minutes (it's still trying to quit). So, in summary, MH format is slw in mutt. NFS makes it far slower, no doubt due to NFS write behavior, which I think is compounded by me running mutt on a Solaris machine but the NFS server being a Linux machine (I believe they have different NFS write block sizes that causes Sun-Linux writes to be especially slow). -Brett __ Brett Coon - [EMAIL PROTECTED] - http://www.rahul.net/brett Joker: Gotham City. Always brings a smile to my face. [190]"Batman" (1989)
Re: Message attributes, MH folders
Gerhard den Hollander wrote: * clemensF [EMAIL PROTECTED] (Mon, Jun 19, 2000 at 07:49:56PM +0200) Ronny Haryanto: I've converted my mailboxes to maildir once, it turned out to be slower than mbox, so I converted back to mbox now. Dunno about MH, but I'm guessing it's about the same speed as maildir since it resembles maildir. are your files on a network? Actually, I think the problem is due to the huge number of files in your subdirs .. depending on the OS (w/ Linux I think the turn around point is between 1000 and 2000 entries per dir) soo many files in your directory makes all directory access slower .. sticking all files in a big folder will improve speed .. a lot of small files in a dir vs a big file containing a lot of small messages shows that the big file is faster (this is at least partly due to the fact that the caching helps ..) well, i',m on the verge of converting to [nx]mh. but i stick to the rules, i.e. i will answer each message to me in due time, so i can't keep n*1000 messages, a few dozen are the utmost horror to me. so, why in the world would one want to leave mh for mutt? clemens
Re: Message attributes, MH folders
Brett Coon [EMAIL PROTECTED] wrote on Tue, 20 Jun 2000: So, in summary, MH format is slw in mutt. NFS makes it far slower, no doubt due to NFS write behavior, You could try also Maildir. It's NFS safe (no locking needed!), and it might (ought to!) give you a better performance on folder close, at least what comes to deleting messages. On the other hand, opening a folder will still be slow, because here it's the NFS that's being the bottleneck. Still, if you use any other format except Maildir over NFS, and you don't take *good* care to make sure locking works over that, then you have the risk of losing mail or getting folder corruption. The risk might be small admittedly, but definitely not zero. Maildir is good because you don't have to worry about locking at all. Up to you to decide how much you value your mail... Regards, Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy scifi, the Corrs / Q: How many surrealists does it take to change a light bulb? A: Fish
Re: Message attributes, MH folders
On 2000.06.20, in [EMAIL PROTECTED], "clemensF" [EMAIL PROTECTED] wrote: so, why in the world would one want to leave mh for mutt? Are you asking why in the world would one want to leave: next spacespacespacenext comp ... send spacespacenext spacespacenext spacespacespacespacenext next repl send for: spacespacespacespacespacem ... yspacespacespacespace spacespacespacespacespacespacespacer ... y ? Multiply by 50 times a day: that's why. I can use mutt with one hand behind my back, and I find that doing so is good for me. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Message attributes, MH folders
On Wed, 21 Jun 2000 01:07:00 +0200, clemensF wrote: well, i',m on the verge of converting to [nx]mh. but i stick to the rules, i.e. i will answer each message to me in due time, so i can't keep n*1000 messages, a few dozen are the utmost horror to me. so, why in the world would one want to leave mh for mutt? I'm considering the change because mutt appears to be better supported, and the only MH front-end I'm familiar with, exmh, is kind of slow and requires tcl for serious customization. From what I've seen, I like the mutt mail browser. Threading is a wonderful thing. My ultimate goal is to get the message tagging stuff I mentioned previously, so if I could more easily hack it into MH/EXMH, I'd probably forget about switching to mutt. -Brett __ Brett Coon - [EMAIL PROTECTED] - http://www.rahul.net/brett Pepa: That lady is dangerous. Cabdriver: No lady's dangerous if you know how to handle her. [193] "Mujeres al borde de un ataque de nervios" (1988)
Performance of Maildir -vs- mbox (was Re: Message attributes, MH folders)
2000-06-21-01:17:34 Ronny Haryanto: I'm still wondering why it's slower though (in general), maybe because it fopen() more times than mbox? The mailbox is on ext2fs if that makes any difference. Ext2 is a nice quick FS, with many great features. One of my favourites. For any size mailbox, you can construct extreme examples where mbox will be quicker, and others where Maildir will be quicker. For opening the folder, mbox will be quicker if most of the messages are small; Maildir will get quicker if there are enough messages that are big enough for the Maildir not having to scan through the file to outweight the cost of the extra file opens. By and large mbox will be quicker on opens, in practice, but if the folder isn't too big the difference won't hurt too much. As the number of messages grows, another effect kicks in: ext2, like nearly all other FSes (the few exceptions include Reiserfs, SGI's xfs, and NetApp's WAFL --- anybody know any others?) anyway, for nearly all FS types out there, after there are more than a few thousand entries in a directory, operations start slowing down dramatically, due to the OS constantly having to re-do linear searches through the directory. I can really happily recommend Reiserfs, works like a champ. Just make sure you put a zero in the last column of /etc/fstab, so Linux won't try to fsck it on reboot --- the Reiserfs fsck isn't ready for prime-time. Fortunately, it's not needed either. Back to our muttons, the above performance discussion focused on opening the folder. Once it's open, mutt has built an in-memory data structure describing the messages, and either their offsets in the mbox file, or the filenames where they can be directly accessed in the Maildir. So most operations are fast. Until it comes time to save changes; then deletions require rewriting an entire mbox, while they just require deleting the specific message files in a Maildir, so Maildirs can be way faster there. And then there are the manipulations outside of the MUA. Maildir wins there, at least for me. I _love_ the simplicity and reliability of delivering to it; it's trivial to do so very safely and robustly even from a portable Bourne Shell script. Scanning mailboxes for messages matching patterns is a piece o' cake with Unix shell tools, likewise migrating older messages to archival folders, indexing them with a full-text search tool like e.g. Glimpse, etc. Mark Crispin, author of the IMAP protocol, and more interestingly the C-Client library that underlies the UW imapd and the pine Mail User Agent, abhors Maildir, and it's illustrative to note why: he bases his design decisions on the performance of his microvax running ultrix or some such, which has an excruciatingly slow filesystem compared to e.g. ext2. It can work up a reasonable sequential read speed, but file operations like create and delete, and even open/close, are pathetic, so he sees a nightmarishly huge performance penalty for the one-file-per-message formats like Maildir. -Bennett PGP signature
Re: Performance of Maildir -vs- mbox (was Re: Message attributes, MH folders)
On Wed, 21 Jun 2000 01:33:31 EDT, Bennett Todd wrote: Back to our muttons, the above performance discussion focused on opening the folder. Once it's open, mutt has built an in-memory data structure describing the messages, and either their offsets in the mbox file, or the filenames where they can be directly accessed in the Maildir. So most operations are fast. Until it comes time to save changes; then deletions require rewriting an entire mbox, while they just require deleting the specific message files in a Maildir, so Maildirs can be way faster there. Hmm, to the extent that MH format is like Maildir, my experience is contrary to your claim that saving changes is faster in a one-message-per-file format. I found that closing mutt took several times longer with MH than with mbox. My suspicioun was that mutt updates the access times for every message file so it can detect new messages, and this updating is slow (at least on Solaris). And then there are the manipulations outside of the MUA. Maildir wins there, at least for me. I _love_ the simplicity and reliability of delivering to it; it's trivial to do so very safely and robustly even from a portable Bourne Shell script. Scanning mailboxes for messages matching patterns is a piece o' cake with Unix shell tools, likewise migrating older messages to archival folders, indexing them with a full-text search tool like e.g. Glimpse, etc. Yes, that's a big win for one-message-per-file formats. -Brett __ Brett Coon - [EMAIL PROTECTED] - http://www.rahul.net/brett Coach Norman Dale: Stick to 'em like chewing gum. By the end of the game I want to know what flavor they are. [196] "Hoosiers" (1986)
Message attributes, MH folders
I'm currently an MH/exmh user, and I'm considering the switch to mutt.I have tried it out briefly, and browsed the documentation, so hopefully the following questions aren't too obvious. 1. Folder changes are really slow. My MH folders (directories) have thousands of messages, which undoubtedly is at least part of the problem. Would it be faster if I stored messages in mbox format? Is there anything else I can do to speed it up other than deleting all my old email? 2. The feature I *really* want in a mailtool is the ability to (conveniently) put various attributes on messages, such as "answer within 1 week", "delete after 2 weeks", etc, and have the mailtool act accordingly on messages with these attributes. My current mailtool basically has three message states: unseen, read, and replied-to. To help me avoid losing the important messages or keeping the unimportant ones around, I'd like more states. Mutt seems extremely customizable, but in browsing the documentation it's not at all clear to me how I could do something like this. Any suggestions? Is there currently support in Mutt for annotating messages, or storing a separate message attribute database? -Brett __ Brett Coon - [EMAIL PROTECTED] - http://www.rahul.net/brett Construction worker: In a past life this worm could have been your mother. [169] "Seven Years in Tibet" (1997)
Re: Message attributes, MH folders
Brett Coon: 1. Folder changes are really slow. My MH folders (directories) have thousands of messages, which undoubtedly is at least part of the problem. Would it be faster if I stored messages in mbox format? Is there anything else I can do to speed it up other than deleting all my old email? try to convert to maildir format. it resembles mh in that every message is kept in a single file in directories (folders), but there is no seq-uence file. please feedback on results. 2. The feature I *really* want in a mailtool is the ability to (conveniently) put various attributes on messages, such as "answer within 1 week", "delete after 2 weeks", etc, and i've searched for this feature for ages. mutt has only the attributes you described, but maybe with the aid of hooks and external applications... currently i have a special folder called "termine" (dates in german), which receives messages i should check frequently. i forget them there with a good conscience. suggestions? Is there currently support in Mutt for annotating messages, or storing a separate message attribute database? i wonder: would this feature not be more easily implemented in a mail-shell like mh/exmh? clemens
Re: Message attributes, MH folders
On 19-Jun-2000, clemensF wrote: Brett Coon: 1. Folder changes are really slow. My MH folders (directories) have thousands of messages, which undoubtedly is at least part of the problem. Would it be faster if I stored messages in mbox format? Is there anything else I can do to speed it up other than deleting all my old email? try to convert to maildir format. it resembles mh in that every message is kept in a single file in directories (folders), but there is no seq-uence file. please feedback on results. I've converted my mailboxes to maildir once, it turned out to be slower than mbox, so I converted back to mbox now. Dunno about MH, but I'm guessing it's about the same speed as maildir since it resembles maildir. Ronny
Re: Message attributes, MH folders
Brett Coon [EMAIL PROTECTED] wrote on Mon, 19 Jun 2000: 2. The feature I *really* want in a mailtool is the ability to (conveniently) put various attributes on messages, such as "answer within 1 week", "delete after 2 weeks", etc, and have the mailtool act accordingly on messages with these attributes. I think the current dev version has support for user-editable X-Label, which can then be matched with some operator (I forget what, maybe it was ~y? It's free at least). You can't really make Mutt remind you of things automatically (eg. you can't put "answer within 1 week" and then have Mutt remind you at the end of that week if you've not yet replied to the message), but you could use it to mark messages as "reply to this" and such, and then use appropriate limit operations (perhaps with macros). This is the dev version though, it will be awhile until it makes its way to the next stable. Not that the dev version is really unreliable or anything. Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy scifi, the Corrs / Conscience is what hurts when everything else feels good.
special flags (was Re: Message attributes, MH folders)
Hi, folks -- ...and then Mikko Hänninen said... % Brett Coon [EMAIL PROTECTED] wrote on Mon, 19 Jun 2000: % 2. The feature I *really* want in a mailtool is the ability to % (conveniently) put various attributes on messages, such as % "answer within 1 week", "delete after 2 weeks", etc, and % have the mailtool act accordingly on messages with these % attributes. My big wish is for a configurable field that will show up in the index via $index_format; I'd love to be able to add 6 or 8 columns and put things like "tip" / "calendar" / etcetc there. A patch for this from the pre-PGP days existed, but it doesn't come close to applying now (or even in the 0.95 days, when I was first forwarded it from a kind soul out there). % % I think the current dev version has support for user-editable X-Label, % which can then be matched with some operator (I forget what, maybe it Now, this sounds pretty cool... % was ~y? It's free at least). You can't really make Mutt remind you Any way to put the X-Label: contents into $index_format? % of things automatically (eg. you can't put "answer within 1 week" and % then have Mutt remind you at the end of that week if you've not yet % replied to the message), but you could use it to mark messages as % "reply to this" and such, and then use appropriate limit operations % (perhaps with macros). Yeah; that sounds very possible. % % This is the dev version though, it will be awhile until it makes its % way to the next stable. Not that the dev version is really unreliable % or anything. *grin* Hasn't been since the first one, eh? % % % Mikko :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.bigfoot.com/~davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! The "new millennium" starts at the beginning of 2001. There was no year 0. Note: If bigfoot.com gives you fits, try sector13.org in its place. *sigh* PGP signature
Re: special flags (was Re: Message attributes, MH folders)
David T-G [EMAIL PROTECTED] wrote on Mon, 19 Jun 2000: Any way to put the X-Label: contents into $index_format? I think so. I'm not sure though, it's awhile since it was discussed and I'm not running the latest dev so I can't test it out or check the docs. Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy scifi, the Corrs / "I took an IQ test and the results were negative."
Re: Message attributes, MH folders
Ronny Haryanto: I've converted my mailboxes to maildir once, it turned out to be slower than mbox, so I converted back to mbox now. Dunno about MH, but I'm guessing it's about the same speed as maildir since it resembles maildir. are your files on a network? clemens
Re: special flags (was Re: Message attributes, MH folders)
On 2000.06.19, in [EMAIL PROTECTED], "David T-G" [EMAIL PROTECTED] wrote: Any way to put the X-Label: contents into $index_format? My index_format has: "%?y?[%y] ?". From the docs: The ``X-Label:'' header field can be used to further identify mailing lists or list subject matter (or just to annotate messages individually). The ``$index_format'' variable's ``%y'' and ``%Y'' escapes can be used to expand ``X-Label:'' fields in the index, and Mutt's pattern-matcher can match regular expressions to ``X-Label:'' fields with the `` y'' selector. ``X-Label:'' is not a standard message header field, but it can easily be inserted by procmail and other mail filtering agents. And: %y `x-label:' field, if present %Y `x-label' field, if present, and (1) not at part of a thread tree, (2) at the top of a thread, or (3) `x-label' is different from preceding message's `x-label'. (Yuck! How did I do such a lousy formatting job?) I also have a patch that allows the label command (bound to 'y' by default) to edit labels in the status line, like similar commands for editing other fields. I find this immensely useful, but Thomas is happy with using edit-headers. :) Add-on for 1.3: http://home.uchicago.edu/~dgc/mutt/mutt-1.3.dgc.xlabel.3 All X-Label patches for 1.2: http://home.uchicago.edu/~dgc/mutt/mutt-1.1.12.dgc.xlabel.3 -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: special flags (was Re: Message attributes, MH folders)
On 2000.06.19, in [EMAIL PROTECTED], "David Champion" [EMAIL PROTECTED] wrote: On 2000.06.19, in [EMAIL PROTECTED], "David T-G" [EMAIL PROTECTED] wrote: Any way to put the X-Label: contents into $index_format? My index_format has: "%?y?[%y] ?". From the docs: ... fields with the `` y'' selector. ``X-Label:'' is not a standard message header field, but it can easily be inserted by procmail and other mail filtering agents. I'll add to this: %y and %Y both respond to the %?y?if-else? structure, and both take standard string-formatting stuff (%-4.4y). My procmail inserts an X-Label for each known mailing list, thus offloading most pattern-matching from Mutt to my MDA. Inside Mutt, I only every use ~y for matching lists. I also have a patch that allows the label command (bound to 'y' by default) to edit labels in the status line, like similar commands for editing other fields. I find this immensely useful, but Thomas is happy with using edit-headers. :) This works as well for multi-tagging. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Mutt and MH folders
The problem you are experiencing is related to the fact that the "new" message flag should be saved to the .mh_sequences file of an MH folder. Mutt did evaluate this file at a time. I dropped this support while redoing the mh and maildir folder update code. It was never added again, partially due to the fact that there is no defined locking mechanism for this file. To make a long story short: Don't use MH folders for incoming messages, and consider mutt's mh folder support "legacy format support". On 1999-06-19 18:55:04 +0200, Staffan Hamala wrote: Date: Sat, 19 Jun 1999 18:55:04 +0200 From: Staffan Hamala [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Mutt and MH folders Mail-Followup-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i Hi, I was just wondering.. Is there a patch available to fix newmessage status flags for MH folders? I'm using MH folders at work, and when looking at the folder-list, only empty folders and the last visited folder does not have an 'N' flag. It makes no difference if I have a new mail waiting or not. At home, where I use mbox folders this works, ie it shows me where there are new messages. I thought it might be the NFS thing mentioned in the README, but the nfs configure switch made no difference at all. /Staffan
Mutt and MH folders
Hi, I was just wondering.. Is there a patch available to fix newmessage status flags for MH folders? I'm using MH folders at work, and when looking at the folder-list, only empty folders and the last visited folder does not have an 'N' flag. It makes no difference if I have a new mail waiting or not. At home, where I use mbox folders this works, ie it shows me where there are new messages. I thought it might be the NFS thing mentioned in the README, but the nfs configure switch made no difference at all. /Staffan
