threads / discuss / 21860

git-blame.el: what is format-spec?

Subject: git-blame.el: what is format-spec?

## tl;dr

24 messages between Dec 4, 2009 and Jan 29, 2013.

replies: 23people: 9as markdown or json

Andreas Schwab· Dec 4, 2009, 16:38 UTC · re: Sergei Organov · lore

Re: git-blame.el: what is format-spec?

Sergei Organov <osv@javad.com> writes:
> What is format-spec function in current git-blame.el? Neither my GNU
> Emacs 22.2.1 nor Google knows anything about it.
It's part of Emacs since more than 9 years, imported from Gnus.
Andreas.
-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Sergei Organov· Dec 4, 2009, 16:59 UTC · re: Andreas Schwab · lore

Re: git-blame.el: what is format-spec?

Andreas Schwab <schwab@linux-m68k.org> writes:
Show 7 quoted lines
> Sergei Organov <osv@javad.com> writes:
>
>> What is format-spec function in current git-blame.el? Neither my GNU
>> Emacs 22.2.1 nor Google knows anything about it.
>
> It's part of Emacs since more than 9 years, imported from Gnus.
>

Thanks, I now see it in Gnus on my own computer, in lisp/gnus/format-spec.el.gz.

GNU Emacs 22.2.1 (i486-pc-linux-gnu, GTK+ Version 2.12.11) of 2008-11-10 on raven, modified by Debian

However, isn't it a bad idea to require Gnus(!) for git-blame to run? Gnus is not installed on our server where I've encountered the problem. Was format-spec actually moved to core emacs recently?

-- Sergei.
David Kågedal· Dec 4, 2009, 17:36 UTC · re: Sergei Organov · lore

Re: git-blame.el: what is format-spec?

Sergei Organov <osv@javad.com> writes:
Show 18 quoted lines
> Andreas Schwab <schwab@linux-m68k.org> writes:
>> Sergei Organov <osv@javad.com> writes:
>>
>>> What is format-spec function in current git-blame.el? Neither my GNU
>>> Emacs 22.2.1 nor Google knows anything about it.
>>
>> It's part of Emacs since more than 9 years, imported from Gnus.
>>
>
> Thanks, I now see it in Gnus on my own computer, in
> lisp/gnus/format-spec.el.gz.
>
> GNU Emacs 22.2.1 (i486-pc-linux-gnu, GTK+ Version 2.12.11) of 2008-11-10
> on raven, modified by Debian 
>
> However, isn't it a bad idea to require Gnus(!) for git-blame to run? Gnus
> is not installed on our server where I've encountered the problem. Was
> format-spec actually moved to core emacs recently?
That was not my intention when I posted the patch. I seem to recall that
I asked for testing, in particular from users with older Emacsen than
23. But I got no response, and only recently discovered that the patch
hade been accepted.

format-spec is included in Emacs 23, and is a useful function. But we can rewrite git-blame.el to do the formatting manuall instead.

-- 
David Kågedal
Sergei Organov· Dec 4, 2009, 20:54 UTC · re: David Kågedal · lore

Re: git-blame.el: what is format-spec?

David Kågedal <davidk@lysator.liu.se> writes:
Show 27 quoted lines
> Sergei Organov <osv@javad.com> writes:
>
>> Andreas Schwab <schwab@linux-m68k.org> writes:
>>> Sergei Organov <osv@javad.com> writes:
>>>
>>>> What is format-spec function in current git-blame.el? Neither my GNU
>>>> Emacs 22.2.1 nor Google knows anything about it.
>>>
>>> It's part of Emacs since more than 9 years, imported from Gnus.
>>>
>>
>> Thanks, I now see it in Gnus on my own computer, in
>> lisp/gnus/format-spec.el.gz.
>>
>> GNU Emacs 22.2.1 (i486-pc-linux-gnu, GTK+ Version 2.12.11) of 2008-11-10
>> on raven, modified by Debian 
>>
>> However, isn't it a bad idea to require Gnus(!) for git-blame to run? Gnus
>> is not installed on our server where I've encountered the problem. Was
>> format-spec actually moved to core emacs recently?
>
> That was not my intention when I posted the patch. I seem to recall that
> I asked for testing, in particular from users with older Emacsen than
> 23. But I got no response, and only recently discovered that the patch
> hade been accepted.
>
> format-spec is included in Emacs 23, and is a useful function.

Then there should be (require 'format-spec) in git-blame.el, right? Due to:

$ emacs --version GNU Emacs 23.1.1 [...] $ emacs --batch -Q -f format-spec Symbol's function definition is void: format-spec $

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?

-- Sergei.
David Kågedal· Dec 6, 2009, 18:43 UTC · re: Sergei Organov · lore

Re: git-blame.el: what is format-spec?

Sergei Organov <osv@javad.com> writes:
> Then there should be (require 'format-spec) in git-blame.el, right? Due
> to:
Of course. I must have missed that since I already had it loaded.
Show 6 quoted lines
> 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).

It would of course be possible to restore the old way, but I think it would be good to ask ourselves what we really would like to see? Some ideas:

* A keybinding to show the commit introducing the current line,
  including diff and all.
* A keybinding to show the commit message in the echo areia.
* The old "log --oneline in echo area when point moves in to a new
  region" behavior.
* The old behvaior with a delay.
* Inline display of even more information. For just the current region?
* A constantly updating separate window
-- 
David Kågedal
Sergei Organov· Dec 7, 2009, 08:36 UTC · re: David Kågedal · lore

Re: git-blame.el: what is format-spec?

David Kågedal <davidk@lysator.liu.se> writes:
Show 20 quoted lines
> Sergei Organov <osv@javad.com> writes:
>
>> Then there should be (require 'format-spec) in git-blame.el, right? Due
>> to:
>
> Of course. I must have missed that since I already had it loaded.
>
>> 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 didn't know you deliberately removed it, -- I thought it's some Emacs22 - related problem. I have no problem then, except that I don't know how to get the hash into my kill-ring or X selection.

While we are at it, why is git-blame-identify interactive and how is it useful?

Show 9 quoted lines
>
> It would of course be possible to restore the old way, but I think it
> would be good to ask ourselves what we really would like to see? Some
> ideas:
>
> * A keybinding to show the commit introducing the current line,
>   including diff and all.
>
> * A keybinding to show the commit message in the echo areia.
For me, these 2 would be more than enough, I think.
-- Sergei.
David Kågedal· Dec 7, 2009, 09:05 UTC · re: Sergei Organov · lore

Re: git-blame.el: what is format-spec?

Sergei Organov <osv@javad.com> writes:
Show 29 quoted lines
> David Kågedal <davidk@lysator.liu.se> writes:
>
>> Sergei Organov <osv@javad.com> writes:
>>
>>> Then there should be (require 'format-spec) in git-blame.el, right? Due
>>> to:
>>
>> Of course. I must have missed that since I already had it loaded.
>>
>>> 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 didn't know you deliberately removed it, -- I thought it's some
> Emacs22 - related problem. I have no problem then, except that I don't
> know how to get the hash into my kill-ring or X selection.
>
> While we are at it, why is git-blame-identify interactive and how is it
> useful?

I think I need to go over this file with a fine-tooth coam to remove or fix bitrot. This command seems to try to show the hash in the echo area, but probably doesn't work. New and better commands should be deviced.

I'll try to find some time to work on this soon.
Thanks a lot for the feedback.
-- 
David Kågedal
Alex Unleashed· May 14, 2010, 13:13 UTC · re: David Kågedal · lore

Re: git-blame.el: what is format-spec?

On Sun, Dec 6, 2009 at 8:43 PM, David Kågedal <davidk@lysator.liu.se> wrote:
Show 6 quoted lines
> Sergei Organov <osv@javad.com> writes:
>
>> Then there should be (require 'format-spec) in git-blame.el, right? Due
>> to:
>
> Of course. I must have missed that since I already had it loaded.

Has this oneliner been submitted for inclusion in git.git yet? Yesterday I stumbled upon format-spec missing on a fresh install of Ubuntu 10.04's emacs package.. Just require'ing it fixes the problem.

  Alex
David Kågedal· May 25, 2010, 13:44 UTC · re: Alex Unleashed · lore

[PATCH] git-blame.el: Add (require 'format-spec)

---
Show 11 quoted lines
> On Sun, Dec 6, 2009 at 8:43 PM, David Kågedal <davidk@lysator.liu.se> wrote:
> > Sergei Organov <osv@javad.com> writes:
> >
> >> Then there should be (require 'format-spec) in git-blame.el, right? Due
> >> to:
> >
> > Of course. I must have missed that since I already had it loaded.
> 
> Has this oneliner been submitted for inclusion in git.git yet?
> Yesterday I stumbled upon format-spec missing on a fresh install of
> Ubuntu 10.04's emacs package.. Just require'ing it fixes the problem.
Apparently not, but here is the patch.
 contrib/emacs/git-blame.el |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/contrib/emacs/git-blame.el b/contrib/emacs/git-blame.el
index 7f4c792..d351cfb 100644
--- a/contrib/emacs/git-blame.el
+++ b/contrib/emacs/git-blame.el
@@ -79,6 +79,7 @@
 ;;; Code:
 
 (eval-when-compile (require 'cl))			      ; to use `push', `pop'
+(require 'format-spec)
 
 (defface git-blame-prefix-face
   '((((background dark)) (:foreground "gray"
-- 
1.7.0.4


-- 
David Kågedal
Jonathan Nieder· Oct 29, 2010, 03:38 UTC · re: David Kågedal · lore

[PATCH resend] git-blame.el: Add (require 'format-spec)

Date: Tue, 25 May 2010 15:44:15 +0200
From: David Kågedal <davidk@lysator.liu.se>

c5022f57 (git-blame.el: Change how blame information is shown, 2009-09-29) taught the "M-x git-blame" mode to format its output in a more interesting way, making use of the format-spec function.

format-spec is included in Emacs 23 and is a useful function. Older emacsen can get it from Gnus. In all emacsen, we need to 'require it before use to avoid warnings:

 git-blame.el:483:1:Warning: the function `format-spec' is not known to be
     defined.
Reported-by: Sergei Organov <osv@javad.com>
Reported-by: Kevin Ryde <user42@zip.com.au>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
David Kågedal wrote:
Show 6 quoted lines
>> On Sun, Dec 6, 2009 at 8:43 PM, David Kågedal <davidk@lysator.liu.se> wrote:
>>> Sergei Organov <osv@javad.com> writes:
>>>> Then there should be (require 'format-spec) in git-blame.el, right? Due
>>>> to:
>>>
>>> Of course. I must have missed that since I already had it loaded.
[...]
>                     here is the patch.

Junio, I think something like this patch is needed for git-blame.el to work correctly. I am no emacs lisp expert, though...

Other observations from that thread are a bit more worrying --- it seems that c5022f57 dropped support for information about the selected commit in the editor buffer, without updating the documentation in contrib/emacs/README to match.

 contrib/emacs/git-blame.el |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/contrib/emacs/git-blame.el b/contrib/emacs/git-blame.el
index 7f4c792..d351cfb 100644
--- a/contrib/emacs/git-blame.el
+++ b/contrib/emacs/git-blame.el
@@ -79,6 +79,7 @@
 ;;; Code:
 
 (eval-when-compile (require 'cl))			      ; to use `push', `pop'
+(require 'format-spec)
 
 (defface git-blame-prefix-face
   '((((background dark)) (:foreground "gray"
-- 
1.7.0.4
Jonathan Nieder· Feb 4, 2011, 01:43 UTC · re: David Kågedal · lore

git-blame.el: does not show one-line summary in echo area

Hi David et al,
David Kågedal wrote:
> Sergei Organov <osv@javad.com> writes:
Show 13 quoted lines
>> 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.)

Jonathan
David Kågedal· Feb 4, 2011, 09:53 UTC · re: Jonathan Nieder · lore

Re: git-blame.el: does not show one-line summary in echo area

Jonathan Nieder <jrnieder@gmail.com> writes:
Show 38 quoted lines
> Hi David et al,
>
> David Kågedal wrote:
>> Sergei Organov <osv@javad.com> 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
Jakub Narebski· Feb 4, 2011, 10:03 UTC · re: David Kågedal · lore

Re: git-blame.el: does not show one-line summary in echo area

Dnia piątek 4. lutego 2011 10:53, David Kågedal napisał:
> 3) Showing when you move to a different blame chunk, by showing a
>    one-line summary in the echo area.

There is even some prior art for this to borrow from, namely cperl-mode shows information about syntax at given point in echo area (minibuffer area) after some delay. Just FYI.

-- 
Jakub Narebski
Poland
David Kågedal· Feb 4, 2011, 10:15 UTC · re: Jakub Narebski · lore

Re: git-blame.el: does not show one-line summary in echo area

Jakub Narebski <jnareb@gmail.com> writes:
Show 8 quoted lines
> Dnia piątek 4. lutego 2011 10:53, David Kågedal napisał:
>
>> 3) Showing when you move to a different blame chunk, by showing a
>>    one-line summary in the echo area.
>
> There is even some prior art for this to borrow from, namely cperl-mode
> shows information about syntax at given point in echo area (minibuffer
> area) after some delay.  Just FYI.

Sure, there are a number of those (eldoc comes to mind). I think the hardest part is figuring out what to show. A 40-charater hash is probably not very useful. The problem is that the committer information, date, and commit message first line takes up a lot of space. But we can of course let the echo area grow to two lines, or even three.

I don't think I'll have time to cook something up right now, though.
-- 
David Kågedal
David Kågedal· Feb 4, 2011, 12:26 UTC · re: David Kågedal · lore

Re: git-blame.el: does not show one-line summary in echo area

David Kågedal <davidk@lysator.liu.se> writes:
Show 18 quoted lines
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Dnia piątek 4. lutego 2011 10:53, David Kågedal napisał:
>>
>>> 3) Showing when you move to a different blame chunk, by showing a
>>>    one-line summary in the echo area.
>>
>> There is even some prior art for this to borrow from, namely cperl-mode
>> shows information about syntax at given point in echo area (minibuffer
>> area) after some delay.  Just FYI.
>
> Sure, there are a number of those (eldoc comes to mind). I think the
> hardest part is figuring out what to show. A 40-charater hash is
> probably not very useful. The problem is that the committer information,
> date, and commit message first line takes up a lot of space. But we can
> of course let the echo area grow to two lines, or even three.
>
> I don't think I'll have time to cook something up right now, though.

I whipped up a patch anyway. This adds an echo area message shown after 0.5 seconds of idleness, using the git-blame-echo-format format string. Try it and see if makes sense. I can clean it up (and split it up) later.

diff --git a/contrib/emacs/git-blame.el b/contrib/emacs/git-blame.el
index d351cfb..9f60a6f 100644
--- a/contrib/emacs/git-blame.el
+++ b/contrib/emacs/git-blame.el
@@ -104,34 +104,53 @@
 (defcustom git-blame-prefix-format
   "%h %20A:"
   "The format of the prefix added to each line in `git-blame'
-mode. The format is passed to `format-spec' with the following format keys:
-
-  %h - the abbreviated hash
-  %H - the full hash
-  %a - the author name
-  %A - the author email
-  %c - the committer name
-  %C - the committer email
-  %s - the commit summary
+mode. See `git-blame-format' for more information.
 "
   :group 'git-blame)
 
 (defcustom git-blame-mouseover-format
   "%h %a %A: %s"
   "The format of the description shown when pointing at a line in
-`git-blame' mode. The format string is passed to `format-spec'
-with the following format keys:
+`git-blame' mode. See `git-blame-format' for more information
+"
+  :group 'git-blame)
+
+(defcustom git-blame-echo-format
+  "%H\n%a %A %t\n%s"
+  "The format of the description shown in the echo area when moving around in
+`git-blame' mode. See `git-blame-format' for more information."
+  :group 'git-blame)
+
+(defun git-blame-format (info format)
+  "Use format-spec to format the blame info in INFO with the following keys:
 
   %h - the abbreviated hash
   %H - the full hash
   %a - the author name
   %A - the author email
+  %t - the author time
   %c - the committer name
   %C - the committer email
+  %T - the commtter time
   %s - the commit summary
 "
-  :group 'git-blame)
-
+  (let ((hash (car info))
+        (author-time (let ((time (string-to-number
+                                  (git-blame-get-info info 'author-time))))
+                       (list (/ time 65536) (% time 65536) 0)))
+        (committer-time (let ((time (string-to-number
+                                  (git-blame-get-info info 'committer-time))))
+                          (list (/ time 65536) (% time 65536) 0))))
+    (format-spec format
+                 `((?h . ,(substring (car info) 0 6))
+                   (?H . ,(car info))
+                   (?a . ,(git-blame-get-info info 'author))
+                   (?A . ,(git-blame-get-info info 'author-mail))
+                   (?t . ,(format-time-string "%c" author-time))
+                   (?c . ,(git-blame-get-info info 'committer))
+                   (?C . ,(git-blame-get-info info 'committer-mail))
+                   (?T . ,(format-time-string "%c" committer-time))
+                   (?s . ,(git-blame-get-info info 'summary))))))
 
 (defun git-blame-color-scale (&rest elements)
   "Given a list, returns a list of triples formed with each
@@ -198,10 +217,13 @@ minor mode.")
   "A cache of git-blame information for the current buffer")
 (make-variable-buffer-local 'git-blame-cache)
 
-(defvar git-blame-idle-timer nil
+(defvar git-blame-update-timer nil
   "An idle timer that updates the blame")
 (make-variable-buffer-local 'git-blame-cache)
 
+(defvar git-blame-show-timer nil
+  "An idle timer that show the current blame info.")
+
 (defvar git-blame-update-queue nil
   "A queue of update requests")
 (make-variable-buffer-local 'git-blame-update-queue)
@@ -246,6 +268,10 @@ See also function `git-blame-mode'."
 	(setq git-blame-colors git-blame-dark-colors)
       (setq git-blame-colors git-blame-light-colors)))
   (setq git-blame-cache (make-hash-table :test 'equal))
+  (unless (and git-blame-show-timer
+               (memq git-blame-show-timer timer-idle-list))
+    (setq git-blame-show-timer
+          (run-with-idle-timer 0.5 t 'git-blame-echo-current)))
   (setq git-blame-mode t)
   (git-blame-run))
 
@@ -254,7 +280,7 @@ See also function `git-blame-mode'."
 
 See also function `git-blame-mode'."
   (git-blame-cleanup)
-  (if git-blame-idle-timer (cancel-timer git-blame-idle-timer))
+  (if git-blame-update-timer (cancel-timer git-blame-update-timer))
   (setq git-blame-mode nil))
 
 ;;;###autoload
@@ -392,34 +418,33 @@ See also function `git-blame-mode'."
       (goto-line start-line)
       (let* ((start (point))
              (end (progn (forward-line num-lines) (point)))
-             (ovl (make-overlay start end))
-             (hash (car info))
-             (spec `((?h . ,(substring hash 0 6))
-                     (?H . ,hash)
-                     (?a . ,(git-blame-get-info info 'author))
-                     (?A . ,(git-blame-get-info info 'author-mail))
-                     (?c . ,(git-blame-get-info info 'committer))
-                     (?C . ,(git-blame-get-info info 'committer-mail))
-                     (?s . ,(git-blame-get-info info 'summary)))))
+             (ovl (make-overlay start end)))
         (push ovl git-blame-overlays)
         (overlay-put ovl 'git-blame info)
         (overlay-put ovl 'help-echo
-                     (format-spec git-blame-mouseover-format spec))
+                     (git-blame-format info git-blame-mouseover-format))
         (if git-blame-use-colors
             (overlay-put ovl 'face (list :background
                                          (cdr (assq 'color (cdr info))))))
         (overlay-put ovl 'line-prefix
-                     (propertize (format-spec git-blame-prefix-format spec)
+                     (propertize (git-blame-format info git-blame-prefix-format)
                                  'face 'git-blame-prefix-face))))))
 
 (defun git-blame-add-info (info key value)
-  (nconc info (list (cons (intern key) value))))
+  (let* ((keysym (intern key))
+         (a (assq keysym (cdr info))))
+    (if a
+        (setcdr a value)
+      (nconc info (list (cons (intern key) value))))))
 
 (defun git-blame-get-info (info key)
   (cdr (assq key (cdr info))))
 
+(defun git-blame-current-info ()
+  (get-char-property (point) 'git-blame))
+
 (defun git-blame-current-commit ()
-  (let ((info (get-char-property (point) 'git-blame)))
+  (let ((info (git-blame-current-info)))
     (if info
         (car info)
       (error "No commit info"))))
@@ -467,17 +492,22 @@ See also function `git-blame-mode'."
          (setq git-blame-last-update (cons start end))
          (setq git-blame-update-queue (nconc git-blame-update-queue
                                              (list git-blame-last-update)))))
-  (unless (or git-blame-proc git-blame-idle-timer)
-    (setq git-blame-idle-timer
+  (unless (or git-blame-proc git-blame-update-timer)
+    (setq git-blame-update-timer
           (run-with-idle-timer 0.5 nil 'git-blame-delayed-update))))
 
 (defun git-blame-delayed-update ()
-  (setq git-blame-idle-timer nil)
+  (setq git-blame-update-timer nil)
   (if git-blame-update-queue
       (let ((first (pop git-blame-update-queue))
             (inhibit-point-motion-hooks t))
         (git-blame-update-region (car first) (cdr first)))))
 
+(defun git-blame-echo-current ()
+  (let ((info (git-blame-current-info)))
+    (when info
+      (message "%s" (git-blame-format info git-blame-echo-format)))))
+
 (provide 'git-blame)
 
 ;;; git-blame.el ends here
-- 
David Kågedal
Jonathan Nieder· Feb 11, 2011, 02:29 UTC · re: David Kågedal · lore

Re: git-blame.el: does not show one-line summary in echo area

David Kågedal wrote:
> I whipped up a patch anyway. This adds an echo area message shown after
> 0.5 seconds of idleness, using the git-blame-echo-format format string.
> Try it and see if makes sense. I can clean it up (and split it up)
> later.
Sorry for the slow response.
Some quick impressions:
 - The 0.5 second delay is noticeable but not terrible.
   The instantaneous response from the older point-entered based
   code was kind of nice --- too bad it has to go.
 - There is no obvious way to copy the (abbreviated or full) hash
   associated to the current line to the clipboard (for pasting in
   another terminal).
   People more familiar with emacs might want "git show" output in
   another buffer when the line is double-clicked or something. :)
   That would work for me, too (since I could copy the hash from
   there).
 - A nice brief oneline format is
	[%h] %a: %s
   which goes well with a git-blame-prefix-format of
	%t
 - The time format (%c) is rather verbose.  I think I prefer %D
   (so maybe this is a potential tweakable?).
 - email addresses are often longer than 20 characters.  Does
   format-spec provide a way to truncate to a certain length,
   so the prefixes can line up?
 - in general, I like it.  Thanks.
Jonathan
Jonathan Nieder· Feb 11, 2011, 06:42 UTC · re: Jonathan Nieder · lore

git-blame.el: format of date strings

Jonathan Nieder wrote:
>  - The time format (%c) is rather verbose.  I think I prefer %D
>    (so maybe this is a potential tweakable?).

Here's what that might look like. Sadly, format-time-string does not seem to have an equivalent to git log's %ar format.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
 contrib/emacs/git-blame.el |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/contrib/emacs/git-blame.el b/contrib/emacs/git-blame.el
index 9f60a6f..a43981e 100644
--- a/contrib/emacs/git-blame.el
+++ b/contrib/emacs/git-blame.el
@@ -121,6 +121,12 @@ mode. See `git-blame-format' for more information.
 `git-blame' mode. See `git-blame-format' for more information."
   :group 'git-blame)
 
+(defcustom git-blame-date-format
+  "%c"
+  "The format of dates specified with %t or %T passed to `git-blame-format'.
+See `format-time-string' for more information."
+  :group 'git-blame)
+
 (defun git-blame-format (info format)
   "Use format-spec to format the blame info in INFO with the following keys:
 
@@ -146,10 +152,10 @@ mode. See `git-blame-format' for more information.
                    (?H . ,(car info))
                    (?a . ,(git-blame-get-info info 'author))
                    (?A . ,(git-blame-get-info info 'author-mail))
-                   (?t . ,(format-time-string "%c" author-time))
+                   (?t . ,(format-time-string git-blame-date-format author-time))
                    (?c . ,(git-blame-get-info info 'committer))
                    (?C . ,(git-blame-get-info info 'committer-mail))
-                   (?T . ,(format-time-string "%c" committer-time))
+                   (?T . ,(format-time-string git-blame-date-format committer-time))
                    (?s . ,(git-blame-get-info info 'summary))))))
 
 (defun git-blame-color-scale (&rest elements)
-- 
1.7.4
Martin Nordholts· Feb 11, 2011, 07:56 UTC · re: Jonathan Nieder · lore

Re: git-blame.el: format of date strings

Please remove me from CC in the next reply, thanks

I don't use git-blame.el any longer btw, I find this approach works better (adjust for your needs):

(defun programming-project-git-gui-blame ()
   (interactive)
   (shell-command (concat "cd "
                          (programming-project-get-current-source-root)
                          " && "
                          "git gui blame --line="
                          (int-to-string (line-number-at-pos nil))
                          " "
                          (buffer-file-name)
                          "&" )))
  / Martin
On 02/11/2011 07:42 AM, Jonathan Nieder wrote:
Show 43 quoted lines
> Jonathan Nieder wrote:
>
>>   - The time format (%c) is rather verbose.  I think I prefer %D
>>     (so maybe this is a potential tweakable?).
>
> Here's what that might look like.  Sadly, format-time-string does not
> seem to have an equivalent to git log's %ar format.
>
> Signed-off-by: Jonathan Nieder<jrnieder@gmail.com>
> ---
>   contrib/emacs/git-blame.el |   10 ++++++++--
>   1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/contrib/emacs/git-blame.el b/contrib/emacs/git-blame.el
> index 9f60a6f..a43981e 100644
> --- a/contrib/emacs/git-blame.el
> +++ b/contrib/emacs/git-blame.el
> @@ -121,6 +121,12 @@ mode. See `git-blame-format' for more information.
>   `git-blame' mode. See `git-blame-format' for more information."
>     :group 'git-blame)
>
> +(defcustom git-blame-date-format
> +  "%c"
> +  "The format of dates specified with %t or %T passed to `git-blame-format'.
> +See `format-time-string' for more information."
> +  :group 'git-blame)
> +
>   (defun git-blame-format (info format)
>     "Use format-spec to format the blame info in INFO with the following keys:
>
> @@ -146,10 +152,10 @@ mode. See `git-blame-format' for more information.
>                      (?H . ,(car info))
>                      (?a . ,(git-blame-get-info info 'author))
>                      (?A . ,(git-blame-get-info info 'author-mail))
> -                   (?t . ,(format-time-string "%c" author-time))
> +                   (?t . ,(format-time-string git-blame-date-format author-time))
>                      (?c . ,(git-blame-get-info info 'committer))
>                      (?C . ,(git-blame-get-info info 'committer-mail))
> -                   (?T . ,(format-time-string "%c" committer-time))
> +                   (?T . ,(format-time-string git-blame-date-format committer-time))
>                      (?s . ,(git-blame-get-info info 'summary))))))
>
>   (defun git-blame-color-scale (&rest elements)
-- 
My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
Jonathan Nieder· Jun 10, 2012, 08:24 UTC · re: Jonathan Nieder · lore

[PATCH/RFC] git-blame.el: truncate author to avoid jagged left edge of code

Without this patch, the author column in git-blame-mode spills over in some rows:

	822a7d <ramsay@ramsay1.demon.co.uk>:const char git_usage_
	f2dd8c <jon.seymour@gmail.com>: "git [--version] [--exec-
	a1bea2 <josh@joshtriplett.org>: "           [-p|--paginat
	a1bea2 <josh@joshtriplett.org>: "           [--git-dir=<p
	293b07 <trast@student.ethz.ch>: "           [-c name=valu
	62b469 <stepan.nemec@gmail.com>:        "           <comm
	822a7d <ramsay@ramsay1.demon.co.uk>:

As a result, code meant to line up does not line up correctly and the colored code area has a jagged left edge.

Specify a maximum width for the autohr email address in the default blame prefix (i.e., use %20.20A instead of %20A) to fix it.

	822a7d <ramsay@ramsay1.demon.c:const char git_usage_strin
	f2dd8c <jon.seymour@gmail.com>: "git [--version] [--exec-

The (format) function used to implement format-spec has supported precision specifiers like ".20" in emacs since 2002-12-09, so this should be safe.

Helped-by: Kevin Ryde <user42@zip.com.au>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
In February of 2011, I wrote:
>  - email addresses are often longer than 20 characters.  Does
>    format-spec provide a way to truncate to a certain length,
>    so the prefixes can line up?
Better late than never, I guess.  Sensible?
 contrib/emacs/git-blame.el |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/emacs/git-blame.el b/contrib/emacs/git-blame.el
index d351cfb6..137d5ba9 100644
--- a/contrib/emacs/git-blame.el
+++ b/contrib/emacs/git-blame.el
@@ -102,7 +102,7 @@
   :group 'git-blame)
 
 (defcustom git-blame-prefix-format
-  "%h %20A:"
+  "%h %20.20A:"
   "The format of the prefix added to each line in `git-blame'
 mode. The format is passed to `format-spec' with the following format keys:
 
-- 
1.7.10
David Kågedal· Jan 29, 2013, 20:17 UTC · re: Jonathan Nieder · lore

Re: [PATCH/RFC] git-blame.el: truncate author to avoid jagged left edge of code

Sorry for being absent a long time. I hope you have managed to sort out the git-blame fixes anyway.

Jonathan Nieder <jrnieder@gmail.com> writes:
Show 50 quoted lines
>Without this patch, the author column in git-blame-mode spills
>over in some rows:
>
>	822a7d <ramsay@ramsay1.demon.co.uk>:const char git_usage_
>	f2dd8c <jon.seymour@gmail.com>: "git [--version] [--exec-
>	a1bea2 <josh@joshtriplett.org>: "           [-p|--paginat
>	a1bea2 <josh@joshtriplett.org>: "           [--git-dir=<p
>	293b07 <trast@student.ethz.ch>: "           [-c name=valu
>	62b469 <stepan.nemec@gmail.com>:        "           <comm
>	822a7d <ramsay@ramsay1.demon.co.uk>:
>
>As a result, code meant to line up does not line up correctly and the
>colored code area has a jagged left edge.
>
>Specify a maximum width for the autohr email address in the default
>blame prefix (i.e., use %20.20A instead of %20A) to fix it.
>
>	822a7d <ramsay@ramsay1.demon.c:const char git_usage_strin
>	f2dd8c <jon.seymour@gmail.com>: "git [--version] [--exec-
>
>The (format) function used to implement format-spec has supported
>precision specifiers like ".20" in emacs since 2002-12-09, so this
>should be safe.
>
>Helped-by: Kevin Ryde <user42@zip.com.au>
>Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
>---
>In February of 2011, I wrote:
>
>>  - email addresses are often longer than 20 characters.  Does
>>    format-spec provide a way to truncate to a certain length,
>>    so the prefixes can line up?
>
>Better late than never, I guess.  Sensible?
>
> contrib/emacs/git-blame.el |    2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/contrib/emacs/git-blame.el b/contrib/emacs/git-blame.el
>index d351cfb6..137d5ba9 100644
>--- a/contrib/emacs/git-blame.el
>+++ b/contrib/emacs/git-blame.el
>@@ -102,7 +102,7 @@
>   :group 'git-blame)
> 
> (defcustom git-blame-prefix-format
>-  "%h %20A:"
>+  "%h %20.20A:"
>   "The format of the prefix added to each line in `git-blame'
> mode. The format is passed to `format-spec' with the following format keys:
-- 
David Kågedal
Kevin Ryde· Feb 4, 2011, 21:49 UTC · re: David Kågedal · lore

Re: git-blame.el: does not show one-line summary in echo area

David Kågedal <davidk@lysator.liu.se> writes:
>
> But we can
> of course let the echo area grow to two lines, or even three.

Though xemacs 21 can't grow it, and emacs doesn't if you turn off message-truncate-lines.

If message-truncate-lines is nil or unbound you might collapse out newlines or perhaps ellipsize or something.

Andreas Schwab· Dec 4, 2009, 17:42 UTC · re: Sergei Organov · lore

Re: git-blame.el: what is format-spec?

Sergei Organov <osv@javad.com> writes:
> However, isn't it a bad idea to require Gnus(!) for git-blame to run? Gnus
> is not installed on our server where I've encountered the problem. 
Gnus has been part of Emacs since more than 10 years.
> Was format-spec actually moved to core emacs recently?
Yes, in 23.1.
Andreas.
-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Matthieu Moy· Dec 4, 2009, 18:18 UTC · re: Andreas Schwab · lore

Re: git-blame.el: what is format-spec?

Andreas Schwab <schwab@linux-m68k.org> writes:
Show 6 quoted lines
> Sergei Organov <osv@javad.com> writes:
>
>> However, isn't it a bad idea to require Gnus(!) for git-blame to run? Gnus
>> is not installed on our server where I've encountered the problem. 
>
> Gnus has been part of Emacs since more than 10 years.

... but Linux distros often cut it out by default, so if you just ask for Emacs as a package, you don't get the Gnus package.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

← back to recent threads