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: Tue, 11 Dec 2018 08:23:37 +0200 Message-ID: <83tvjk1t06.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> <83sgzc8mp0.fsf@gnu.org> <87a7lcj2f8.fsf@mail.linkov.net> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1544509389 16986 195.159.176.226 (11 Dec 2018 06:23:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 11 Dec 2018 06:23:09 +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 Tue Dec 11 07:23:05 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 1gWbRf-0004IK-Ny for geb-bug-gnu-emacs@m.gmane.org; Tue, 11 Dec 2018 07:23:03 +0100 Original-Received: from localhost ([::1]:36203 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWbTl-00009A-RL for geb-bug-gnu-emacs@m.gmane.org; Tue, 11 Dec 2018 01:25:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45063) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWbTf-00008d-78 for bug-gnu-emacs@gnu.org; Tue, 11 Dec 2018 01:25:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gWbTa-00042p-BN for bug-gnu-emacs@gnu.org; Tue, 11 Dec 2018 01:25:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:38387) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gWbTa-00042e-6b for bug-gnu-emacs@gnu.org; Tue, 11 Dec 2018 01:25:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gWbTa-0003go-1F for bug-gnu-emacs@gnu.org; Tue, 11 Dec 2018 01:25: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: Tue, 11 Dec 2018 06:25:01 +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.154450944314102 (code B ref 33567); Tue, 11 Dec 2018 06:25:01 +0000 Original-Received: (at 33567) by debbugs.gnu.org; 11 Dec 2018 06:24:03 +0000 Original-Received: from localhost ([127.0.0.1]:42645 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gWbSc-0003fN-OT for submit@debbugs.gnu.org; Tue, 11 Dec 2018 01:24:03 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:35272) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gWbSY-0003eq-6z for 33567@debbugs.gnu.org; Tue, 11 Dec 2018 01:23:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gWbSO-00033G-AN for 33567@debbugs.gnu.org; Tue, 11 Dec 2018 01:23:53 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55979) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWbSO-000334-6M; Tue, 11 Dec 2018 01:23:48 -0500 Original-Received: from [176.228.60.248] (port=1900 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gWbSN-0007U0-Py; Tue, 11 Dec 2018 01:23:48 -0500 In-reply-to: <87a7lcj2f8.fsf@mail.linkov.net> (message from Juri Linkov on Tue, 11 Dec 2018 02:38:18 +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:153343 Archived-At: > From: Juri Linkov > Cc: 33567@debbugs.gnu.org > Date: Tue, 11 Dec 2018 02:38:18 +0200 > > > 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. > > I looked at archive-set-buffer-as-visiting-file, and it seems it could > be simplified based on the assumption that the backend inserts output > in the binary coding. "Binary coding" means what we have in the buffer is exactly what we had on disk. IOW, we have there the contents of the file in its original encoding, and so decoding it correctly needs to use the same facilities we normally use when visiting a file with the likes of find-file. archive-set-buffer-as-visiting-file solves precisely the same problem. > I tried and this fixes the problem: > > diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el > index 5ff9f4d5be..c980369fa9 100644 > --- a/lisp/vc/vc.el > +++ b/lisp/vc/vc.el > @@ -2042,6 +2042,7 @@ vc-find-revision-no-save > (if backend > (vc-call-backend backend 'find-revision file revision outbuf) > (vc-call find-revision file revision outbuf)))) > + (recode-region (point-min) (point-max) buffer-file-coding-system 'binary) Where does the value of buffer-file-coding-system come from here? Isn't that just (default-value 'buffer-file-coding-system)? If so, you were just lucky that it worked for you; in general, if the encoding of the file is different from your locale-derived defaults, the above won't DTRT. In any case, really don't think recode-region is TRT in this case, for several reasons: . recode-region is a command, so it wastes cycles checking the argument coding-system, which is entirely unnecessary in this case . it narrows the buffer, something that again is a waste of cycles for your case . it wastes even more cycles for "encoding" with 'binary', which in this case is a no-op, since the text was not decoded on reading . it doesn't use the following facilities for determining the right encoding, where you use buffer-file-coding-system: - auto-coding-function, which is where we detect the 'coding:' cookies in the first line and in the local vars, and use the data in auto-coding-alist and auto-coding-regexp-alist, and also call auto-coding-functions if needed - find-operation-coding-system by file name, which uses the data in file-coding-system-alist to determine the appropriate encoding given the file's name The hard problem here is to determine what coding-system to use for decoding a region that was inserted without any conversions; once the encoding is determined, the rest boils down to calling decode-coding-region with that encoding. The method used by archive-set-buffer-as-visiting-file solves that very problem, whereas recode-region does not, because it is a command that relies on the caller to specify the encoding, and is otherwise nothing more than a thin wrapper around decode-coding-region. If you need further help understanding what archive-set-buffer-as-visiting-file does, and which parts might not be relevant to the function you are writing, please ask specific questions and I will gladly help as much as I can. But recode-region is IMO not the right tool for this job. Thanks.