args-out-of-range error in blame mode

[garyo]

I have a file in blame mode, go to the chunk of interest, hit RET (to open log). I get an error with this backtrace:

Debugger entered--Lisp error: (args-out-of-range 2 2)
  next-single-property-change(2 :mark)
  egg-log-buffer-get-marked-alist(10004 46 9998 62)
  egg-log-buffer-get-rebase-marked-alist()
  egg-generic-display-logs((:description #("history scope: v6-maint-branch and 1c1959d" 0 15 (face egg-text-2) 15 30 (face egg-term) 30 35 (face egg-text-2) 35 42 (face egg-term)) :closure (lambda nil (egg-insert-logs-with-full-decoration (list "v6-maint-branch" "1c1959d1956637468c01e781e414b41531f5a1d9"))) :title #("v6-maint-branch" 0 15 (face egg-branch)) :subtitle #("1510b4bef24ea5cc69df31d3f31c71472d68ed96" 0 40 (face font-lock-string-face))) nil)
  egg-log-buffer-redisplay(#<buffer *sapphire-v6-log@c:/genarts/sapphire-v6/.git*>)
  egg-do-locate-commit("1c1959d1956637468c01e781e414b41531f5a1d9")
  egg-blame-locate-commit(11903 nil)
  call-interactively(egg-blame-locate-commit nil nil)

(point-min) is 1, so pos is 1. Apparently it can't find the next single property change after that. I'm not sure why, the selected buffer seems to be the blame buffer and it has lots of properties.

Oh yes, this is on nightly emacs 24.3.50.1 of 11-19-12 (Dani's Windows trunk build)

[bogolisk]

egg-log-buffer-redisplay should be called with egg's log buffer as argument. I'm not sure what the "#" in backtrace means:

egg-log-buffer-redisplay(#)

[garyo]

Not sure what happened to that line in my cut 'n paste. [EDIT: github processes some text specially in these tickets! Look at the source to see the real thing.] Mostly correct version of that line:

 egg-log-buffer-redisplay(#<buffer *sapphire-v6-log@c:/genarts/sapphire-v6/.git*>)

The rest seems OK. But if I run egg-log-buffer-get-marked-alist in edebug and check the currently selected buffer (with "P" in edebug) it shows my source buffer (in egg blame mode), not the log buffer. I'll poke at it some more if you think this is related.

By the way, the log buffer sapphire-v6-log@c:/genarts/sapphire-v6/.git is empty.

[bogolisk]

so what's exactly the argument egg-log-buffer-redisplay recieved when it cr*pped out?

btw, egg-log-buffer-get-marked-alist () will collect the marked commits in the "current" buffer because it's expected to be called in the log buffer.

[garyo]

On Thu, Nov 29, 2012 at 4:38 PM, Bogolisk [email protected] wrote:

so what's exactly the argument egg-log-buffer-redisplay recieved when it
cr*pped out?

I edited the text of the bug report to have the correct info. It's the log
buffer (which is empty).

Gary

[bogolisk]

well, it's a bug!!!

I'll whip up a fix, but it might be on the testing branch.

[bogolisk]

If you're comfortable with diff and patch, try this patch:

diff --git a/egg.el b/egg.el
index 621f6be..80d5c82 100644
--- a/egg.el
+++ b/egg.el
@@ -4509,7 +4509,8 @@ With C-u prefix, unmark all."
(let ((pos (point-min))
marker subject alist)
(save-excursion

•  (while (setq pos (next-single-property-change (1+ pos) :mark))
  

•  (while (and (< pos (point-max))
  

•             (setq pos (next-single-property-change (1+ pos) :mark)))
  (when (or (null types) (memq (get-text-property pos :mark) types))
    (goto-char pos)
    (setq marker (point-marker))
  

On Thu, Nov 29, 2012 at 4:59 PM, GaryO [email protected] wrote:

On Thu, Nov 29, 2012 at 4:38 PM, Bogolisk [email protected]
wrote:

so what's exactly the argument egg-log-buffer-redisplay recieved when it
cr*pped out?

I edited the text of the bug report to have the correct info. It's the log
buffer (which is empty).

Gary

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/54#issuecomment-10868389.

[garyo]

That helps, definitely. It gets further.

There is I think another bug though, if the rev in question is not found in
the log buffer. I have these customizations:
'(egg-log-HEAD-max-len 50)
'(egg-log-all-max-len 500)

(which I do to make it go faster -- maybe that's too aggressive). But it
means that the rev I want to go to from the blame mode buffer is not found
in the log buffer, because it only goes back 50 revs. I think it's
trying to include my rev, because at the top of the log buffer I see:
history scope: master and a7dfc6a
and a7dfc6a is the rev I'm looking for. But the log buffer doesn't
actually include that rev, at least that I can see. I think you may have
to temporarily bind those max-len vars to large values before calling the
log, or I suppose you could call log multiple times. Or maybe all you care
about is the sha in question, and you don't even need to include master.
Just as an experiment, I tried that: I just used ,sha1 instead of (list
,head-name ,sha1) in egg-do-locate-commit and it seemed to work for me.

On Thu, Nov 29, 2012 at 6:38 PM, Bogolisk [email protected] wrote:

If you're comfortable with diff and patch, try this patch:

diff --git a/egg.el b/egg.el
index 621f6be..80d5c82 100644
--- a/egg.el
+++ b/egg.el
@@ -4509,7 +4509,8 @@ With C-u prefix, unmark all."
(let ((pos (point-min))
marker subject alist)
(save-excursion

• (while (setq pos (next-single-property-change (1+ pos) :mark))
• (while (and (< pos (point-max))
• (setq pos (next-single-property-change (1+ pos) :mark)))
  (when (or (null types) (memq (get-text-property pos :mark) types))
  (goto-char pos)
  (setq marker (point-marker))

On Thu, Nov 29, 2012 at 4:59 PM, GaryO [email protected] wrote:

On Thu, Nov 29, 2012 at 4:38 PM, Bogolisk [email protected]
wrote:

so what's exactly the argument egg-log-buffer-redisplay recieved when
it
cr*pped out?

I edited the text of the bug report to have the correct info. It's the
log
buffer (which is empty).

Gary

—
Reply to this email directly or view it on GitHub<
https://github.com/byplayer/egg/issues/54#issuecomment-10868389>.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/54#issuecomment-10871879.

Gary

[bogolisk]

Try cherry-pick:

4c5bca3 fixed bug: cannot locate commit when displayed history is too short

[bogolisk]

On Fri, Nov 30, 2012 at 8:51 AM, GaryO [email protected] wrote:

That helps, definitely. It gets further.

There is I think another bug though, if the rev in question is not found
in
the log buffer. I have these customizations:
'(egg-log-HEAD-max-len 50)
'(egg-log-all-max-len 500)

(which I do to make it go faster -- maybe that's too aggressive). But it
means that the rev I want to go to from the blame mode buffer is not found
in the log buffer, because it only goes back 50 revs. I think it's
trying to include my rev, because at the top of the log buffer I see:
history scope: master and a7dfc6a
and a7dfc6a is the rev I'm looking for.

Hi

it was intentional. The intend was to show the commit in the history of the
current branch.
My latest commit should fix this bug. Basically, egg will compute the
minimum number of commits
in order to display the commit and HEAD.

[garyo]

Thanks, it works now. Just FYI, I recently discovered the git rev-list
--ancestry-path option, which might perhaps be useful to you in this
context, since it prunes the commit list to only those commits that are
directly on the given ancestry chain between commit1 and commit2.

On Sun, Dec 2, 2012 at 4:50 AM, Bogolisk [email protected] wrote:

On Fri, Nov 30, 2012 at 8:51 AM, GaryO [email protected] wrote:

That helps, definitely. It gets further.

There is I think another bug though, if the rev in question is not found
in
the log buffer. I have these customizations:
'(egg-log-HEAD-max-len 50)
'(egg-log-all-max-len 500)

(which I do to make it go faster -- maybe that's too aggressive). But it
means that the rev I want to go to from the blame mode buffer is not
found
in the log buffer, because it only goes back 50 revs. I think it's
trying to include my rev, because at the top of the log buffer I see:
history scope: master and a7dfc6a
and a7dfc6a is the rev I'm looking for.

Hi

it was intentional. The intend was to show the commit in the history of the
current branch.
My latest commit should fix this bug. Basically, egg will compute the
minimum number of commits
in order to display the commit and HEAD.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/54#issuecomment-10927873.

Gary

[bogolisk]

Thanx, that should be faster than my current implementation because it doesn't need to parse the commit objects.

[bogolisk]

new implementation (the previous one was not correct.)