From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) Newsgroups: gmane.emacs.bugs Subject: bug#20892: 25.0.50; Applying vc-diff hunks on CRLF tracked files Date: Fri, 01 Apr 2016 11:22:50 +0100 Message-ID: References: <83y4j9duh6.fsf@gnu.org> <83bng3etpy.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1459506262 5642 80.91.229.3 (1 Apr 2016 10:24:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 Apr 2016 10:24:22 +0000 (UTC) Cc: 20892@debbugs.gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Apr 01 12:24:11 2016 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 1alwFP-0003EF-FB for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 Apr 2016 12:24:11 +0200 Original-Received: from localhost ([::1]:43233 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alwFO-0005ps-Fa for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 Apr 2016 06:24:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alwFK-0005pi-6J for bug-gnu-emacs@gnu.org; Fri, 01 Apr 2016 06:24:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1alwFG-0006Nk-4e for bug-gnu-emacs@gnu.org; Fri, 01 Apr 2016 06:24:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49664) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alwFG-0006Ne-0T for bug-gnu-emacs@gnu.org; Fri, 01 Apr 2016 06:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1alwFF-0000l8-S9 for bug-gnu-emacs@gnu.org; Fri, 01 Apr 2016 06:24:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 Apr 2016 10:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20892 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20892-submit@debbugs.gnu.org id=B20892.14595061822841 (code B ref 20892); Fri, 01 Apr 2016 10:24:01 +0000 Original-Received: (at 20892) by debbugs.gnu.org; 1 Apr 2016 10:23:02 +0000 Original-Received: from localhost ([127.0.0.1]:46791 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1alwEH-0000jW-Nc for submit@debbugs.gnu.org; Fri, 01 Apr 2016 06:23:01 -0400 Original-Received: from mail-wm0-f51.google.com ([74.125.82.51]:34401) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1alwEF-0000jB-V0 for 20892@debbugs.gnu.org; Fri, 01 Apr 2016 06:23:00 -0400 Original-Received: by mail-wm0-f51.google.com with SMTP id p65so19741516wmp.1 for <20892@debbugs.gnu.org>; Fri, 01 Apr 2016 03:22:59 -0700 (PDT) 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-transfer-encoding; bh=ldzF4j8KVDJdc6K357rFAEGaJDm/qkANzGmmsl3lsoE=; b=pux/bhd8vnuhNtwuTXJ6WOc5a5VSu2iBJ5sbJV7Jx5ZnhbHB9qdtquQopAcvpkvki2 c7b57EpLf+9QCDhX2pmpm4r7+8kITMKpdQm1aMLRddC5q/+ioxR1+k3jk/zHFj0uoDKj lCC15dcAVS1b4NRyVO14nzSsVSO7hSzpKpApo9Rmc4A2h+qlGfGqT49l5MyrpNQIFg5J xGGYMTjIjw8Luceb5sBAB2a35qbSunjqcKbRc9+xhjKE/UtnPUga1oHu6uEBMZXrzQhD Xfjisq/RBCMiZbs2LLdClwxRF7xM7zw5XWl2wwGxOpT8X/2ALGYuRKXmQ+elmgFTSBcE VkdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=ldzF4j8KVDJdc6K357rFAEGaJDm/qkANzGmmsl3lsoE=; b=bS8zOpEAgPhabfB5FQmr/zpN+4RMchkrMQLFuiB2XlLzj0djvRWxiHWfYL5xKvPVJ4 va+VXVthUlEXOp7HofTr1YUlO8yHiAjkPR3MOazxNDnTgxx9cifSfiMzOyrZOjKsRLSP vel4opaW7X7bl7zdwp0g5mdTy0Mg7X++oNrnI4WoIJ58Ay/qSzOrRdpN78ZFmqoktohQ rey70J5Cjq2ijq00Ow6zfbn91EGjFsoelE0EelF5tvPCSUGldtk3veF0bjK4OBkHKWza NpePyOWeYcxq9hf6MFC5+9i+EMFU9HkeXBe/R9cfWTwEohdY7jQ2os1LF7EzgotEB4Dw v0PQ== X-Gm-Message-State: AD7BkJIfTiLFbk7QLiKpwKxe162biCud8f2UuYFzzcbnDLtA99WDJ5jmhyDuRFjqQwM0jg== X-Received: by 10.194.119.201 with SMTP id kw9mr22337448wjb.173.1459506174022; Fri, 01 Apr 2016 03:22:54 -0700 (PDT) Original-Received: from GONDOMAR.yourcompany.com (mail3.siscog.pt. [195.23.29.18]) by smtp.gmail.com with ESMTPSA id q62sm29233744wmg.12.2016.04.01.03.22.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Apr 2016 03:22:52 -0700 (PDT) In-Reply-To: <83bng3etpy.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 25 Jun 2015 17:41:13 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.91 (windows-nt) 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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:115835 Archived-At: Hi, So I'm reviving this ancient thread, since I've possibly come up with a more interesting patch. In lisp/vc/vc.el, in vc-diff-internal, dynamically binding `coding-system-for-read' seems to be defeated by a call to `vc-setup-buffer', which in turn kills all local variables.=20 I don't fully understand the interaction between buffer-local and lexically/dinamically bound variables but this seems wrong, right? Anyway, I believe the `vc-setup-buffer' can be pulled up to outside the let. diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el index 25b41e3..c245c3f 100644 --- a/lisp/vc/vc.el +++ b/lisp/vc/vc.el @@ -1678,6 +1678,7 @@ BUFFER, if non-nil, should be a buffer or a buffe= r name. Return t if the buffer had changes, nil otherwise." (unless buffer (setq buffer "*vc-diff*")) + (vc-setup-buffer buffer) (let* ((files (cadr vc-fileset)) (messages (cons (format "Finding changes in %s..." (vc-delistify files)) @@ -1696,7 +1697,6 @@ Return t if the buffer had changes, nil otherwise= ." (setq coding-system-for-read (coding-system-change-eol-conversion coding-system-for-re= ad 'dos))) - (vc-setup-buffer buffer) (message "%s" (car messages)) ;; Many backends don't handle well the case of a file that has been ;; added but not yet committed to the repo (notably CVS and Subver= sion). If, to this, we add a fix in lisp/vc/vc-git.el and don't let it override an existing `coding-system-for-read'... diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el index 8498cc8..c60125c 100644 --- a/lisp/vc/vc-git.el +++ b/lisp/vc/vc-git.el @@ -1387,8 +1387,10 @@ This command shares argument histories with \\[r= grep] and \\[grep]." "A wrapper around `vc-do-command' for use in vc-git.el. The difference to vc-do-command is that this function always invokes `vc-git-program'." - (let ((coding-system-for-read vc-git-commits-coding-system) - (coding-system-for-write vc-git-commits-coding-system)) + (let ((coding-system-for-read (or coding-system-for-read + vc-git-commits-coding-system)) + (coding-system-for-write (or coding-system-for-write + vc-git-commits-coding-system))) (apply 'vc-do-command (or buffer "*vc*") okstatus vc-git-program ;; http://debbugs.gnu.org/16897 (unless (and (not (cdr-safe file-or-list)) the system seems to do the right thing and honour the intention of commit 0e2c793ffefa72c40c7731847d8210c2d7d0e515 Author: Eli Zaretskii Date: Tue Nov 26 21:17:55 2013 +0200 =20=20=20=20 Fix ugly ^M characters in Diff output shown by "C-x v u". What do you think?=20 Jo=E3o Eli Zaretskii writes: >> From: Jo=E3o T=E1vora >> Date: Thu, 25 Jun 2015 14:54:26 +0100 >> Cc: 20892@debbugs.gnu.org >>=20 >> I don't think simply removing the CR characters is the right thing, we >> should interpret them according to coding-system-eol-type, right? > > You should remove them if coding-system-eol-type for > buffer-file-coding-system of the buffer which the hunk comes from > returns 1. > >> So, say a diff hunk contains just a couple of lines with CRLF and a >> couple of lines just LF. If applied to a buffer that is all CRLF, I >> would say that applying this hunk should eventually provoke the normal >> Emacs behaviour of highlighting all CR's except for the two lines with >> LF. Is it worth it? What do you both think? > > It depends on what the user wants/needs. The Patch utility has > options which will cause it to strip the CR characters when applying > the diffs; I guess we should have a similar flexibility here.