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 "
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 a
There's a piece of code in addir (uip/folder.c) that seems well intended but
causes problems. It's the stuff under the "short cut" comment below.
static void
addir (char *name)
{
int nlink;
char *base, *cp;
struct stat st;
st
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
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.
Jon
> Hmm. I'm afraid I disagree about this redefinition of "next". Currently, I
> don't need to do individual mhshows if I just want to sequence through all
> the parts: just show, and keep hitting Return, or Ctrl-C to skip a part.
>
> Cheers,
> Dave
Disagreement is good. I do it too! If I get
> 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 sho
> 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, shou
> Jon Steinhart <[EMAIL PROTECTED]> writes:
>
> > Also, I didn't mean to start a flame war with my questions
> > about the code. It's my opinion that nmh has about twice as
> > much code as is really needed to do the job. That excess
> > fluff ma
Wow! It's amazing how something so simple can be such a
problem. OK, since I started this, I'll change it so that
install-mh lives in bin with a link to it from lib, and I'll
change the manual page to be in section 1 instead of section 8.
Now, I hate to make this even more complicated, but shoul
> 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
> 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, o
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;
i
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 it
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
> > 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 G
> >It's always bugged me that MH/nmh starts to install a new user setup if
> >it can't find something it's looking for -- like the MH (.mh_profile)
> >file. IMHO, it should simply fail and print an error message that gives
> >the pathname of the MH file that it's looking for (that's either the
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
I just started integrating some of my stuff. I noticed that the cvs does
not come with a configure file. I tried to use the one from nmh-1.0.4 but
it doesn't work because it doesn't know anything about SASL_INCLUDES.
Anyone know how to get this stuff built? Thanks.
Jon
> 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.
&
> Sigh. I can see I'm not going to convince you. While some software exists
> to perform spam detection, integrating it into nmh would be ... challenging,
> especially if you want to avoid downloading the whole message.
>
> --Ken
Well, I've been waiting for all of the minor updates to nmh to be
Hey folks, nothing is served by this increasingly heated bickering.
There seems to be a general consensus on the following:
o People would like to see work continue on nmh in a timely fashion,
o People would like to get a new release together,
o CVS is a good tool and people would like t
I too would like to see work continue on nmh. I'd like to see the
stuff that I contributed to integrated in to a new release. It seems
clear that Doug is no longer able to be the maintainer for this, so
someone else should pick it up. If that means forking the CVS, so
be it. Let's get somethin
Howdy. This is a minor update of the patches that I posted a long
time ago. It supercedes the earlier patches. It makes one change
which is to add a -append option to anno so that headers that
indicate attachments can be appended to the header instead of
prepended. This makes attachments come
I originally wrote:
>I just noticed that
>
> mhpath cur
>
>produces the same results as
>
> mhpath new
>
>if there is no current message. Looking at the code, it seems
>deliberate, but why? Acts like a bug to me.
Neil wrote:
> I just tested, and got
>
> 6% mhpath cur
>
I just noticed that
mhpath cur
produces the same results as
mhpath new
if there is no current message. Looking at the code, it seems
deliberate, but why? Acts like a bug to me. If I want to write
a shell script to, for example cat the current message so that I
can look at th
> Hold up -- everyone back up a step. The most immediate concern is
> getting out a release that makes public the changes in CVS for the last
> 2 (?) years. This is not a good time to be making more changes on the
> main branch, as it will inevitably hold up the process more. This would
> be a
> On 7 December 2001 at 8:24, Jon Steinhart <[EMAIL PROTECTED]> wrote:
> > I am planning to change anno to append header fields instead.
> > Can't see how this would break any existing applications. If
> > anyone is worried about this, I can add a prepend/
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 att
> 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
>
> The enclosed message causes problems for nmh-1.0.4 from the NetBSD
> packages collection. It prints the headers, along with the message:
>
> mhshow: bogus multipart content in message 1256
>
> Alas, I don't know the mail RFCs well enough to pin the blame on the
> IETF editor or NMH. A
> | 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
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. 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
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
nobody is doing this stuff.
But if, for example, Microsoft decided to being every mail header field name
with a NUL it would be legal while breaking lots of things.
Is this a correct recap?
Jon Steinhart
e that this stuff is sort of covered by the NETWORK-SPECIFIC
TRANSFORMATIONS section of RFC822 but I have trouble believing that any
*NIX mail system actually does it. Is this true?
Thanks,
Jon Steinhart
Thanks to Dan Harkless for feedback on how to get this stuff in. Among
other things, he wrote:
> Nothing special. Just let the list know. As for your attachment changes,
> why not just post your diffs (using -c, of course, and vs. the latest CVS
> source if possible) to the list and ask if som
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
39 matches
Mail list logo
