magit-status buffer can get into a state where it doesn't refresh #483

Closed
stsquad opened this Issue Sep 26, 2012 · 15 comments

Projects

None yet

5 participants

@stsquad
stsquad commented Sep 26, 2012

The magit-status buffer can get itself into a state where it never refreshes when actions are carried out (e.g. TAB to expand diff or s to statge). I end up having to re-run magit-status for the display to be correct.

It seems to be triggered by magit tripping over something. The only clue I've seen so far in these cryptic messages:

Parsing edit-server.el (LL)...done
Error during redisplay: (wrong-type-argument arrayp nil) [5 times]
QuitError during redisplay: (wrong-type-argument arrayp nil)
Error during redisplay: (wrong-type-argument arrayp nil) [14 times]

Even closing all the magit buffers (status, process and log) and restarting leaves it broken. The only solution I've found so far is to re-start emacs which is obviously sub-optimal.

@radamant

👍 I am experiencing this issue as well

@dudebout
Member

Experienced it too.

@tarsius
Member
tarsius commented May 13, 2013

Does anyone know how to turn on debug-on-error inside redisplay code? It makes sense that it is disabled there by default (e.g. endless loop when displaying the backtrace) but sometimes we just need that backtrace. One solution could be to write the backtrace to a file instead of displaying it in Emacs.

I am not experiences this particular problem but have a similar and very persistent problem that from time to time spams *Messages* with lines saying some (actually defined) face isn't defined.

@tarsius
Member
tarsius commented May 13, 2013

@dudebout I am this to you because... well, you are experiencing it too :-)

I would like to get the bug count down, and will try my best too, just not here (unless someone can give me the information I asked for above.)

@dudebout dudebout was assigned May 13, 2013
@dudebout
Member

@tarsius, unfortunately I experienced it once and I do not have reproduction steps. There was definitely a failed magit action but I do not remember what.

@tarsius
Member
tarsius commented May 15, 2013

@stsquad @radamant are you still experiencing this?

@stsquad
stsquad commented May 17, 2013

@tarsius not recently although I haven't been doing much development the last month or so.

@tarsius
Member
tarsius commented May 26, 2013

Please reopen if this should happen again.

@tarsius tarsius closed this May 26, 2013
@stsquad
stsquad commented May 29, 2013

OK I'm re-opening as it's just triggered. The key thing that happened was an underlying git command failed leaving a backtrace (sorry I foolishly forgot to save it). After that point all magit-status buffers wouldn't respond to key-presses (e.g. Tab, s etc). As per before even closing all magit related buffers and restarting magit didn't bring it back.

This is with latest dev version as distributed via MELPA.

@stsquad
stsquad commented May 29, 2013

@tarsius ok I can't actually see how to re-open this issue.

One other thing I noted. The highlighting of the changes section had stopped. Perhaps this is related to the failure to spot key-presses.

@tarsius tarsius reopened this May 29, 2013
@stsquad
stsquad commented May 29, 2013

I don't know if this is directly related but I think some other global minor modes may be interfering. I've already disabled yasnippet for magit-mode but even then I can see a TAB swallowed up so you have to hit it twice to get the background git task running. Then TAB toggling works as normal.

@stsquad
stsquad commented May 29, 2013

Just confirmed the lazy TAB occurs on:

emacs -Q /some/file
M-x package-initialize
M-x magit-status

Although of course something may be in the way from the other ELPA packages.

@stsquad
stsquad commented May 29, 2013

OK the TAB swallowing is simply because the first magit-toggle-selection takes so long to return (possibly because I have a big repo). I'll raise a separate issue for that.

@jsoa
jsoa commented Jun 19, 2013

I was getting the same issue when I noticed I had (setq debug-on-error t) set. After setting this to ``nil` i have not seen the issue since.

@tarsius
Member
tarsius commented Oct 25, 2013

The key thing that happened was an underlying git command failed leaving a backtrace

I was getting the same issue when I noticed I had (setq debug-on-error t) set. After setting this to ``nil` i have not seen the issue since.

There no longer is any cleanup code that is prevented from running when the debugger kicks in.

@tarsius tarsius closed this Oct 25, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment