[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: diff-find-file-name and /dev/null
From: |
Glenn Morris |
Subject: |
Re: diff-find-file-name and /dev/null |
Date: |
Fri, 24 Aug 2007 21:54:35 -0400 |
User-agent: |
Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) |
Nikolaj Schumacher wrote:
> Since there's nothing to view or edit in /dev/null.
How about this patch then:
diff -c -c -w -r1.99.2.3 diff-mode.el
*** diff-mode.el 6 Aug 2007 20:08:07 -0000 1.99.2.3
--- diff-mode.el 25 Aug 2007 01:41:53 -0000
***************
*** 646,652 ****
((or (null files)
(setq file (do* ((files files (cdr files))
(file (car files) (car files)))
! ((or (null file) (file-exists-p file))
file))))
file))
;; <foo>.rej patches implicitly apply to <foo>
--- 646,652 ----
((or (null files)
(setq file (do* ((files files (cdr files))
(file (car files) (car files)))
! ((or (null file) (file-regular-p file))
file))))
file))
;; <foo>.rej patches implicitly apply to <foo>
> Also in a usual diff file
>
> --- /dev/null 2007-08-17 06:03:27.000000000 +0200
> +++ /foo/bar.c 2007-08-18 00:48:25.000000000 +0200
>
> `diff-goto-source' would visit /foo/bar.c
It's easy to produce a non-git diff that has the same behaviour. Just
do a diff between /dev/null and a relative filename:
diff -u /dev/null foo/somefile > foo/some.diff
Then open foo/some.diff in Emacs and try to jump to source. I'd never
make a hideous diff like that though...
> I admit the actual fault could be the fact that it looks for first
> one at all (or at least _before_ chopping off prefixes of the second
> one), even when diff-jump-to-old-file is nil. /dev/null is just the
> only cause of such behavior.
Yes, I don't see why diff-find-file-name does that, and I don't think
/dev/null is the only cause. Eg repeating the above example, but with
regular files:
diff -u /tmp/file1 foo/file2 > foo/file.diff
diff-goto-source will open file1 rather than file2.
Stefan, is there a reason why diff-find-file-name can return the old
file, even when OLD is nil? Why doesn't it just consider
(car (diff-hunk-file-names old))?
If it should consider both old and new in each case, should it not try
dropping the directory entries from the new/old file first, before
going on to check the old/new one in the same way only it it does not
find a match?