RE: [PATCH] Showing the relevant part of a diff

[Herring, Davis]

> > +(defun diff-goto-line (file line column)
> > +  "Go to the place in this diff producing LINE in FILE.
> 
> This first line should mention COLUMN as well.

So, to keep to the length limit, I guess we want

  Go to the place in this diff producing LINE:COLUMN in FILE.

even though that (still) doesn't name the arguments in order.

> > +If LINE (in the new version of FILE) is included, move to it and then
>                                         ^^^^^^^^^^^
> Included where?

In the diff, as a +/! line or a context line.

> > +COLUMN characters forward.  If it is absent, go to the first hunk
> > +starting after LINE, or to the end if none does.
> 
> Why this fallback?  Would it make sense to just stay at the beginning?

First, it handles the case where point is just outside a hunk's context, by 
putting it "just off the edge" of the context.  It can also be useful to see 
the nearest changes before and after point even if they are far away: they 
might be additions/removals of "#ifdef...#endif", for example.

> > +    (unless rev2    ; remember the position in the or a current buffer
> 
> Typo in the comment.

Not a typo -- I meant "in the [current buffer] or a current buffer".  I could 
write "in the, or a, current buffer", but now that I think of it we shouldn't 
call another existing buffer "a current buffer".  Maybe

  ; remember position in some buffer

and then

  ;; Prefer current buffer:

above the "(setq f ...)"?

There's actually a more general issue there: some members of `files' may be 
directories (for C-x v D, for instance), and the buffer chosen (current or no) 
might be visiting a file that has no changes.  These points don't matter for 
plain `vc-diff', which was my first use case.  I'll change it to record 
positions for all possibly-relevant buffers, and try each (current first) until 
it finds one relevant to the resulting diff.

> Thanks.

Thanks for looking at it,
Davis