0

After a while running emacs (typically days) all comint buffers start to behave strangely (shell, python, SQL). The ones I have already opened and the new ones that I open.

When I am after prompt, C-a moves tho the beginning of the line, as opposed to right after the prompt. More irritating is the fact that in this state C-up (comint-previous-input) moves to the beggining of the line before inserting the previous input, leaving the line broken (the text is before the prompt).

A workaround for the second problem is to do (setq comint-use-prompt-regexp t), but the first problem remains.

That was happening with emacs 24.3 in GNU Linux (cassou ppa for Ubuntu 12.04) and happens also now with emacs 24.4 (compiled by myself).

I debugged the shipped comint.el and tracked the issue to the built-in function line-beginning-position; in freshly started emacs sessions that function works fine in comint mode. After a while this function just returns the point at the beggining of line (just like comint-mode were not enabled).

I suspect it has something to do with my setup, since google did not came up with any help. However, binary search is not an option since I would need to spend days with a half functional emacs while waiting for the problem to happen.

Any ideas about how to narrow the suspects or further debug the problem?

Improve this question
2
  • Did you check inhibit-field-text-motion?
    – abo-abo
    Dec 30, 2014 at 16:39
  • Yes, that variable is as it should be (and I tried toggling it, but no difference)
    – juanleon
    Dec 30, 2014 at 16:59

2 Answers 2

Reset to default
0

Try to reproduce the problem without using your init file: emacs -Q, loading anything you need explicitly, and keeping track of all that you do.

If you can repro the problem that way, then report this as a bug: M-x report-emacs-bug.

If you cannot, then recursively bisect your init file, to find out what the culprit code is. You can do that by commenting out blocks of code there, using command comment-region (you can uncomment a selection by giving that command a plain prefix arg, C-u).

Improve this answer
4
  • The problem with bisecting is what I commented in the question: problem is not evident until after some time has happened (last time it was 2 days). I don't know what triggers the problem, because "emacs -Q" works as good as "emacs" in the 10 first minutes. Also, my .emacs is huge and living with half of it commented out for several days while I decide if the problem will appear or not is worse than the problem.
    – juanleon
    Dec 30, 2014 at 16:58
  • Try debug-on-entry for the C-a command, when the problem occurs (after loading the *.el, not *.elc, defining that command), to see just what is happening. That may give a clue as to why.
    – Drew
    Dec 30, 2014 at 19:05
  • Everything goes smoothly until line-beginning-position is called (and that is C source code). Then that function returns the wrong value (the real line beginning position).
    – juanleon
    Dec 31, 2014 at 9:29
  • M-x report-emacs-bug, providing a clear recipe, preferably one that starts from emacs -Q.
    – Drew
    Dec 31, 2014 at 14:49
0

After a couple of days without incident, I am not 100% sure but I am pretty confident that the problem was related to fixmee-mode (or the library that mode uses underneath: button-lock-mode).

I removed them from my setup and no more issues. IIRC those libraries made other emacs packages (like wdired, dired-efap) that worked with text properties in the buffer to have "glitches".

Improve this answer

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.