Hitting max-lisp-eval-depth when using magithub

[SerialVelocity]

Hey,

I haven't got the stacktrace yet but here's the error I am seeing:

magithub-ci-status: Lisp nesting exceeds ‘max-lisp-eval-depth’

This happens before I have decrypted my ~/.authinfo.gpg file. It's symmetrically encrypted and I have this in my config:

;; Fix gpg-agent pin entry
(setq epa-pinentry-mode 'loopback)

Best, Ben

[SerialVelocity]

The workaround I've tried is to disable magithub temporarily. I'm not sure but it would probably also be fixed by unlocking the authinfo.gpg file.

[vermiculus]

We should already have handling for this. If you set magithub-debug-mode to t and try again, what appears in *Messages*?

[SerialVelocity]

Unfortunately I haven't figured out how to trigger the error yet. I'll try setting that to t and also debug-on-error next time I see it. I'm on 0.1.4 btw.

[SerialVelocity]

The debug stacktrace consists of:

Debugger entered--Lisp error: (error "Lisp nesting exceeds ‘max-lisp-eval-depth’")
  magithub-debug-message("ghub-request%S" ("GET" "https://github-enterprise/api/v3/repos/my-org/my-repo/commits/my-branch/name/status" nil nil))

then this over and over:

  ghub--request("GET" "/repos/my-org/my-repo/commits/branch/name/status" nil nil)
  apply(ghub--request ("GET" "/repos/my-org/my-repo/commits/branch/name/status" nil nil))
  magithub-debug--ghub-request-wrapper(ghub--request "GET" "/repos/my-org/my-repo/commits/branch/name/status" nil nil)
  apply(magithub-debug--ghub-request-wrapper ghub--request ("GET" "/repos/my-org/my-repo/commits/branch/name/status" nil nil))

and then after that:

  ghub-request("GET" "/repos/my-org/my-repo/commits/my-branch/name/status" nil nil)
  ghubp-request(get "/repos/my-org/my-repo/commits/my-branch/name/status" nil nil)
  apply(ghubp-request get "/repos/my-org/my-repo/commits/my-branch/name/status" (nil nil))
  ghubp-get-repos-owner-repo-commits-ref-status(...)
  magithub-ci-status("my-branch/name")
  magithub-insert-ci-status-header()
  magithub-maybe-insert-ci-status-header()
  funcall(magithub-maybe-insert-ci-status-header)
  mapc(funcall (magit-insert-upstream-branch-header magit-insert-push-branch-header magit-insert-tags-header magithub-maybe-report-offline-mode magithub-maybe-insert-ci-status-header))
  magit-insert-remaining-headers()
  run-hooks(magit-insert-section-hook)
  magit-insert-head-branch-header()
  magit-insert-headers((magit-insert-error-header magit-insert-diff-filter-header magit-insert-head-branch-header magit-insert-upstream-branch-header magit-insert-push-branch-header magit-insert-tags-header magithub-maybe-report-offline-mode magithub-maybe-insert-ci-status-header))
  magit-insert-status-headers()
  run-hooks(magit-status-sections-hook)
  magit-run-section-hook(magit-status-sections-hook)
  magit-status-refresh-buffer()
  apply(magit-status-refresh-buffer nil)
  magit-refresh-buffer()
  magit-refresh()
  funcall-interactively(magit-refresh)
  call-interactively(magit-refresh nil nil)
  command-execute(magit-refresh)

My *Messages* has this over and over again:

magithub: ghub-request("GET" "https://github-enterprise/api/v3/repos/my-org/my-repo/commits/my-branch/name/status" nil nil)

[SerialVelocity]

authinfo.gpg could actually just be a red herring. By the time I unlock it, enough time has probably passed.

[SerialVelocity]

I think there are really two issues here:

• The stack overflow seen above
• The fact that if magithub throws an error, magit fails to work at all (I couldn't open the magit screen at all just now)

As a note: I tried to upgrade magithub and now everything is just borked because of #171 (magit-buffer-lock-functions not defined). I use melpa stable so I don't have access to anything past magit 2.11. I've just disabled magithub entirely for now.

[vermiculus]

I do try to make MELPA-Stable work in my packages, but it's almost always an after thought. For magithub, it's best to be using plain old MELPA. (IIRC, MELPA-Stable wasn't an enthusiastic addition to MELPA from the start; it's difficult to get these things right.)

[vermiculus]

This mostly stems from needing to make the occasional PR to magit core in order to make something work correctly on this end 😄

[vermiculus]

Closing this as a duplicate of #219; sorry for all your troubles with magithub on stable melpa ☹️