GNU bug report logs - #16286
24.3.50; insert-file-contents may bring invisible garbage

Previous Next

Full log

Message #11 received at 16286 <at> debbugs.gnu.org (full text, mbox):

From: Andrey Kotlarski <m00naticus <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Kenichi Handa <handa <at> gnu.org>, 16286 <at> debbugs.gnu.org
Subject: Re: bug#16286: 24.3.50;
 insert-file-contents may bring invisible garbage
Date: Sun, 05 Jan 2014 00:42:39 +0200

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.