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, jpeek(_at_)jpeek(_dot_)com, http://www.jpeek.com/