Re: TRAMP copies binary files incorrectly
In [EMAIL PROTECTED] Kenichi Handa wrote: In article [EMAIL PROTECTED], Chris Moore [EMAIL PROTECTED] writes: Stefan Monnier [EMAIL PROTECTED] writes: Which function is it? I believe the function at fault is uudecode-decode-region Yes, it's uudecode-decode-region. Ok, I've just installed a fix to make it work on a multibyte buffer. I'm sorry for the late response but I noticed that uudecode.el bundled with Gnus now doesn't work with Emacs 21 and XEmacs because of `string-to-multibyte'. Since Gnus still supports those versions of Emacsen, we have the emulating function for it in mm-util.el as follows: --8---cut here---start-8--- (defalias 'mm-string-to-multibyte (cond ((featurep 'xemacs) 'identity) ((fboundp 'string-to-multibyte) 'string-to-multibyte) (t (lambda (string) Return a multibyte string with the same individual chars as string. (mapconcat (lambda (ch) (mm-string-as-multibyte (char-to-string ch))) string ) --8---cut here---end---8--- Is it possible to add a similar one to uudecode.el? I've tested the attached patch with Gnus v5.10.8 (aka v5.11). Thanks in advance. --8---cut here---start-8--- *** uudecode.el~Sun Jan 21 21:53:53 2007 --- uudecode.el Wed Jan 24 08:15:57 2007 *** *** 128,133 --- 128,147 (message Can not uudecode))) (ignore-errors (or file-name (delete-file tempfile)) + (eval-and-compile + (defalias 'uudecode-string-to-multibyte + (cond + ((featurep 'xemacs) + 'identity) + ((fboundp 'string-to-multibyte) + 'string-to-multibyte) + (t + (lambda (string) + Return a multibyte string with the same individual chars as string. + (mapconcat +(lambda (ch) (string-as-multibyte (char-to-string ch))) +string )) + ;;;###autoload (defun uudecode-decode-region-internal (start end optional file-name) Uudecode region between START and END without using an external program. *** *** 206,212 (or (markerp end) (setq end (set-marker (make-marker) end))) (goto-char start) (if enable-multibyte-characters ! (mapc #'(lambda (x) (insert (string-to-multibyte x))) (nreverse result)) (insert (apply 'concat (nreverse result (delete-region (point) end)) --- 220,226 (or (markerp end) (setq end (set-marker (make-marker) end))) (goto-char start) (if enable-multibyte-characters ! (mapc #'(lambda (x) (insert (uudecode-string-to-multibyte x))) (nreverse result)) (insert (apply 'concat (nreverse result (delete-region (point) end)) --8---cut here---end---8--- ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
In article [EMAIL PROTECTED], Katsumi Yamaoka [EMAIL PROTECTED] writes: In [EMAIL PROTECTED] Kenichi Handa wrote: In article [EMAIL PROTECTED], Chris Moore [EMAIL PROTECTED] writes: Stefan Monnier [EMAIL PROTECTED] writes: Which function is it? I believe the function at fault is uudecode-decode-region Yes, it's uudecode-decode-region. Ok, I've just installed a fix to make it work on a multibyte buffer. I'm sorry for the late response but I noticed that uudecode.el bundled with Gnus now doesn't work with Emacs 21 and XEmacs because of `string-to-multibyte'. Ah! :-( Since Gnus still supports those versions of Emacsen, we have the emulating function for it in mm-util.el as follows: --8---cut here---start-8--- (defalias 'mm-string-to-multibyte (cond ((featurep 'xemacs) 'identity) ((fboundp 'string-to-multibyte) 'string-to-multibyte) (t (lambda (string) Return a multibyte string with the same individual chars as string. (mapconcat (lambda (ch) (mm-string-as-multibyte (char-to-string ch))) string ) --8---cut here---end---8--- Is it possible to add a similar one to uudecode.el? I've tested the attached patch with Gnus v5.10.8 (aka v5.11). Yes. Please install your change. --- Kenichi Handa [EMAIL PROTECTED] --8---cut here---start-8--- *** uudecode.el~ Sun Jan 21 21:53:53 2007 --- uudecode.el Wed Jan 24 08:15:57 2007 *** *** 128,133 --- 128,147 (message Can not uudecode))) (ignore-errors (or file-name (delete-file tempfile)) + (eval-and-compile + (defalias 'uudecode-string-to-multibyte + (cond + ((featurep 'xemacs) + 'identity) + ((fboundp 'string-to-multibyte) + 'string-to-multibyte) + (t + (lambda (string) + Return a multibyte string with the same individual chars as string. + (mapconcat + (lambda (ch) (string-as-multibyte (char-to-string ch))) + string )) + ;;;###autoload (defun uudecode-decode-region-internal (start end optional file-name) Uudecode region between START and END without using an external program. *** *** 206,212 (or (markerp end) (setq end (set-marker (make-marker) end))) (goto-char start) (if enable-multibyte-characters ! (mapc #'(lambda (x) (insert (string-to-multibyte x))) (nreverse result)) (insert (apply 'concat (nreverse result (delete-region (point) end)) --- 220,226 (or (markerp end) (setq end (set-marker (make-marker) end))) (goto-char start) (if enable-multibyte-characters ! (mapc #'(lambda (x) (insert (uudecode-string-to-multibyte x))) (nreverse result)) (insert (apply 'concat (nreverse result (delete-region (point) end)) --8---cut here---end---8--- ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
In [EMAIL PROTECTED] Kenichi Handa wrote: In article [EMAIL PROTECTED], Katsumi Yamaoka [EMAIL PROTECTED] writes: uudecode.el bundled with Gnus now doesn't work with Emacs 21 and XEmacs because of `string-to-multibyte'. [...] + (defalias 'uudecode-string-to-multibyte [...] Yes. Please install your change. I've installed it in both the Gnus trunk and the v5-10 branch. The later will be merged into Emacs CVS soon. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
However, the underlying bug in `insert' remains I think. Stefan Monnier said the problem is that: | Basically, `insert' uses implicitly string-make-multibyte instead of | string-to-multibyte. I am not convinced this is a bug. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
Stefan Monnier [EMAIL PROTECTED] writes: Which function is it? I believe the function at fault is uudecode-decode-region Yes, it's uudecode-decode-region. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
Stefan Monnier [EMAIL PROTECTED] writes: But independently from whether we fix it or not, I believe that making the buffer unibyte is the right thing to do since it will only ever contain bytes, and never chars: using a multibyte buffer here is inefficient and is asking for trouble. I've committed a patch based on Chris' proposal. Stefan Best regards, Michael. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
Michael Albinus [EMAIL PROTECTED] writes: I've committed a patch based on Chris' proposal. The has fixed the problem with copying the image file using TRAMP's ssh method, thanks. However, the underlying bug in `insert' remains I think. Stefan Monnier said the problem is that: | Basically, `insert' uses implicitly string-make-multibyte instead of | string-to-multibyte. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
In article [EMAIL PROTECTED], Chris Moore [EMAIL PROTECTED] writes: Stefan Monnier [EMAIL PROTECTED] writes: Which function is it? I believe the function at fault is uudecode-decode-region Yes, it's uudecode-decode-region. Ok, I've just installed a fix to make it work on a multibyte buffer. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
Kenichi Handa [EMAIL PROTECTED] writes: In article [EMAIL PROTECTED], Chris Moore [EMAIL PROTECTED] writes: Stefan Monnier [EMAIL PROTECTED] writes: Which function is it? I believe the function at fault is uudecode-decode-region Yes, it's uudecode-decode-region. Ok, I've just installed a fix to make it work on a multibyte buffer. Maybe I'm missing something, but isn't the problem in `insert', not in individual uses of it? Stefan wrote: | I believe the function at fault is uudecode-decode-region, although | personally I think the problem is much deeper, in the implicit use of | unibyte-char-to-multibyte in `insert'. So if the root cause of this is in `insert', isn't that where it should be fixed? Otherwise there's a risk that there's other code which is broken in the same way that uudecode-decode-region was before your patch. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
In article [EMAIL PROTECTED], Chris Moore [EMAIL PROTECTED] writes: Michael Albinus [EMAIL PROTECTED] writes: I've committed a patch based on Chris' proposal. The has fixed the problem with copying the image file using TRAMP's ssh method, thanks. However, the underlying bug in `insert' remains I think. Stefan Monnier said the problem is that: | Basically, `insert' uses implicitly string-make-multibyte instead of | string-to-multibyte. But, that is currently a feature, an intentional one. We agree that it's not a good feature, but I believe we shouldn't change it before the release. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
I've committed a patch based on Chris' proposal. The has fixed the problem with copying the image file using TRAMP's ssh method, thanks. However, the underlying bug in `insert' remains I think. Stefan Monnier said the problem is that: | Basically, `insert' uses implicitly string-make-multibyte instead of | string-to-multibyte. But, that is currently a feature, an intentional one. We agree that it's not a good feature, but I believe we shouldn't change it before the release. Agreed. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
So if the root cause of this is in `insert', isn't that where it should be fixed? Otherwise there's a risk that there's other code which is broken in the same way that uudecode-decode-region was before your patch. Yes, but there's also code that relies on the current behavior. Now's not the time to make such far reaching changes. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
Date: Wed, 10 Jan 2007 21:04:19 +0100 From: Chris [EMAIL PROTECTED] I have a 1 byte file on a remote server. If I use 'scp' to copy the file to my local machine, it copies correctly, but if I use: $ emacs -Q (copy-file /ssh:[EMAIL PROTECTED]:~/file /tmp/file) C-j to copy it, then the resulting local file is 2 bytes long. I used hexl-mode to compare the two files: 1 byte correct version: : ce . 2 byte broken version: : 81ce .. Could it be that Emacs is doing some kind of character-encoding conversion? Tramp does some complicated encode/decode stuff to send the file on the wire (since ssh is just a filter, so binary stuff cannot be easily sent verbatim). However, I just tried this, and I cannot reproduce the problem with the current CVS: I get an exact replica of the original file on my local machine. Do _all_ files from that machine copy incorrectly? Or just some? Also, could you show the contents of the *Messages* buffer after the copy operation finishes? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
Eli Zaretskii [EMAIL PROTECTED] writes: Do _all_ files from that machine copy incorrectly? Or just some? No. Plain text files copy correctly for example. And I just noticed that using /scp:... instead of /ssh:... works fine, too. I only used ssh in the first place because I didn't have ssh-agent running and the scp method prompts for the password over and over. Also, could you show the contents of the *Messages* buffer after the copy operation finishes? Certainly, but I don't know how much it will help. You see I have 2 machine here, both running debian sid. On one I can copy the 1-byte file and on the other it turns into a 2-byte file. The *Messages* buffer is identical on the 2 machines (other than the name of the temporary file used, which looks to be random). Here it is: Loading tramp... Loading regexp-opt...done Loading tramp...done tramp: Opening connection for [EMAIL PROTECTED] using ssh... tramp: Waiting for prompts from remote shell tramp: Waiting 60s for prompt from remote shell tramp: Sending password tramp: Found remote shell prompt. tramp: Initializing remote shell Loading time-date...done tramp: Waiting 30s for remote `/bin/sh' to come up... tramp: Setting up remote shell environment tramp: Checking remote host type for `send-process-string' bug tramp: Determining coding system tramp: Waiting 30s for `HISTFILE=$HOME/.tramp_history; HISTSIZE=1; export HISTFILE; export HISTSIZE' tramp: Waiting 30s for `set +o vi +o emacs' tramp: Waiting 30s for `unset MAIL MAILCHECK MAILPATH' tramp: Waiting 30s for `unset CDPATH' tramp: Setting shell prompt tramp: Remote `/bin/sh' groks tilde expansion, good tramp: Finding command to check if file exists tramp: Finding a suitable `ls' command tramp: Checking remote `/usr/xpg4/bin/ls' command for `-n' option tramp: Checking remote `/bin/ls' command for `-n' option tramp: Testing remote command `/bin/ls' for -n...okay tramp: Using remote command `/bin/ls' for getting directory listings tramp: Sending the Perl `mime-encode' implementations. tramp: Sending the Perl `mime-decode' implementations. tramp: Checking remote encoding command `mimencode -b' for sanity tramp: Checking remote encoding command `mmencode -b' for sanity tramp: Checking remote encoding command `recode data..base64' for sanity tramp: Checking remote encoding command `uuencode xxx' for sanity tramp: Checking remote decoding command `uudecode -o /dev/stdout' for sanity tramp: Checking to see if encoding/decoding commands work on remote host...done tramp: Sending the Perl script `tramp_file_attributes'...done. tramp: Encoding remote file /ssh:[EMAIL PROTECTED]:/home/dooglus/image1... tramp: Decoding remote file /ssh:[EMAIL PROTECTED]:/home/dooglus/image1... tramp: Decoding remote file /ssh:[EMAIL PROTECTED]:/home/dooglus/image1 with function uudecode-decode-region... Loading uudecode...done Wrote /tmp/tramp.5003zUW tramp: Decoding remote file /ssh:[EMAIL PROTECTED]:/home/dooglus/image1...done tramp: Inserting local temp file `/tmp/tramp.5003zUW'...done Wrote /tmp/file Loading dired...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
Eli Zaretskii [EMAIL PROTECTED] writes: I just tried this, and I cannot reproduce the problem with the current CVS: I get an exact replica of the original file on my local machine. I found what was causing the problem: I didn't have uudecode installed on the local machine, so TRAMP was using Emacs' Lisp version of uudecode, and using Emacs' write-region to save the results to a file. tramp.el is careful to bind coding-system-for-write to 'binary when writing the region: (let ((coding-system-for-write 'binary)) (funcall loc-dec (point-min) (point-max)) (write-region (point-min) (point-max) tmpfil)) but unfortunately that's not enough to stop write-region playing with multi-byte characters - and that's probably the real bug. The *tramp tmp* buffer has coding-system-for-write set to 'binary, but also has enable-multibyte-characters set to t. write-region uses fileio.c's e_write(), and that does the following, copying the buffer's value of enable-multibyte-characters into the coding system, before using it to write the region: coding-src_multibyte = !NILP (current_buffer-enable_multibyte_characters); My question is: should having the coding-system-for-write set to 'binary be enough to stop any multi-byte processing being done on write, regardless of the value of enable-multibyte-characters? And if so, shouldn't we tell e_write() about it? This patch demonstrates that it is enable-multibyte-characters which causes the problem, but I suspect that the bug really needs fixing in the C code: --- lisp/net/tramp.el 2007-01-11 01:19:46.0 +0100 +++ lisp/net/new/tramp.el 2007-01-11 01:18:59.0 +0100 @@ -3827,6 +3827,7 @@ ;; line from the output here. Go to point-max, ;; search backward for tramp_exit_status, delete ;; between point and point-max if found. +(set-buffer-multibyte nil) (let ((coding-system-for-write 'binary)) (funcall loc-dec (point-min) (point-max)) (write-region (point-min) (point-max) tmpfil)) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
In article [EMAIL PROTECTED], Chris [EMAIL PROTECTED] writes: I have a 1 byte file on a remote server. If I use 'scp' to copy the file to my local machine, it copies correctly, but if I use: $ emacs -Q (copy-file /ssh:[EMAIL PROTECTED]:~/file /tmp/file) C-j to copy it, then the resulting local file is 2 bytes long. I used hexl-mode to compare the two files: 1 byte correct version: : ce . 2 byte broken version: : 81ce .. Could it be that Emacs is doing some kind of character-encoding conversion? The byte sequence 0x81 0xCE looks like Emacs' internal character representation for ISO-8859-1 0xCE character. So, it seems that Emacs is doing character-DECODING conversion on reading that 1-byte file, and then it writes without encoding it back. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
tramp.el is careful to bind coding-system-for-write to 'binary when writing the region: (let ((coding-system-for-write 'binary)) (funcall loc-dec (point-min) (point-max)) (write-region (point-min) (point-max) tmpfil)) but unfortunately that's not enough to stop write-region playing with multi-byte characters - and that's probably the real bug. The problem is not really in write-region but in the code before: there's no way write-region can correctly write a multibyte char in binary. Write-region should probably just burp here rather than write something which is likely to be incorrect. The *tramp tmp* buffer has coding-system-for-write set to 'binary, but also has enable-multibyte-characters set to t. That's not a problem per se as long as the region passed to write-region doesn't contain any multibyte char (i.e. non-ascii and non-eight-bit-*). My question is: should having the coding-system-for-write set to 'binary be enough to stop any multi-byte processing being done on write, regardless of the value of enable-multibyte-characters? And if so, shouldn't we tell e_write() about it? No. The problem seems to be that in uudecode.el the call to insert ends up internally converting the unibyte chars into multibyte chars (via unibyte-char-to-multibyte) when inserting them into the multibyte buffer. Basically, `insert' uses implicitly string-make-multibyte instead of string-to-multibyte. --- lisp/net/tramp.el 2007-01-11 01:19:46.0 +0100 +++ lisp/net/new/tramp.el 2007-01-11 01:18:59.0 +0100 @@ -3827,6 +3827,7 @@ ;; line from the output here. Go to point-max, ;; search backward for tramp_exit_status, delete ;; between point and point-max if found. + (set-buffer-multibyte nil) (let ((coding-system-for-write 'binary)) (funcall loc-dec (point-min) (point-max)) (write-region (point-min) (point-max) tmpfil)) This patch looks correct, although I'd move the line earlier to right after `erase-buffer' where set-buffer-multibyte will be more efficient. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
In article [EMAIL PROTECTED], Chris Moore [EMAIL PROTECTED] writes: I didn't have uudecode installed on the local machine, so TRAMP was using Emacs' Lisp version of uudecode, and using Emacs' write-region to save the results to a file. tramp.el is careful to bind coding-system-for-write to 'binary when writing the region: (let ((coding-system-for-write 'binary)) (funcall loc-dec (point-min) (point-max)) (write-region (point-min) (point-max) tmpfil)) but unfortunately that's not enough to stop write-region playing with multi-byte characters - and that's probably the real bug. The *tramp tmp* buffer has coding-system-for-write set to 'binary, but also has enable-multibyte-characters set to t. I think that's the problem. How that buffer is created? How the contents was inserted in that buffer? write-region uses fileio.c's e_write(), and that does the following, copying the buffer's value of enable-multibyte-characters into the coding system, before using it to write the region: coding-src_multibyte = !NILP (current_buffer-enable_multibyte_characters); My question is: should having the coding-system-for-write set to 'binary be enough to stop any multi-byte processing being done on write, regardless of the value of enable-multibyte-characters? And if so, shouldn't we tell e_write() about it? In a multibyte buffer, raw byte data, say 0x81, is represented not by that byte itself but by 0x20 added and with preceding special byte 0x9E (so the byte sequence is 0x9E 0xA1) to distinguish it from a normal multibyte character (e.g. iso-8859-1's 0xC0 (A-grave) is represented by 0x81 0xC0). So, the writing process should convert 0x9E 0xA1 back to 0x81. The flag coding-src_multibyte tells if that kind of conversion is necessary or not. This patch demonstrates that it is enable-multibyte-characters which causes the problem, but I suspect that the bug really needs fixing in the C code: --- lisp/net/tramp.el 2007-01-11 01:19:46.0 +0100 +++ lisp/net/new/tramp.el 2007-01-11 01:18:59.0 +0100 @@ -3827,6 +3827,7 @@ ;; line from the output here. Go to point-max, ;; search backward for tramp_exit_status, delete ;; between point and point-max if found. + (set-buffer-multibyte nil) (let ((coding-system-for-write 'binary)) (funcall loc-dec (point-min) (point-max)) (write-region (point-min) (point-max) tmpfil)) No. That change runs the function loc-dec in a unibyte buffer after 0x9E 0xA1 being converted back to 0x81 by (set-buffer-multibyte nil). That make the difference. But, as Stefan wrote, it is better to call (set-buffer-multibyte nil) much earlier. Anyway, it is better to fix the function bound to loc-dec to work in a multibyte buffer too. Which function is it? --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
But, as Stefan wrote, it is better to call (set-buffer-multibyte nil) much earlier. Anyway, it is better to fix the function bound to loc-dec to work in a multibyte buffer too. Which function is it? I believe the function at fault is uudecode-decode-region, although personally I think the problem is much deeper, in the implicit use of unibyte-char-to-multibyte in `insert'. But independently from whether we fix it or not, I believe that making the buffer unibyte is the right thing to do since it will only ever contain bytes, and never chars: using a multibyte buffer here is inefficient and is asking for trouble. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP copies binary files incorrectly
In article [EMAIL PROTECTED], Stefan Monnier [EMAIL PROTECTED] writes: But, as Stefan wrote, it is better to call (set-buffer-multibyte nil) much earlier. Anyway, it is better to fix the function bound to loc-dec to work in a multibyte buffer too. Which function is it? I believe the function at fault is uudecode-decode-region, although personally I think the problem is much deeper, in the implicit use of unibyte-char-to-multibyte in `insert'. Right. But independently from whether we fix it or not, I believe that making the buffer unibyte is the right thing to do since it will only ever contain bytes, and never chars: using a multibyte buffer here is inefficient and is asking for trouble. I agree. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
