GNU bug report logs -
#1809
decode-coding-inserted-region corrupts files
Previous Next
Reported by: Juri Linkov <juri <at> jurta.org>
Date: Tue, 6 Jan 2009 17:55:03 UTC
Severity: normal
Merged with 2416
Done: Chong Yidong <cyd <at> stupidchicken.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
This is an automatic notification regarding your bug report
which was filed against the emacs package:
#1809: 23.0.60; decode-coding-region
It has been closed by Chong Yidong <cyd <at> stupidchicken.com>.
Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Chong Yidong <cyd <at> stupidchicken.com> by
replying to this email.
--
1809: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1809
Emacs Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
> 2009-02-22 Andreas Schwab <schwab <at> linux-m68k.org>
>
> * insdel.c (del_range_2): Don't modify gap contents when
> called from decode_coding_object. (Bug#1809)
Thanks for fixing this bug.
[Message part 3 (message/rfc822, inline)]
I have been having this problem since I switched to Emacs 23 several
weeks ago. I'm using VM to read my mails. There seems to be a problem
in decode-coding-region when VM tries to decode a string. When VM
tries to decode a region or a string, it uses a temporary buffer and
basically runs the following lisp code:
(apply 'decode-coding-region (point-min) (point-max) 'us-ascii nil)
The original buffer content would be something like this:
B7040400-12
some text here
after decode-coding-region is executed, the buffer content became:
^@7040450-12
some text here
Where ^@ is actually binary code \0 (not ascii ^ and @). There is another instance
that a string was decoded and the result is ^@ prefixed.
I could not reproduce this with "Emacs -Q". But it always happens when
thsoe particular messages were processed by VM.
Strangely enough, if I inserted a few spaces at the beginning of
buffer: (one space in the following buffer)
B7040400-12
some text here
And, the decoding was done correctly. In another instance mentioned
above, one space is not enough. I had to put several spaces to get the
decoding working.
I saw another bug report just yesterday regarding decode-coding-region
crashing. I applied the patch, but it did not help in the
decoding.
Please let me know if you need other information to help understand
the problem. Thanks.
-----
Emacs version: "GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2009-01-29 on T42"
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -I../../GnuWin32/include'
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: ENU
value of $XMODIFIERS: nil
locale-coding-system: chinese-big5
default-enable-multibyte-characters: t
Major mode: Shell
Minor modes in effect:
auto-image-file-mode: t
shell-dirtrack-mode: t
tooltip-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
global-auto-composition-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
This bug report was last modified 16 years and 95 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.