bug#16286: 24.3.50; insert-file-contents may bring invisible garbage

[Andrey Kotlarski <m00naticus@gmail.com>]

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.