[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#16286: 24.3.50; insert-file-contents may bring invisible garbage
From: |
Andrey Kotlarski |
Subject: |
bug#16286: 24.3.50; insert-file-contents may bring invisible garbage |
Date: |
Sun, 05 Jan 2014 00:42:39 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
Thanks a lot for the hints and pointers.
[ 2 януари 2014, 18:30 +0200, четвъртък ] Eli Zaretskii:
> What vlf does is strange and IMO not the best possible solution to
> this issue:
> ...
> This seems to have a subtle misfeature of not supporting files with
> inconsistent encoding, or files with binary data, because there _all_
> characters will belong to the eight-bit charset.
There had been changes meanwhile which hopefully address these (no
special treatment of eight-bit) along other issues (vlf-base.el).
> More to the point, I'm not sure whether inserting raw bytes in
> insert-file-contents when a portion of a multibyte sequence was read
> (i.e. go back to what Emacs 24.3 did) will be good for vlf. It sounds
> to me much better if Emacs would only return complete characters read
> from the file, so that applications will not need to remove those
> stray bytes.
I agree. It would be ideal for vlf if insert-file-contents would also
report the number of stray bytes at the end that haven't been utilized.
> Finally, it would seem a better design for vlf to always read a few
> more bytes than was requested into some scratch buffer, and then
> decode them manually to determine just how many to copy to the main
> buffer.
I see that vlf somehow works only by some accident with current trunk
(and --enable-checking disabled), so I'm on it. My initial attempt at
naively combining insert-file-contents-literally with
decode-coding-inserted-region though often produces wrong decoding where
insert-file-contents would be good.