This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.1 (patch 14) "Cuyahoga Valley" [Lucid] (i386-redhat-linux, Mule) of Mon Oct 15 2001 on stripples.devel.redhat.com configured using `configure i386-redhat-linux --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --datadir=/usr/share --libdir=/usr/lib --mandir=/usr/share/man/man1 --infodir=/usr/share/info --with-gpm=no --with-sound=native --with-pop --mail-locking=lockf --with-clash-detection --debug=no --error-checking=none --lockdir=/var/lock/xemacs --with-mule=yes --with-database=no --with-ldap=yes --with-hesiod=no --with-canna=yes --with-wnn=yes --with-wnn6=yes --with-menubars=lucid --with-scrollbars=lucid --with-dialogs=athena3d --with-xim=xlib --with-msw=no --with-xfs=yes' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: This bug involves a bad interaction between vm and xemacs; I'm not sure where to put the blame, so I'm reporting it to both places. The function vm reads in a mailbox file by binding coding-system-for-read to no-conversion (in the xemacs version), and doing find-file-noselect within the scope of that binding. vm then expects the resulting buffer's coding system to be no-conversion, but in fact it's taken from default-buffer-file-coding-system. As a result, vm later has to use encode-coding-region to get the buffer back into raw mode before processing it (which as I understand it is also a bug, since iso-2022-8 isn't a reversible encoding, but that's a subject for another bug report). This can take a lot of time for large mailboxes--to open a 12Mb mailbox on my machine, it takes 74 seconds if I have default-buffer-file-coding-system set to iso-2022-8, as opposed to 16 seconds if I have it set to no-conversion. Here's a little test case to illustrate the problem. The vm author apparently would expect this to return no-conversion, but it actually returns iso-2022-8. (set-default-buffer-file-coding-system 'iso-2022-8) ;; (that's already the default in xemacs 21.1.14, at least as distributed ;; with RedHat 7.2) (let ((coding-system-for-read 'no-conversion)) (find-file-noselect "foo")) (save-excursion (set-buffer "foo") buffer-file-coding-system) Recent keystrokes: TAB RET C-x b RET C-s c o d i n g - s y s t e m - f o r - r e a d C-s C-s C-s C-s C-v C-v C-v C-v C-v C-v C-v M-x e m a c s - c v BS BS v e r w i BS BS s i o n RET q C-x k RET M-x r e p o TAB r TAB BS BS BS BS BS BS BS BS BS C-g misc-user C-g C-x b C-g M-< M-> C-r b i n d C-a C-x C-s misc-user Recent messages (most recent first): Loading mail-abbrevs... Wrote /home/kaplan/vm-mod/ANK-notes Quit Quit Loading emacsbug...done Quit Loading emacsbug... Making completion list... Buffer is read-only: #<buffer "NEWS"> XEmacs 21.1 (patch 14) "Cuyahoga Valley" [Lucid] (i386-redhat-linux, Mule) of Mon Oct 15 2001 on stripples.devel.redhat.com