From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#33567: Syntactic fontification of diff hunks Date: Wed, 05 Dec 2018 09:19:55 +0200 Message-ID: <83sgzc8mp0.fsf@gnu.org> References: <878t18j4is.fsf@mail.linkov.net> <83a7lobemr.fsf@gnu.org> <87a7lnv6ex.fsf@mail.linkov.net> <83pnuj9kb8.fsf@gnu.org> <87bm62npwr.fsf@mail.linkov.net> <83a7llai7v.fsf@gnu.org> <87va4826tz.fsf@mail.linkov.net> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1543994347 3194 195.159.176.226 (5 Dec 2018 07:19:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 5 Dec 2018 07:19:07 +0000 (UTC) Cc: 33567@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Dec 05 08:19:02 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gURSX-0000b8-I1 for geb-bug-gnu-emacs@m.gmane.org; Wed, 05 Dec 2018 08:19:01 +0100 Original-Received: from localhost ([::1]:60600 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gURUe-0006Vs-7r for geb-bug-gnu-emacs@m.gmane.org; Wed, 05 Dec 2018 02:21:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58772) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gURUX-0006Vm-V1 for bug-gnu-emacs@gnu.org; Wed, 05 Dec 2018 02:21:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gURUU-0005J4-Og for bug-gnu-emacs@gnu.org; Wed, 05 Dec 2018 02:21:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57023) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gURUU-0005Is-KC for bug-gnu-emacs@gnu.org; Wed, 05 Dec 2018 02:21:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gURUU-0004NE-A2 for bug-gnu-emacs@gnu.org; Wed, 05 Dec 2018 02:21:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 05 Dec 2018 07:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33567 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 33567-submit@debbugs.gnu.org id=B33567.154399441016729 (code B ref 33567); Wed, 05 Dec 2018 07:21:02 +0000 Original-Received: (at 33567) by debbugs.gnu.org; 5 Dec 2018 07:20:10 +0000 Original-Received: from localhost ([127.0.0.1]:33048 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gURTd-0004Lk-US for submit@debbugs.gnu.org; Wed, 05 Dec 2018 02:20:10 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:48707) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gURTd-0004LU-5V for 33567@debbugs.gnu.org; Wed, 05 Dec 2018 02:20:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gURTU-0004Qp-Kh for 33567@debbugs.gnu.org; Wed, 05 Dec 2018 02:20:03 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47565) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gURTU-0004Qf-G4; Wed, 05 Dec 2018 02:20:00 -0500 Original-Received: from [176.228.60.248] (port=1671 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gURTU-0007mT-3t; Wed, 05 Dec 2018 02:20:00 -0500 In-reply-to: <87va4826tz.fsf@mail.linkov.net> (message from Juri Linkov on Wed, 05 Dec 2018 01:16:48 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:153095 Archived-At: > From: Juri Linkov > Cc: 33567@debbugs.gnu.org > Date: Wed, 05 Dec 2018 01:16:48 +0200 > > >> I tried to remove coding-system-for-read binding from > >> vc-find-revision-no-save, but it still fails to get the buffer > >> in the right encoding. > > > > What is "the right encoding", > > By the right encoding I meant the same encoding that is detected > when write-region saves the file, e.g. when using the macro > with-temp-file in vc-find-revision-save. I don't know how > write-region detects the encoding for the saved file, but we need > the same encoding for the buffer that is not saved to the file > in vc-find-revision-no-save. > > > and what did Emacs think the encoding was, when you didn't bind > > coding-system-for-read? These details are necessary to understand > > what exactly happens there and how to solve it. > > vc-git-find-revision binds coding-system-for-read to `binary'. I see that vc-hg-find-revision does the same. Sigh. I guess the find-revision API was never meant to process the resulting buffer normally. My advice would be to reimplement your vc-find-revision-no-save function differently, without trying to piggy-back the fact that vc-find-revision inserts the contents into a buffer. That is, let the code write the contents to a temporary file, like vc-find-revision does, then call insert-file-contents to re-read that file normally. It would be slightly less efficient, but I think the result will be much simpler, so a net win. If you still want to reuse the literal contents of the file, as inserted by vc-git-find-revision etc., then you will have to duplicate what insert-file-contents does internally. I suggest to look at how this is done in archive-set-buffer-as-visiting-file. > > How do you know vc-git-find-revision doesn't have a subtle bug as > > well, e.g. when file names in the repository are encoded in some > > non-trivial, non-UTF-8 encoding? > > This is why vc-git-find-revision does nothing with its output > when it binds coding-system-for-read to `binary', > and doesn't try to encode/decode the git output. vc-git-find-revision does _something_ with Git's output: it uses the file name returned by Git. That file name could have a non-trivial encoding. > vc-git-find-revision returns the output undecoded. I don't know > other way to decode it to the default coding other than recode-region. See above.