First off, let me say that I didn't mean to suggest stepping on anyone's
toes -- I certainly feel that Dan and Doug have done the world a
service, and I respect that. I threw out SF as an option because it
would let us beat on an `interim release' or similar without disturbing
the current mhost
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
I
I would personally like there to be no difference between reading messages
and reading attachments. In other words, I don't want to have to use a
different UI because someone sends me a message with 3 attachments as
opposed to 3 messages.
I strongly agree, but want a new command name so that
I've noticed that when I send a message, any BCC or DCC recipients do not appear
in the copy saved via FCC. This behavior is consistent with the send(1) man
page, but IMHO, that behavior is broken. I understand that the recipients should
be hidden for outbound mail, but I believe that the file
New module? No, that is just not the way CVS is supposed to be
used. Maybe a seperate branch if radical changes are going to be
made, but HEAD is the appropriate place for most development.
Hmm. While I agree with you, and I'm certainly willing to try it, I
have to say that most of the
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 good
Please deal with Jon offline, since your mail is getting through to the
rest of us.
Shantonu
On Friday, December 7, 2001, at 12:25 PM, Laura Creighton wrote:
Return-Path: MAILER-DAEMON
Delivery-Date: Fri Dec 7 18:21:51 2001
Return-Path: MAILER-DAEMON
Received: from localhost (localhost)
Oh, sorry, I thought I was in the Jon Steinhart wants opinions on
major new features thread.
Laura Creighton
Doug wrote:
New module? No, that is just not the way CVS is supposed to be used.
Maybe a seperate branch if radical changes are going to be made, but
HEAD is the appropriate place for most development.
Yes, that is correct. I've worked quite a bit with CVS in the recent
past and find it an
I'm not sure that I agree. When I asked people on this list about making
changes to the CVS, I was told to post my changes and someone would look
'em over and put them into the CVS. I couldn't find anybody to give me
CVS write access since the maintainer was too busy. So let's not just toss
Hey, all.
I'm using nmh 1.0.4 on Mac OS X, and I'm trying to duplicate the
functionality I had on my Linux box. I'm using fetchmail 5.8.17 and
procmail 3.21 and somewhere along the lines, something is
different. Now any messages that come in and get delivered with
rcvstore have '^M' at the ends
Okay, my reading of the rough consensus of the messages I've seen is,
Yes, do something, dammit. Here's what I think we should do:
- We should wait for Dan to say something. I just checked my exmh address
book, and the last message I ever saw from Dan was July 31st. So I'm
not even sure
Ken Hornstein [EMAIL PROTECTED] wrote:
At this point, I become the Grand High Poobah of nmh.
Great, politics already. :/
I _would_ like to do off-site backups of the CVS repository,
but assuming everything goes through, I'll work that off-line
with Doug.
Definately... It would be a
Sorry for barging in. Seems the fetchmail versions were different. Now
I have it explicitly stripping CRs from incoming mail, and everything
works nicely.
Zac
Ken Hornstein wrote:
Part of my motivation for a 2.0 release is to draw attention back to
I'd say it still only warrants a 1.1. There are insufficient new
features added or changed functionality. Leave 2.0 for a major
rewrite.
I think bumping a version number simply to draw attention to a
I'd say it still only warrants a 1.1. There are insufficient new
features added or changed functionality. Leave 2.0 for a major
rewrite.
Are you sure? Have you looked at the changes? There was a whole lot
of cleaning up that was done, and I don't think the security stuff was
insignificant
On Sat, 8 Dec 2001, Ken Hornstein wrote:
I'd say it still only warrants a 1.1. There are insufficient new
features added or changed functionality. Leave 2.0 for a major
rewrite.
I will side with Doug on this (Sorry if I'm being difficult ;-( ). My
reasons are explained below.
Are you
17 matches
Mail list logo
