Tobias Nijweide wrote: > I've started to redo my patches to nmh, and have some questions on > how people would like them implemented. This mail will ask some > questions about the patch for per folder component/filter/etc files.
Thanks for doing this, Tobias. BTW, it's great to see something happening with nmh again. > 2 Where do we look for component files: > > a - If fixed path (Starting with '/', '~', './' or '../'), only one choice. > b - Current, or selected folder > c - Recursive search upwards from current folder, up to: > d - User nmh directory > e - /etc/nmh (or whatever is the value of nmhetcdir) I haven't actually tried your code, so I might be on the wrong track here... still, I've got some comments about c. Instead of recursive search upwards, can we assume that people who want to use this feature would simply make *links* (hard or soft), from whatever folders they create, into a master copy (somewhere) of the component files they want to use in that folder? It seems to me that a link is a fine way to propagate particular components files to the folder(s) where they're wanted. Using links (instead of a recursive search upwards) would also let people *block* the feature (and use the default components files in the nmh directory, I guess), in any particular subfolders where they want to. > - I'm not sure what the impact of public folders would be. I have > never used them, any ideas? Thanks for thinking of this obscure but useful nmh feature. As a sort of side question: do nmh hackers want/need a list of "obscure nmh features" to keep in mind as they hack the code? (I'm talking about features like public folders, private sequences, relative folder paths starting with "@", etc.) This might be especially useful for nmh hackers from the exmh (and mh-e, etc.) worlds, where some nmh features may not be obvious or accessible. But back to your question: Public folders have different semantics than private folders do because, I think, they're intended to be accessed by many people. Sequences are treated differently in a public folder (they're not stored in a public-access file in the folder; they're stored in a particular user's own nmh directory), and I think it makes sense that components can be treated differently, too. Still, there *are* times when using components in a public folder would be good. For instance, we used to have a group of consultants who did bug-tracking and end-user consulting via a central mail folder. All new bugs and user questions went into that folder; whoever handled a bug would use "anno" to mark its state (accepted, replied, closed, etc.). And we all replied from the same central bug-tracking address, *not* from our own personal addresses. In a case like that, the *ability* to have a shared replcomps file would be nice. One sort-of-kludgey way to control this, folder by folder, is the way that private sequences are handled: by per-folder entries in each user's context. I'm offline now (on a laptop running Win98), so I don't have access to nmh. But private sequences are handled with an entry something like "atr-cur-/prj/mail/bugs/inbox: 23" (That says: in the public folder +/prj/mail/bugs/inbox, *my* current message is 23.) Maybe there could be (optional) context entries for each component, something like "atr-replcomps-/prj/mail/bugs/inbox: ." meaning to use the components file in that folder (.) when your current folder is +/prj/mail/bugs/inbox. This is getting pretty complicated, so I'm not sure I'm adding anything to the discussion except confusion. ;-) Still, as you point out (in your final paragraph, thanks) it *is* important to think these features through carefully. I wish I had access to nmh from here! > 3 - In my current version, for comp I change what happens when you use a > +folder argument and no msg argument. Traditionally this means you use > the current msg from that folder as a draft, in my version this just > takes the component files from that folder. > > I can imagine this would break some things people are currently doing. I've never used this feature, but it seems to me that it was designed for flexibility and programmability. Maybe you want to have more than one folder for mail drafts: some drafts for use on each of your consulting jobs (say), and some for personal mail. Or maybe someone has programs that use this feature: a temporary drafts folder that's used only while a program is running, so it doesn't conflict with the user's main draft-folder. > Some solutions? > - Use a different flag (-compfolder? yuk) I guess I don't see what's wrong with -compfolder. It lets you specify exactly what you mean... and (I think) it could be abbreviated to -compf, so it's not that much to type. Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
