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

[Herring, Davis]

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