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.

Improve this question
11
  • 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 2, 2015 at 22:30
  • It looks like it is set to the default. So is revert-buffer-insert-file-contents-function.
    – asmeurer
    Sep 3, 2015 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 3, 2015 at 19:55
  • Dunno, but I doubt that (for no good reason; just a hunch).
    – Drew
    Sep 3, 2015 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 3, 2015 at 20:18

1 Answer 1

Reset to default
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.

Improve this answer
1
  • 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 9, 2015 at 22:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.