Jonathan Nieder <jrnieder@xxxxxxxxx> writes:
> Hi David et al,
>
> David KÃgedal wrote:
>> Sergei Organov <osv@xxxxxxxxx> writes:
>
>>> Now, I've evaluated (require 'format-spec) in my Emacs 22 (yes, 22, not
>>> 23), and now git-blame almost works there. The problem I see is that it
>>> doesn't output anything in the echo area. It color-codes the buffer, it
>>> does show correct pop-up when mouse is over a region, but it doesn't
>>> print anything in the echo area when I move cursor through the regions.
>>> Any idea how to debug/fix this?
>>
>> Well, it appears I removed the output to the echo area. I didn't think
>> it worked very well, and the new output format mostly replaces it by
>> showing the hash.
>>
>> There are also technical reasons for removing it (it couldn't be
>> implemented very cleanly).
>
> I don't use git-blame.el ("git blame", "git gui blame", and "git log
> -S/-G" take care of my needs already) but it seems to me that this
> change was a regression. The emacs support before v1.6.6-rc0~120^2
> had a simple way to find out the purpose of each line of code, while
> after that there is no simple way. And it is what the README
> promises:
>
> * git-blame.el:
>
> Emacs implementation of incremental git-blame. When you turn it on
> while viewing a file, the editor buffer will be updated by setting
> the background of individual lines to a color that reflects which
> commit it comes from. And when you move around the buffer, a
> one-line summary will be shown in the echo area.
>
> Any advice for people who want to fix that? Is anyone interested in
> doing so? (It is quite likely I am guessing incorrectly about what is
> useful, but I would imagine that at least the documentation could use
> updating.)
Let's try to figure out how we would like it to work. I agree that the
mouseover information is not good enough. There are several things we
can do:
1) Use some command to request information about the current line.
When the command is invoked (bound to some convenient key?), it pops
up a buffer with the result of "git show <commit>" or similar.
2) Have a separate buffer always showing information about the line
under the cursor. This should at least be the info in the commit
object, but going to the diff should be accessible.
3) Showing when you move to a different blame chunk, by showing a
one-line summary in the echo area.
There are variations and combinations. I think that 1+3 or 2 are the
best options.
--
David KÃgedal
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html