1

And it's driving me crazy.

My TERM = xterm-256color, emacs 23.3.1. I'm using Ubuntu, and this problem doesn't occur on OS X using the same dotfiles/settings. I am running it in terminal (in tmux, in bash, over SSH, on Ubuntu, iTerm2 being my emulator).

If I open a file, e.g. emacs init.el, and immediately press DOWN, the B persists. If I don't press anything right away, nothing gets inserted.

So it looks like nothing is going on. If my mark isn't at the beginning of the buffer, the B is inserted there, I think (it is harder to reproduce this).

Any help would be MUCH appreciated. My repos are littered with commit messages like "ARGH THE B OF DOOM STRIKES AGAINaskdjasdq".

Isaac
  • 15,783
  • 9
  • 53
  • 76
  • Is this just in emacs, or do you get the B-of-doom in other editors as well? – Marc B Jul 09 '12 at 20:13
  • Do you mean "66" rather than "11"? Because `'B'` == 66 in ASCII. (Even if you were using hex values, it'd be 0x42, not 0x11.) – JAB Jul 09 '12 at 20:14
  • Appears to just be in emacs (just tried it in vi). – Isaac Jul 09 '12 at 20:14
  • Er, yeah, it's 66. Don't know how I got 11. – Isaac Jul 09 '12 at 20:16
  • 2
    Does this behavior occur in a graphical Emacs session? Does it occur outside of a `tmux` window? I seem to recall once having a similar issue some years ago; the culprit ultimately proved to be `readline` and was resolved with some modifications to my global `inputrc` and possibly `termcap` settings. Sadly, this was so long ago that I don't remember the details. If you could isolate the source of the problem more exactly by eliminating some of the other programs involved (like testing outside of `tmux` and in a different shell and terminal emulator, if possible), that might help. – Greg E. Jul 09 '12 at 20:25
  • 1
    Brilliant, it appears to not occur outside `tmux`. Can you further recall anything you did? – Isaac Jul 09 '12 at 20:29
  • 1
    Tangentially, you should always check what you are about to commit, even if you don't suffer from some unwanted insertion problem. Your "B of doom" would be easily spotted in a diff and fixed before you committed it. – phils Jul 09 '12 at 22:54
  • @IsaacHodes, I don't remember precisely what I had to do and, given that my system configuration was dramatically different, I doubt specifics would be helpful anyway. Based on a quick search, it seems a lot of threads indicate that `tmux` behaves best if `TERM` is set to `screen-256color`. See also Craig Citro's answer below. If changing `TERM` fixes your problem but disables 256-color support in Emacs, there [appears to be a solution in another SO question](http://stackoverflow.com/questions/684424/how-do-i-set-up-my-linux-x-terminal-so-that-emacs-has-access-to-256-colors). – Greg E. Jul 10 '12 at 00:44
  • I've deleted my answer: I was going down the wrong path. I can reproduce this on my machine, but only ~5% of the time. I suspect hat what's going on is that some function we both load at frame creation time is accidentally eating an extra keystroke, namely the escape for ``. If so, we can start bisecting `.emacs`. To confirm, here's a question: can you get this behavior to happen, inside or outside of tmux, if you start emacs without your config file (`emacs -q -nw`)? – Craig Citro Jul 15 '12 at 06:02
  • Unfortunately it still happens (that was one of the first things I tried—my dotfiles are getting huge) – Isaac Jul 15 '12 at 19:11
  • Same error for me: when I use tmux, then launch emacs and immediately press the down arrow, then a "B" character is inserted into my emacs file. The symptom does not happen if I'm using the same emacs but without tmux. Any leads? Thanks! – joelparkerhenderson Jul 15 '13 at 04:58
  • No idea! I don't think I get the error anymore, though; see if anything in my tmux.conf helps you out: https://gist.github.com/ihodes/6002895 – Isaac Jul 15 '13 at 19:56

0 Answers0