From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andrey Kotlarski Newsgroups: gmane.emacs.bugs Subject: bug#16286: 24.3.50; insert-file-contents may bring invisible garbage Date: Sun, 05 Jan 2014 00:42:39 +0200 Message-ID: <87ob3rqsgw.fsf@gmail.com> References: <87sitb4usd.fsf@gmail.com> <83y52yxs61.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1388875398 874 80.91.229.3 (4 Jan 2014 22:43:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 Jan 2014 22:43:18 +0000 (UTC) Cc: 16286@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 04 23:43:24 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VzZw8-0003fq-El for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Jan 2014 23:43:20 +0100 Original-Received: from localhost ([::1]:55954 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzZw8-0004RO-3Q for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Jan 2014 17:43:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47968) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzZvy-0004R2-29 for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2014 17:43:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VzZvq-0000Nt-OC for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2014 17:43:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:48791) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzZvq-0000Np-L2 for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2014 17:43:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VzZvq-0007Fn-9q for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2014 17:43:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Andrey Kotlarski Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Jan 2014 22:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16286 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16286-submit@debbugs.gnu.org id=B16286.138887535027840 (code B ref 16286); Sat, 04 Jan 2014 22:43:02 +0000 Original-Received: (at 16286) by debbugs.gnu.org; 4 Jan 2014 22:42:30 +0000 Original-Received: from localhost ([127.0.0.1]:34577 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VzZvK-0007Ey-B7 for submit@debbugs.gnu.org; Sat, 04 Jan 2014 17:42:30 -0500 Original-Received: from mail-ee0-f42.google.com ([74.125.83.42]:54710) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VzZvI-0007Ep-8o for 16286@debbugs.gnu.org; Sat, 04 Jan 2014 17:42:28 -0500 Original-Received: by mail-ee0-f42.google.com with SMTP id e53so7320313eek.1 for <16286@debbugs.gnu.org>; Sat, 04 Jan 2014 14:42:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=+3mZDZn1myQqixZd2TyEbgtGbAYxwhOQ+CAFGMWVnOw=; b=rvGZHrHNuFX0Oja6ayhosKEw7ZFuV7/FtqrpWNKk9FScLjTD4YI6HaJlbOr5IzVNsC /TNwXl7U0Qks4em2gRMFbX6A6g0o8h+WHTzVlZct/G9D9yfTQ7mQh3ud1sqUnWzFtBtN VvVD0VPoKfYLPmrP9hAGGe+TtM2ugeYZ23ArraGjNhC9n1dy0P17i+bbmvPoqL0AHtfg 47cmNobftOkuPZ6Q9HVKeXHX86Ifr7tI5OPnxIPxpGOe11luHNeYB0ok3jspLt9Au4lJ Hx6s6tpyH+Z7t+THo5wfcLK80V7/qQWzozK5c5227WRHZNQuugXyhYvg/ymoP3tV0Uha 85GQ== X-Received: by 10.14.3.1 with SMTP id 1mr8244288eeg.94.1388875347346; Sat, 04 Jan 2014 14:42:27 -0800 (PST) Original-Received: from andrexhe (77-85-30-63.btc-net.bg. [77.85.30.63]) by mx.google.com with ESMTPSA id e43sm157139755eep.7.2014.01.04.14.42.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Jan 2014 14:42:26 -0800 (PST) In-Reply-To: <83y52yxs61.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 02 Jan 2014 18:30:30 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:82952 Archived-At: Thanks a lot for the hints and pointers. [ 2 =D1=8F=D0=BD=D1=83=D0=B0=D1=80=D0=B8 2014, 18:30 +0200, =D1=87=D0=B5= =D1=82=D0=B2=D1=8A=D1=80=D1=82=D1=8A=D0=BA ] 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.