GNU bug report logs - #6745
24.0.50; vc-annotate should allow to configure the width of blame info

Previous Next

To reply to this bug, email your comments to 6745 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: aneesh.kumar <at> linux.vnet.ibm.com (Aneesh Kumar K.V)
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50; vc-annotate should allow to configure the width of blame info
Date: Wed, 28 Jul 2010 20:25:11 +0530

This is with vc-git.el. With C-x v g it would be nice to be able to
customize the width of blame info. That allows to see both the code
and associate sha1 on the same window. Another option is to display the
source and commit in separate window thereby being able to scroll
them. But this have the issue that we will not be able to search both
the blame information and source at the same time. Limiting blame info
to a configuration 'x' character seems to be a nice trade off.

-aneesh

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: aneesh.kumar <at> linux.vnet.ibm.com (Aneesh Kumar K.V)
Cc: 6745 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#6745: 24.0.50; vc-annotate should allow to configure the
 width of blame info
Date: Mon, 09 May 2022 18:16:35 +0200

aneesh.kumar <at> linux.vnet.ibm.com (Aneesh Kumar K.V) writes:

> This is with vc-git.el. With C-x v g it would be nice to be able to
> customize the width of blame info. That allows to see both the code
> and associate sha1 on the same window.

Yes, that would be great.  It has also been suggested that all the VC
backends should use the same format, and I think that could be done at
the same time.  (Even if they don't all have the same data available,
they generally have much in common.)

But to do that, I think we'd have to rework how vc-*-annotate-command
works.  I think they basically work by running the "blame" command for
the VC in a buffer, and then parsing/fontifying the output a bit?

To allow regularisation (and user customisation) of the output, I think
we'd have to redo that completely.  Instead the backends would dump the
output to a temp dir, we'd parse it completely, add it to some
structure, and then output the data into a buffer in the format we want.
(Something that looks a bit like tabulated-list-mode, but where the user
can, for instance, use commands to make columns disappear and appear as
they wish.)

I think that's more than doable, and worth doing.

I wonder whether anybody's had any concrete ideas in this direction
before (so I've added Dmitry to the CCs).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: aneesh.kumar <at> linux.vnet.ibm.com (Aneesh Kumar K.V)
Cc: 6745 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#6745: 24.0.50; vc-annotate should allow to configure the
 width of blame info
Date: Mon, 09 May 2022 20:35:45 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> To allow regularisation (and user customisation) of the output, I think
> we'd have to redo that completely.  Instead the backends would dump the
> output to a temp dir, we'd parse it completely, add it to some
> structure, and then output the data into a buffer in the format we want.

We wouldn't have to implement this for all the backends -- we could bind
`C-x v g' to a command that does new-style annotations if the backend
supports it, and fall back to the current functions if they don't.

Oh, and we could also implement annotations for just a narrowed-to
region while we're at it.  (This has also been requested a few times.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 6745 <at> debbugs.gnu.org, "Aneesh Kumar K.V" <aneesh.kumar <at> linux.vnet.ibm.com>,
 Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#6745: 24.0.50; vc-annotate should allow to configure the
 width of blame info
Date: Wed, 11 May 2022 19:53:54 +0300

> But to do that, I think we'd have to rework how vc-*-annotate-command
> works.  I think they basically work by running the "blame" command for
> the VC in a buffer, and then parsing/fontifying the output a bit?

There is no such problem in the vc-git backend because it shows
short hashes, and also it's possible to make other parts shorter
by customizing vc-git-annotate-switches.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 6745 <at> debbugs.gnu.org, "Aneesh Kumar K.V" <aneesh.kumar <at> linux.vnet.ibm.com>,
 Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#6745: 24.0.50; vc-annotate should allow to configure the
 width of blame info
Date: Wed, 11 May 2022 20:40:47 +0200

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

> There is no such problem in the vc-git backend because it shows
> short hashes, and also it's possible to make other parts shorter
> by customizing vc-git-annotate-switches.

If you want to make the "name" part 10 characters long (for instance), I
don't think there's any way to do that?  (At least I can't find the
relevant switch after skimming the manual.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>,
 "Aneesh Kumar K.V" <aneesh.kumar <at> linux.vnet.ibm.com>
Cc: 6745 <at> debbugs.gnu.org
Subject: Re: bug#6745: 24.0.50; vc-annotate should allow to configure the
 width of blame info
Date: Sat, 4 Jun 2022 21:46:51 +0300

On 09.05.2022 19:16, Lars Ingebrigtsen wrote:
> To allow regularisation (and user customisation) of the output, I think
> we'd have to redo that completely.  Instead the backends would dump the
> output to a temp dir,

              ^ temp buffer, probably

> we'd parse it completely, add it to some
> structure, and then output the data into a buffer in the format we want.
> (Something that looks a bit like tabulated-list-mode, but where the user
> can, for instance, use commands to make columns disappear and appear as
> they wish.)
> 
> I think that's more than doable, and worth doing.
> 
> I wonder whether anybody's had any concrete ideas in this direction
> before (so I've added Dmitry to the CCs).

IIRC there was a similar or related issue where Stefan M. suggested a 
similar course of action.

Nobody has taken up the work yet, though.

Previous Next

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