Re: diff-find-file-name and /dev/null

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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>

Looks very good.  This will also rule out directories.  Please install.

>> 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))?

diff-find-file-name tries pretty hard to find *A* file, so I think it's
OK for it to sometimes return an old file even when OLD is nil.
But maybe the order in which file names are tried could be improved.

> 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?

Sounds right.  The current ordering is somewhat arbitrary.  Fell free to
change it as you suggest, but for any such change, please add a comment
explaining the situation for which the change makes sense.


        Stefan