1

I'm not sure how to completely reproduce this. It may be related to this other question of mine. My hope is that someone else has seen this as well and knows what causes it.

Sometimes when editing an emacs buffer, generally for a Python file, the buffer is out of date (usually because it has changed from git checkouts in other terminal tabs). So when I try to edit the buffer, it tells me that the file is out of date and if I want to edit it or revert it. I choose revert.

What happens then is that instead of reverting the file, it gets corrupted. In particular, it seems to insert chunks of the original file in the wrong place. For instance, the first 20 or so lines will be inserted twice. This error persists (but often with slightly different results) if I manually run M-x revert-buffer.

Fortunately, I always keep my files under revision control, so I can usually detect and fix these issues, but it's pretty annoying, and there is potential for it to screw me over pretty hard or even cause me to lose data. Any suggestions on what might be causing this are welcome.

asmeurer
  • 1,572
  • 12
  • 32
  • 1
    Check what the value of revert-buffer-function is, and if it is not revert-buffer--default then check what the value (a function) actually does. You can also use debug-on-entry for that function, to follow what it does in the debugger. – Drew Sep 02 '15 at 22:30
  • It looks like it is set to the default. So is revert-buffer-insert-file-contents-function. – asmeurer Sep 03 '15 at 19:41
  • Reading through the source code, I wonder if this is related to auto-save somehow. I have my auto-save set to save to ~/.emacs.d. Is it possible that multiple emacs processes running at once (which I typically have) could have some race conditions that corrupt these? – asmeurer Sep 03 '15 at 19:55
  • Dunno, but I doubt that (for no good reason; just a hunch). – Drew Sep 03 '15 at 20:16
  • If this is something that you can reproduce, e.g., starting from emacs -Q (no init file) and with a step-by-step description, then consider filing an Emacs bug report (M-x report-emacs-bug). If this is an Emacs bug it is quite important - users should not have their data (including programs) corrupted. – Drew Sep 03 '15 at 20:18
  • I really wish I could figure out the steps to reproduce this consistently. I tried for a while, but I had a hard time even getting emacs to even not automatically revert a buffer. I use emacsclient, and sometimes when I exit the client and reopen, the buffer from the visited file is still in the buffers list, and sometimes it isn't. I can't even figure out the pattern of when that happens or not. – asmeurer Sep 03 '15 at 20:26
  • Sounds like you have global-auto-revert-mode turned on. I'd suggest that you turn off automatic reversion, to start with - take it out of the equation. See if you still get the problem when you revert manually. – Drew Sep 03 '15 at 21:47
  • It's not enabled. I think there is something related to how emacsclient decides to kill a buffer or just close the frame and leave the buffer alive (I always quit using C-x C-c). I think my best bet here is to wait until I notice this happening again and debug-on-entry. – asmeurer Sep 04 '15 at 16:28
  • This may be related to an issue of emacs-jedi. Do you use emacs-jedi? If so, I think this problem will be fixed if you upgrade emacs-jedi to the latest version and set jedi:install-imenu to nil. – sho Sep 09 '15 at 14:55
  • @sho I do use emacs-jedi. That sounds exactly like my issue. Can you post this as an answer? – asmeurer Sep 09 '15 at 16:55
  • Ugh. It seems that the jedi imenu never worked for me, but I kept it enabled anyway. – asmeurer Sep 09 '15 at 16:57

1 Answers1

3

It seems that this problem is caused by a bug of emacs-jedi.

To avoid it,

  1. Upgrade emacs-jedi to the latest version (newer than 736300f).
  2. Set jedi:install-imenu to nil (the default value is nil).

Something is wrong with jedi:after-change-handler. But I do not fully understand why the problem occurs. It is related to asynchronous programming and is hard to debug.

Even in the latest version (cf4689e), the problem still occurs if jedi:install-imenu is non-nil. Essentially, the bug is not fixed yet.

sho
  • 146
  • 3
  • Awesome. This is almost certainly it, since I've only seen it in Python, and I do use emacs-jedi with jedi:install-imenu set to t. This also explains why it's so hard to reproduce. – asmeurer Sep 09 '15 at 22:03