From xemacs-m  Mon Mar 10 07:10:48 1997
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3])
	by xemacs.org (8.8.5/8.8.5) with SMTP id HAA22409
	for <xemacs-beta@xemacs.org>; Mon, 10 Mar 1997 07:10:47 -0600 (CST)
Received: from helios (actually helios.tnt.uni-hannover.de) by mgate 
          with SMTP (PP); Mon, 10 Mar 1997 14:10:51 +0100
Received: from daedalus.tnt.uni-hannover.de by helios (SMI-8.6/SMI-SVR4) 
          id OAA10978; Mon, 10 Mar 1997 14:10:11 +0100
Received: by daedalus.tnt.uni-hannover.de (SMI-8.6/SMI-SVR4) id OAA26302;
          Mon, 10 Mar 1997 14:10:09 +0100
Date: Mon, 10 Mar 1997 14:10:09 +0100
Message-Id: <199703101310.OAA26302@daedalus.tnt.uni-hannover.de>
From: Heiko Muenkel <muenkel@tnt.uni-hannover.de>
MIME-Version: 1.0
To: kyle_jones@wonderworks.com
Cc: xemacs-beta@xemacs.org
Subject: Re: Bug in vm
In-Reply-To: <QQcftx03390.199703070229@crystal.WonderWorks.COM>
References: <199702271328.OAA09887@daedalus.tnt.uni-hannover.de> <199702271348.OAA10286@daedalus.tnt.uni-hannover.de> <QQcesq19835.199702271708@crystal.WonderWorks.COM> <199703070225.DAA22264@daedalus.tnt.uni-hannover.de> <QQcftx03390.199703070229@crystal.WonderWorks.COM>
X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2> 
        y]f{HzB|Q(\V9+y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{ 
        HS@NEv9c.VII+9PgXHASx}K(jy^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!] 
        4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_xzuXJJ7W(EGqnzB]`]aq??;+z=) 
        DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H<R5S[:ZN%B:s0;|v1x"Jb
Content-Type: text/plain; charset=US-ASCII

>>>>> "Kyle" == Kyle Jones <kyle_jones@wonderworks.com> writes:

    Kyle> Heiko Muenkel writes: NUL (ASCII code 0) cannot be
    Kyle> transmitted reliably without encoding.  Since NULs usually
    Kyle> mean binary data, VM chose base64 encoding.  The problem
    Kyle> with your message is that there was no
    Kyle> content-transfer-encoding header.  I suspect that something
    Kyle> stripped it out in transit.
    >>  I think, that there was no content-transfer-encoding header in
    >> my mail, because I did not add such a header and I did not add
    >> such a header, because I did not expect, that VM encoded my
    >> mail. vm should display a warning message (not sure, if there
    >> wasn't such a message :-)) and add a content-transfer-encoding
    >> header, if it converts text automaticly.

    Kyle> VM automatically adds the header if it encodes the mail.
    Kyle> That's why I think something stripped it out.

Hmm. I'm using tm together with vm. Do you or anyone else think, that
this could be the reason?

If there's something which stripes the header out, than it must be in
the XEmacs, because after sending the mail the mail in the mail
compose buffer looks like the one in the "mail receiving buffer",
coded and without a header.


    Kyle> Sending mail at 0325, eh?  Feeding the little one, I take
    Kyle> it? :-)

No. We've luck. Most nights she sleeps between 23:30 and 06:30 and
aside from that, at the moment my wife is the only one who can feed
her - and that's my luck :-). 

But she and her brother are making us busy the rest of the day. So
sometimes I've to work at night and last week I had over 1000 emails
in may mail boxes and that takes a long time to read :-(.

And by the way: There should be a better and faster way to delete
multiple messages (I know of the prefix args and of the mark mail
command). What I'm missing is something like
vm-delete-messages-in-the-range-from-to which needs the start message
number and the end message number or vm-delete-messages-in-the-region
or vm-delete-all-unread-messages or
vm-delete-all-unread-messages-until-this-message or
vm-delete-this-thread.

I'm also thinking about another new feature to speed up the reading of
emails with vm. I'm one of these stupid guys with big mail boxes. I'm
already sorting my mail in different mail boxes with procmail, but in
some of my mail boxes there are over 1000 mails - too much to handle
them realy fast with vm in the XEmacs. The reason for not deleting and
expunging them direct after reading is, that I want to store them a
few days until it is very unlikly, that I need them again. There are
also some mails, that I want to keep over a longer time. So currently,
I delete mails, which could be deleted in a few days and undelete the
rest. Then from time to time I realy delete the messages by expunging
the folders. But this leads to very big mail boxes. I think it would
be better to move mails after a few weeks or days to other associated
mail boxes, so that you've only the actual mails of the last week
(month, ...) in the main mail boxes. This should be done automatic,
may be by vm once a week. It should be easy to move to such an
associated mail box (eg: If you read the first mail of a mail box and
you run a command to get the previous message, then you should get the
last message of the previous, associated mail box).

Here's an example of what I'd like to have:

Let's assume that there's an inboxes foo, then you should have an
inbox directory with a subdirectory called foo. The contents
of this directory should be:

foo:
	current		<- the real inbox foo, current mail
	foo.1		<- oldest mail from the inbox foo
	foo.2		<- old mail from the inbox foo

In this example all readed email, which is newer than a specific date
(let's assume the 1. March), is in the mail folder current. All
unreaded email is also in this mail folder. In foo.2 all readed mail
from the 1. February until the 28. February is in the Folder
foo.2. and older mail is in foo.1. This should keep the folder current
small, so that it could be read faster. During the automatic move of
messages from current to foo.2 all mails marked as deleted should be
realy deleted instead of moved.

Kyle, what do you think about this?

