Installed vm 6.93-1 (i386 source all)
-----BEGIN PGP SIGNED MESSAGE-----
Format: 1.7
Date: Wed, 4 Jul 2001 14:31:49 -0500
Source: vm
Binary: mime-codecs vm
Architecture: source i386 all
Version: 6.93-1
Distribution: unstable
Urgency: low
Maintainer: Manoj Srivastava <srivasta@debian.org>
Changed-By: Manoj Srivastava <srivasta@debian.org>
Description:
mime-codecs - Fast Quoted-Printable and BASE64 MIME transport codecs
vm - A mail user agent for Emacs
Changes:
vm (6.93-1) unstable; urgency=low
.
* New upstream version.
* Excerpted changes:
* New variables:
+ vm-folder-file-precious-flag
* added CRAM-MD5 as an authentication method for IMAP.
* vm-su-do-date: interpret 2-digit years in the RFC-822 matching
case as 20XX if year starts with 0-6.
* vm-rfc1153-or-rfc934-burst-message: skip spaces in addition to
newlines that occur after a separator line. A digest has been
observed with that kind of deformity.
* treat enable-local-eval as we do enable-local-variables--- always
bind it to nil.
* vm: don't bind vm-auto-decode-mime-messages non-nil during
initial message preview if it is nil.
* vm-mime-display-internal-text/html: dropped (sleep-for 2). No one
cares enough about the "Need W3 to inline HTML" message to wait 2
seconds afterward.
* added menu entry to allow MIME objects to be converted to
another type and displayed. The new type is determined by
vm-mime-type-converter-alist.
* added koi8-r to vm-mime-mule-charset-to-coding-alist (XEmacs only).
* vm-pop-read-list-response: check for nil return of
vm-pop-read-response before using return value.
* vm-pop-read-stat-response: check for nil return of
vm-pop-read-response before using return value.
* vm-encode-coding-region: use unwind-protect to make sure (well
more likely) that the work buffer always gets killed if it has
been created.
* vm-decode-coding-region: use unwind-protect to make sure (well
more likely) that the work buffer always gets killed if it has
been created.
* vm-mime-convert-undisplayable-layout: put object buffer on
garbage list sooner to make rarer the situation where the
buffer never gets deleted.
* Makefile: remove function definition of vm-its-such-a-cruel-world
after it is run.
* vm-md5-region: if vm-pop-md5-program exits non-zero, signal an
error. Also if the work buffer is not at least 32 bytes long,
signal an error. This prevents naive callers from assumption all
is well and using a possibly empty string as an MD5 hash.
* vm-md5-region: check the MD5 digest returned for non-hex-digit
characters and signal an error if any are found.
* vm-get-file-buffer: use find-buffer-visiting if it is fbound.
* vm-build-threads: fixed loop that removed child messages from a
parent when better information about a child's parent is found.
Previously the loop attempted to remove the same message from
the parent over and over.
* vm-build-threads: gather thread data using References and
In-Reply-To for all messages before using the Subject header.
This helps prevent the case where References says A is the
parent of B but because of clock skew B is older than A, which
can lead to B being considered the parent of A if A and B have
the same subject and vm-thread-using-subject is non-nil.
Files:
6f8ac8c9901d428a1ad8dbb7502750ee 595 mail optional vm_6.93-1.dsc
1d332a60c9e3cbd621ee2f06bdabdb36 343689 mail optional vm_6.93.orig.tar.gz
6a4d1026b5dc89e79332f1cffb642e46 55267 mail optional vm_6.93-1.diff.gz
4ffb56d0cadb53e73e4234e12af0d716 47022 utils optional mime-codecs_6.93-1_i386.deb
f1f411da7a2e410afe979d0199416e8a 507022 mail optional vm_6.93-1_all.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7Q3E3Ibrau78kQkwRAQA6AJ9zPbFcCQCw/qZVOVUTRG0bV6iTJQCg74eX
25DRXcdoV2tB53uXUzclbIM=
=Uqet
-----END PGP SIGNATURE-----
Installed:
mime-codecs_6.93-1_i386.deb
to pool/main/v/vm/mime-codecs_6.93-1_i386.deb
vm_6.93-1.dsc
to pool/main/v/vm/vm_6.93-1.dsc
vm_6.93-1.diff.gz
to pool/main/v/vm/vm_6.93-1.diff.gz
vm_6.93.orig.tar.gz
to pool/main/v/vm/vm_6.93.orig.tar.gz
vm_6.93-1_all.deb
to pool/main/v/vm/vm_6.93-1_all.deb
Reply to: