Robert Elz writes:
| Anyone have a problem if I remove this test?
Yes.
It is that test that makes folder run in manageable time, without it,
every message in every folder has to be stat'd to see if it happens to
be a directory - with it, folders with no sub-folders (which almost all
Robert Elz wrote:
| How about if I change the test so that it is only ignored for the top
| level directory?
That would do much less harm, but is unlikely to be so easy (that function
gets called for any level in the hierarchy, if I recall correctly).
An alternative would be a try
I have it working on Solaris (albeit an old 2.6) and Linux RH9.
Hi. Seems like we've had a 1.1 release candidate sitting for a long
time. Can we make it a release yet? It would be nice to have something
newer than 1.0.4 going into things like Linux distributions.
Hm, well ... how about
Where we're had to move away from nmh towards gnus is in MIME
composition (e.g. for the ability to specify inline/attachment).
You might want to look at the attachment stuff that I checked in a while
back. I implemented it in such a way that it could easily be incorporated
into MH-E. The
I've changed the Subject and included [EMAIL PROTECTED]
since we've spent the last year improving MIME handling in Gnus since
raw MH wouldn't work for us. We should be able to provide some
suggestions which would allow us to use more MH and less Gnus. Peter?
Satyaki?
Yeah, should
Neil W Rickert [EMAIL PROTECTED] writes:
But, install-mh is not likely to be in the user's path;
it's in the lib directory. Should I change the
installation to move this to the bin directory or to
make a link from the bin to the lib directory?
Make a sym-link, or put in a shell
Jon Steinhart [EMAIL PROTECTED] writes:
3. If the $HOME environment variable is set, mypath is copied from the
getenv return. Why? It's never changed.
4. If the $HOME environment variable is not set, mypath is copied from the
pw_dir member of the returned passwd structure
Well, here's a minor detail that could cause problems.
I have a version of nmh here that has sbr/context_read
modified to give a run install-mh message if mh
isn't installed rather than doing it for the user as
per yesterday's discussion.
But, install-mh is not likely to be in the user's path;
Howdy. I've been working on a companion mail reading system
for nmh. In short, this is a system that builds a database
from mail in folders, allowing it to be searched quickly. It
includes a ranking mechanism, and allows messages to be searched
by rank. Sort of like the current fad of Bayesian
But, there's one more sticky point. There's no good way to test whether
or not nmh is installed. When I set up my program, I want to fail with
an error message if the user hasn't set up a mail directory, etc.
Is test -d `mhparam Path` sufficient for your needs?
--
Eric Gillespie *
I've started working on the changes for the mh installation thing discussed
earlier. My plan is to modify context_read() to print a message instead of
invoking install-mh, and to add a -check option to install-mh that allows it
to silently check for installation, returning the status via the exit
sbr/context_read does a complicated check for installation involving first
the MH environment variable and second the default profile. I was surprised
to discover that uip/install-mh does not perform identical tests. It just
looks for the default profile. This seems wrong to me. Should I fix
On July 8, 2002 at 11:05, Jon Steinhart wrote:
And I agree, downloading the entire message is the way to go. Most spam is
very small compared to even slow V90 speeds which is what I'm stuck with out
in the country here, so it's no big deal.
Well, I would have to disagree about spam
Well, since Chad just reposted my attachment code, let me tell you
what's wrong with it. I'll update it if work is really going to
happen on a new release.
I use anno to add attachment headers. Anno works by prepending
headers to a message. Unfortunately, this means that if you add
several
Jon Notice that the boundary specified on the content-type
Jon line is NextPart. This means that --NextPart lines
Jon are boundary markers. But, in the remainder of the
Jon document they're - --NextPart.
It's not clear from the mangled copy attached just WHAT it
looked like
I have noticed that mail from one of the mailing lists that I subscribe
to often gets mangled on inc, splitting a message into two. I can't
tell what's going on for sure because by the time I see the mail, it's
too late. My suspicion is that somehow one of the headers in the
message body is
Here's another instance of the previously posted bug:
(Message inbox:3107)
Return-Path: [EMAIL PROTECTED]
Delivery-Date: Wed Aug 15 20:07:07 2001
Received: from fedney.cdc.nextlink.net (fedney.cdc.nextlink.net [208.177.199.21])
by darkstar.fourwinds.com (8.12.0.Beta5/8.12.0.Beta5)
| I have noticed that mail from one of the mailing lists that I subscribe
| to often gets mangled on inc, splitting a message into two.
Are you running Solaris? Solaris' mail.local uses Content-Length
to delimit messages, and leaves From alone. That can confuse MH.
There was an old
I posted some patches to improve the user interface for handling
attachments with mail drafts several weeks ago and haven't heard
a thing since. Was this stuff great? Terrible? Need some changes
before merging it with the code base? Or is nobody there with the
time to look at it?
Jon
I have made a modification to whatnow to support an "attach"
request, and an associated mhattach program. There are a few other
minor changes to support an "attachproc" in the context. This all
allows MIME attachments to drafts with a decent user interface.
I'd like to get this
20 matches
Mail list logo
