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

["Herring, Davis" <herring@lanl.gov>]

>> 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.
> 
> I think it's confusingly different from what you do when FILE is not
> give.  IMO the beginning is better.

I find the "where LINE would go" behavior natural and useful.  Files are different in that they have no natural sequencing: no place where any particular FILE "would go".

The "no FILE" case doesn't arise for single files, of course, unless there are no changes and the whole question is moot.  For changeset diffs, I (soon will) handle an absent FILE by trying another buffer's file.  It is already the case that the FILE-not-found case is a no-op in that point _remains_ at the beginning; this will make it truly ignorable, so there shouldn't be any confusion.

>> 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".
> 
> Sorry, I don't understand: "_a_ current buffer"? why?

Do you mean "Why record the location in a non-current buffer?"?  If so, the answer is that the diff might be run from Dired or via C-x v D, and so the buffer whose point indicates what is interesting need not be current.

That feature strikes me as less important than the between-hunks feature, because the user might be more confused about and less interested in point's value in a non-current buffer.  Still, it probably finds "your most recent changes", which could be useful.

If you meant "Why call a buffer 'a current buffer'?", then I can only agree with you, since "current buffer" is a uniquely defined concept -- that's why I was talking about rephrasing it (before talking about changing it to try positions in several buffers).

Davis