[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [PATCH] Showing the relevant part of a diff
From: |
Herring, Davis |
Subject: |
RE: [PATCH] Showing the relevant part of a diff |
Date: |
Sat, 20 Feb 2016 22:49:01 +0000 |
>> 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