Karl Hasselström <kha@xxxxxxxxxxx> writes: > On 2007-01-31 14:04:06 +0100, David Kågedal wrote: > >> Here's another version of git-blame.el that automatically tries to >> create a sensible list of colors to use for both light and dark >> backgrounds. Plus a few minor fixes. > > I've tried it, like the concept of in-buffer blame and the pretty > colors, and have a few comments and suggestions: > > 1. For some files, but not all, emacs is unresponsive (and consumes > lots of CPU) right after git-blame-mode is activated. Once > git-blame has finished, it becomes responsive again, but this > kind of defeats the whole "incremental" idea. > > This is most easily seen by holdnig down Ctrl+N or similar, to > make the cursor move constantly. Don't know why this happens. I haven't seen it myself. > 2. Getting to see the sha1 of the commit is not so useful when it > can't be selected for copy-pasting. Maybe a keyboard shortcut for > "copy-sha1-to-kill-ring"? Sure. It's a trivial addition. > 3. Even after I've edited a line, or added a new line, they continue > to be attributed to the same existing commits. They should either > have no attribution, or possibly just "local edit" or something. > I seem to recall this kind of functionality for git-blame being > discussed very recently? I saw it was discussed, but I don't think it was added. Currently, it probably makes most sense to verify that the file hasn't been modified, and then switch to read-only mode while viewing the blame. > 4. It would be nice with a keyboard shortcut that (in a new buffer) > printed more details about the commit under the cursor, kind of > like the output from git-log. (Having this available would > obviate the need for (2).) > > 5. It would be nice with a keyboard shortcut for displaying the > commit under the cursor in gitk. (For extra points: successive > uses of this command should reuse the same gitk window if it's > still open.) This is almost as trivial as 2, since the hash is available, you can simply run shell-command. > 6. It would be nice with a keyboard shortcut for displaying (in a > separate buffer) the diff to that file introduced by the commit > under the cursor. This could be combined with (3) by having > commit details followed by diff. As in "git log -p", you mean? > Oh, and try to have it done by Monday. ;-) Sorry Kalle. I won't have any more spare cycles until next week. -- 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