On Tue, Sep 14, 2010 at 16:17, Philip Jackson <[email protected]> wrote:
> At Tue, 14 Sep 2010 05:51:00 -0700 (PDT),
> Andrew W. Nosenko wrote:
>>
>> On 12 сен, 20:54, Samuel Wales <[email protected]> wrote:
>> > In the status buffer, s on a hunk moves point to a random location.
>> > Is this behavior the same for everybody?
>> >
>> > I have not been able to determine a pattern to it yet.
>> >
>>
>> Looks like it just stay on the same buffer line. E.g. if at the time
>> of pressing 's' your point was on the line #39, then it will either at
>> the line #39 after "stage" at at the last buffer line if there not
>> enough lines. Because content of the buffer itself changing, it looks
>> like "random" jumps. And yes, I also think that such behavior counter-
>> convinient.
>
> What should it do instead?
Move to next "stageable" item (diff-hunk if visible, or file). If
staged item was the latest one, then to previous "stageable" item. If
there no unstaged items left (all items are staged), then to the 1st
item in the "Staged" area (i.e. on the 1st "unstageable" item).
Similar for "unstage" operation.
Just as example: assume we have
File-A [buffer lines 53-123]
hunk-A-1 [lines 58-80]
hunk-A-2 [lines 81-106]
hunk-A-3 [lines 107-123]
File-B [line 124] (one line because hunks are collapsed)
After staging hunk-A-2 the point should be moved to the 1st line of
hunk-A-3 (that was the line #107 and now become line #81, because
hunk-A-2 removed from the "Unstaged changes" list). After staging the
hunk-A-3 the point should be moved to "File-B" line (that become the
line 81 after staging hunk-A-3). And so on...
Please pay attention that it is different from the current "stay on
current line" behavior. In my example sequence "move point to line
#104 and stage hunk-A-2" results in movement to line #81 (that
contains now the beginning of the hunk-A-3), while the current
behavior ("stay on current line") tries to keep the point on the line
#104, which after staging of hunk-A-2 becomes past the buffer end at
all (for this concrete example).
--
Andrew W. Nosenko <[email protected]>
