[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20892: 25.0.50; Applying vc-diff hunks on CRLF tracked files

From: João Távora
Subject: bug#20892: 25.0.50; Applying vc-diff hunks on CRLF tracked files
Date: Fri, 01 Apr 2016 11:22:50 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.91 (windows-nt)


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. 

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

    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 buffer 
     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-read
    -    (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 

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 
\\[rgrep] 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
    -  (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 <address@hidden>
   Date:   Tue Nov 26 21:17:55 2013 +0200
       Fix ugly ^M characters in Diff output shown by "C-x v u".

What do you think? 


Eli Zaretskii <address@hidden> writes:

>> From: João Távora <address@hidden>
>> Date: Thu, 25 Jun 2015 14:54:26 +0100
>> Cc: address@hidden
>> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]