GNU bug report logs - #50489
vc-annotate doesn't keep the current line

Previous Next

To reply to this bug, email your comments to 50489 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: bug-gnu-emacs <at> gnu.org
Subject: vc-annotate doesn't keep the current line
Date: Thu, 09 Sep 2021 20:43:08 +0300

After 'C-x v g' (vc-annotate), typing 'a' (vc-annotate-revision-previous-to-line)
doesn't keep the current line.  For VC archaeology there is a need to traverse
the history of the current line by typing a sequence of 'a a a ...'
But 'a' doesn't keep the line current, so need to spend time
finding the same line in the buffer to be able to type 'a' on it again.

Message #8 received at 50489 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>, 50489 <at> debbugs.gnu.org
Subject: Re: bug#50489: vc-annotate doesn't keep the current line
Date: Fri, 10 Sep 2021 02:15:46 +0300

On 09.09.2021 20:43, Juri Linkov wrote:
> After 'C-x v g' (vc-annotate), typing 'a' (vc-annotate-revision-previous-to-line)
> doesn't keep the current line.  For VC archaeology there is a need to traverse
> the history of the current line by typing a sequence of 'a a a ...'
> But 'a' doesn't keep the line current, so need to spend time
> finding the same line in the buffer to be able to type 'a' on it again.

I think it does keep the current line (by number).

But the exact text can shift up or down between revisions, so we end up 
hunting for it.

It might be possible to keep up with the hunks by doing full diff before 
switching the revision, then count removals/additions in preceding hunks 
and go there. But it would not work when 'a' brings you to the version 
of the file before it was renamed, for example.

Message #11 received at 50489 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Juri Linkov <juri <at> linkov.net>
Cc: 50489 <at> debbugs.gnu.org
Subject: Re: bug#50489: vc-annotate doesn't keep the current line
Date: Mon, 13 Sep 2021 20:19:11 +0200

Juri Linkov <juri <at> linkov.net> writes:

> After 'C-x v g' (vc-annotate), typing 'a' (vc-annotate-revision-previous-to-line)
> doesn't keep the current line.  For VC archaeology there is a need to traverse
> the history of the current line by typing a sequence of 'a a a ...'
> But 'a' doesn't keep the line current, so need to spend time
> finding the same line in the buffer to be able to type 'a' on it again.

I think `git blame` provides a --porcelain option that helps track lines
accross revisions.  I expect that using that information would be an
improvement over the current behavior, but the solution won't be perfect
and in some situations it'll still go to a strange line.  Also, I don't
know if this feature is available in other non-git vc backends.

Message #14 received at 50489 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Daniel Martín <mardani29 <at> yahoo.es>,
 Juri Linkov <juri <at> linkov.net>
Cc: 50489 <at> debbugs.gnu.org
Subject: Re: bug#50489: vc-annotate doesn't keep the current line
Date: Tue, 14 Sep 2021 02:45:30 +0300

On 13.09.2021 21:19, Daniel Martín via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> Juri Linkov<juri <at> linkov.net>  writes:
> 
>> After 'C-x v g' (vc-annotate), typing 'a' (vc-annotate-revision-previous-to-line)
>> doesn't keep the current line.  For VC archaeology there is a need to traverse
>> the history of the current line by typing a sequence of 'a a a ...'
>> But 'a' doesn't keep the line current, so need to spend time
>> finding the same line in the buffer to be able to type 'a' on it again.
> I think `git blame` provides a --porcelain option that helps track lines
> accross revisions.  I expect that using that information would be an
> improvement over the current behavior, but the solution won't be perfect
> and in some situations it'll still go to a strange line.  Also, I don't
> know if this feature is available in other non-git vc backends.

Interesting suggestion. I think reliance on known line numbers can be 
made optional for backends that do not provide that info.

--porcelain (or --list-porcelain) output is peculiar and not 
customizable, so it would take some work to convert in to the same view 
we are currently enjoying. Hopefully without any loss in performance 
(I'm guessing the slowest part is still going to be the scanning of 
history).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.