Tobias Nijweide <nmh-workers(_at_)nijweide(_dot_)nl> writes:
Scott(_dot_)Blachowicz(_at_)seaslug(_dot_)org said:
* I have a folder where I always want to use a different '-form'
option for scan.
Don't have a solution for this. You could code a variant of the patches
I mention below, with (recursive) searching of format files in maildirs.
Scott(_dot_)Blachowicz(_at_)seaslug(_dot_)org said:
* I reply to a message in a folder where I file all of the messages
from a mailing
list. I want to use a different replcomps that has the email
address (in From &
Reply-to headers) that I used when I subscribed to the list.
On http://www.neatech.nl/oss/nmh you can find a patch that adds per
maildir component files. This functionality is also in exmh, but I
needed it in nmh proper. I never got any favorable responses to it,
so I never bothered to work out the other changes on that page.
Well, that's not exactly true. Hal DeVore, who did the exmh implementation,
said that he agreed it belonged in nmh proper. I also expressed that I'd be
willing to commit your changes (never got around to it, though -- one of
many items that've been sitting in my nmh-pending folder waiting for me to
get some time to devote -- hopefully I'll have some in the near future).
I'll attach the original mails on this topic.
It will actually do a recursive search for the right component file,
so that I can have different trees of maildirs with sometimes individual
comp files, sometimes one per tree or subtree. And I do use it for your
intended use, nmh-workers(_at_)nijweide(_dot_)nl is not my general mail
address. :)
If anyone is interested in this patch, want a cleaner version to put
in the official nmh for example :), I'd be very happy to do some work.
I've been using it for almost 2 years without any problems.
Regards,
Tobias Nijweide
--
Dan Harkless
nmh(_at_)harkless(_dot_)org
http://harkless.org/dan/
--- Begin Message ---
[If somebody gets this twice (thrice?) I apologize, used the wrong sender
first two tries.]
Hi,
I'm a recently converted nmh/exmh user. There were a couple of things
I found missing that I hacked in. There's also a couple of less necessary
things that I added just for the heck of it. My question is whether
anyone would be interested in these changes, and in what format I should
send patches (split up per feature or everything in one big blob).
- etcpath to searchpath.
I created a new routine searchpath to replace etcpath. If given
a filename without leading '/' or '~' it searches the folder
and all its parents before searching ~/Mail and /etc/nmh.
While I was writing this into nmh the same feature was also put
into exmh, but nmh would be a cleaner location?
- formatted components for comp.
I wanted a formatted components file for comp because I want to
automatically 'Fcc:' to the current folder.
- folder components escape.
The current/target/something folder can be used from your
formatted components files.
- userflags and component escapes.
comp and repl were extended with a '-userflag key=value' option that
allows the user to add any needed component escape from the commandline.
Makes it easier to use one componentfile for multiple uses.
These features were only implemented for comp and repl. dist and forw
haven't
been tackled yet because I'm not completely comfortable with all their
features.
So, is anyone interested or shall I keep them to myself?
Tobias Nijweide
--- End Message ---
--- Begin Message ---
On Wed, 6 Sep 2000, "nmhworkers" == nmh-workers(_at_)nijweide(_dot_)nl
wrote:
nmhworkers> While I was writing this into nmh the same feature
nmhworkers> was also put into exmh, but nmh would be a cleaner
nmhworkers> location?
As the perpetrator of the change to exmh you're talking about, I
agree that putting it in nmh would have been better. But nmh
development is in somewhat of a state of disarray. Plus it was
less complex to have it in exmh than to hack it into nmh and
then have to write exmh in such a way as to work both with and
without the feature.
There are lots of exmh features that should be in nmh. Getting
them there and then getting them distributed has been a bit
problematic.
--Hal
--- End Message ---
--- Begin Message ---
nmh-workers(_at_)nijweide(_dot_)nl writes:
[If somebody gets this twice (thrice?) I apologize, used the wrong sender
first two tries.]
Hi,
I'm a recently converted nmh/exmh user. There were a couple of things
I found missing that I hacked in. There's also a couple of less necessary
things that I added just for the heck of it. My question is whether
anyone would be interested in these changes, and in what format I should
send patches (split up per feature or everything in one big blob).
- etcpath to searchpath.
I created a new routine searchpath to replace etcpath. If given
a filename without leading '/' or '~' it searches the folder
and all its parents before searching ~/Mail and /etc/nmh.
While I was writing this into nmh the same feature was also put
into exmh, but nmh would be a cleaner location?
Aren't there usability and security concerns with this? Won't some people
suddenly start getting different components files than the ones they expect
if they don't change their .mh_profile to prepend '~/<`mhparam path`>' to
all components filenames?
I think it'd be safer to check the current directory (but not its parent
tree -- why do you need that?) *last*, with an option to force the
components file in the current directory by using './'..., just like with
$PATHs.
- formatted components for comp.
I wanted a formatted components file for comp because I want to
automatically 'Fcc:' to the current folder.
- folder components escape.
The current/target/something folder can be used from your
formatted components files.
- userflags and component escapes.
comp and repl were extended with a '-userflag key=value' option that
allows the user to add any needed component escape from the commandline.
Makes it easier to use one componentfile for multiple uses.
These features were only implemented for comp and repl. dist and forw
haven't been tackled yet because I'm not completely comfortable with all
their features.
So, is anyone interested or shall I keep them to myself?
Tobias Nijweide
I don't have a personal interest in the components changes, but I can see
how they'd be useful, and at first glance they don't seem to have
undesirable consequences like your etcpath change. Why don't you post the
diffs to the list and see if anyone takes it upon themselves to commit them?
Separate diffs per feature are of course preferable, but if that's hard to
achieve, it seems like those three changes are related enough that a single
diff would be acceptable. Just make sure the diff is against the latest CVS
source so the patches work properly and don't get rejected.
Frankly, though, you'd increase the chances of the patches getting applied
if the new features were implemented across the board and if you updated the
documentation to reflect the changes (you didn't mention whether or not
you'd done this).
-----------------------------------------------------------------------
Dan Harkless | To prevent SPAM contamination, please
dan-nmh(_at_)dilvish(_dot_)speed(_dot_)net | do not post this private
email address
SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
--- End Message ---
--- Begin Message ---
- etcpath to searchpath.
I created a new routine searchpath to replace etcpath. If given
a filename without leading '/' or '~' it searches the folder
and all its parents before searching ~/Mail and /etc/nmh.
While I was writing this into nmh the same feature was also put
into exmh, but nmh would be a cleaner location?
Aren't there usability and security concerns with this? Won't some people
suddenly start getting different components files than the ones they expect
if they don't change their .mh_profile to prepend '~/<`mhparam path`>' to
all components filenames?
I think it'd be safer to check the current directory (but not its parent
tree -- why do you need that?) *last*, with an option to force the
components file in the current directory by using './'..., just like with
$PATHs.
With current directory you mean current folder, or really current directory?
I agree it's probably wise to check for './' and '..' cases as well as '/'
and '~'.
I need it because I have groups of mailboxes that I treat the same.
I have a group of work-related mailboxes that need my work email address
in the from header, private mails get a different from. By using a
recursive search I only have to have one component file for work or
private (To see where I'm coming from, I have 200 mailboxes with
27000 mails, and I like to keep things manageable).
Security concerns? The user still gets to see the mail before he sends it,
doesn't he? The routine only searches in the user's mailfolders. I can't
imagine any security concerns, but then I do have to admit I don't
understand all the uses people have for nmh like public folders.
Usability concerns? If the user has files called 'components' in a
mailfolder, I think we can assume in 99.99% of the cases that user
want to use that file for mails composed from that folder.
The recursiveness could be a little trickier. If a user has folders
a and a/b, with a components file in a, I can imagine circumstances
where he wouldn't want to use that components file from a/b. I
still think that won't happen too often.
Frankly, though, you'd increase the chances of the patches getting applied
if the new features were implemented across the board and if you updated the
documentation to reflect the changes (you didn't mention whether or not
you'd done this).
That's why I first sent my request for interest to the list. Stuff works
satisfactorily for me now. If nobody wanted it, I wouldn't have bothered
with documentation and parts that I don't use.
I'll split up the searchpath and components changes and flesh them out
a bit more, and put them on the list when they work.
Thanks for the feedback.
Tobias
--- End Message ---
--- Begin Message ---
nmh-workers(_at_)nijweide(_dot_)nl writes:
- etcpath to searchpath.
I created a new routine searchpath to replace etcpath. If given
a filename without leading '/' or '~' it searches the folder
and all its parents before searching ~/Mail and /etc/nmh.
While I was writing this into nmh the same feature was also put
into exmh, but nmh would be a cleaner location?
Aren't there usability and security concerns with this? Won't some people
suddenly start getting different components files than the ones they expect
if they don't change their .mh_profile to prepend '~/<`mhparam path`>' to
all components filenames?
I think it'd be safer to check the current directory (but not its parent
tree -- why do you need that?) *last*, with an option to force the
components file in the current directory by using './'..., just like with
$PATHs.
With current directory you mean current folder, or really current directory?
Okay, I'm sorry. I misread your initial description. I thought you were
saying directory rather than mail folder. My security concerns came from
imagining it climbing all the way up to the '/' directory looking for
components files. My usability concerns came from imagining having a
components file in the current directory that you don't want to override
your ~/`mhparam path` version or the system version. Now I understand your
feature, and it sounds like a good addition.
Frankly, though, you'd increase the chances of the patches getting applied
if the new features were implemented across the board and if you updated the
documentation to reflect the changes (you didn't mention whether or not
you'd done this).
That's why I first sent my request for interest to the list. Stuff works
satisfactorily for me now. If nobody wanted it, I wouldn't have bothered
with documentation and parts that I don't use.
I'll split up the searchpath and components changes and flesh them out
a bit more, and put them on the list when they work.
Great! Thanks a lot for your contribution.
-----------------------------------------------------------------------
Dan Harkless | To prevent SPAM contamination, please
dan-nmh(_at_)dilvish(_dot_)speed(_dot_)net | do not post this private
email address
SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
--- End Message ---
--- Begin Message ---
Ppl,
Some time ago I posted on this list my desire for recursive searching
for mh-format files. I finally finished the patch, thanks to lokigames
and a son that needed some extra quality time for the delay.
The patch (or any new versions) can be found at
http://www.neatech.nl/oss/nmh/
The diff is against nmh cvs sources of 17 october 2000 is available.
Documentation can be found in the manpages, especially mh-format.
There is one controversial change in this patch. When comp is started
with only a folder, and not a message like comp +mh/nmh-workers , it
will now reference a component file as its template, and not the
current message from that folder.
This change could cause some users some pain, but I still think it's
better to include it. Without it it is very difficult to have comp
find a per-folder components file reliably. I don't know how many
people would run comp with a +folder argument, and without a msg
argument (this is different from the draftfolder argument!). If the
needs of these users override those of this patch, I'll rework it.
I'd appreciate any comments, or alternatively a checkin by someone.
Tobias Nijweide
--- End Message ---