I am using emacs under iTerm2 on Mac. I am using mouse to scroll up and down. Please not that I haven't face with the issue when I remotely connected into a linux machine, which has exactly same emacs setup.

When I scroll to bottom OBB character is generated and emacs is hangs. When I scroll to top section OAA character is generated and hangs again.

Than emacs crashes/suspends itself and generated following output:

[1]  + 5999 suspended  TERM=xterm-256color emacs -nw -nw --no-site-file --debug-init

=> Another case, when I keep scroll to bottom of the buffer and when the cursor ends up on the bottom, emacs halts. I try to enter character or scroll back nothing happens. In another terminal when I try to close emacs, it gets closed and the characters I already entered would show up on the terminal.

My setup:

(setq fast-but-imprecise-scrolling 't)
(setq jit-lock-defer-time 0)
(setq max-lisp-eval-depth 10000)

(setq echo-keystrokes 0.1
      inhibit-startup-screen t
      initial-major-mode 'emacs-lisp-mode
      uniquify-buffer-name-style 'forward
      mouse-yank-at-point t)

$ ssh -tx4C user@IP zsh -i
$ echo $TERM
$ emacs -nw file.txt
  • You mention "hangs", "crashes", and "suspends" which are threee very different things, so you might like to clarify which happens when.
    – Stefan
    Aug 31, 2020 at 13:03
  • This does not occur always but when it happens: I keep scroll top or bottom of the buffer even after it reach to tap/bottom than it hangs(frozen), so it does not accept any input. In same cases if I waits long enough 5 minutes it get backs to normal but all the characters I entered when it was hanged will entered in to buffer as well. I never crashes, but if the hang time is so long I kill emacs-daemon from another terminal to make it work again, but after it killed again all the characters I entered shows up in the terminal shell.
    – alper
    Aug 31, 2020 at 20:54
  • Please edit your answer rather than completing it via comments (which aren't always displayed).
    – Stefan
    Sep 1, 2020 at 1:41

2 Answers 2


Contrary to @db48x, I don't think it's due to Emacs sending wrong sequences to your terminal, but rather the other way around: those ^[OB thingies look very much like the byte-sequence normally sent by a terminal emulator when you hit some keys such as "page down".

So, you might want to look at C-h l (aka view-lossage) to see the exact bytes that Emacs received from your iTerm2 and which command it ran in response to that. Hopefully, you'll spot somewhere there something odd. E.g. I'd expect to see a "long" repetition of the same keysequence (corresponding to one step of scrolling) mapped to the same command, so any discontinuity in this repetition might point to the culprit. It might be an error in your iTerm2 or in Emacs (or in the intermediate tty code, ...).

For further investigation, we'd need to see the interesting details of the view-lossage.

  • Sorry I played with my emacs setting right now in linux it does not hangs for now. I am trying to re-generate the hang case. In linux currently I am just getting around 10 to 20 ESC O B [next-line], but it does not hanges. In mac I am getting gist.github.com/avatar-lavventura/… when I keep scroll bottom, but it does not hang just writes BOBBOBOB... into the buffer.
    – alper
    Aug 31, 2020 at 20:59
  • @alper: The lossage you link to contains weird sequences like ESC O B B and ESC O B O B which don't make much sense. I can't rule out a bug on the Emacs side, but it might also be a bug in iTerm2.
    – Stefan
    Sep 1, 2020 at 1:45
  • What would be the normal/acceptable sequence that it should have?
    – alper
    Sep 1, 2020 at 10:24
  • ESC O B is the one that is recognized as mapping to next-line. In order to see if those extra Os and Bs (or the lack of corresponding ESCs) really come erroneously from your terminal you could try to record all the bytes sent to Emacs with something like script.
    – Stefan
    Sep 1, 2020 at 12:43
  • script? is it a emacs package?
    – alper
    Sep 1, 2020 at 20:43

Sounds like Emacs is sending escape sequences that iTerm2 doesn't understand, so probably your TERM variable has the wrong value, or your terminfo database has incorrect information in it (though that's much less likely).

You would probably be happier overall if you were just running Emacs directly, rather than running it in a terminal emulator. It would eliminate all possibility of this problem happening, and Emacs will gain the ability to use all your fonts, all the colors your monitor can display, as well as images, pdfs, etc.

  • TERM returns xterm-256color. Hm using Terminal instead of` iTerm2` might help to fix it? Also the emacs I am using is in a remote machine where I am connected using ssh.
    – alper
    Aug 27, 2020 at 19:24
  • Are you setting TERM anywhere, such as your ~/.bashrc? You might be overriding the correct value that it sets for itself. You should probably consult the iTerm2 documentation to see what the value ought to be.
    – db48x
    Aug 27, 2020 at 19:28
  • Yes: in .zshrc I have export TERM="xterm-256color" and I also run emacs as: TERM=xterm-256color emacsclient -t -q file.txt . and also in .emacs file I have (require 'xterm-color); (setq compilation-environment '("TERM=xterm-256color"))
    – alper
    Aug 27, 2020 at 19:31
  • You shouldn't do any of those. Let your terminal emulator set TERM to the correct value for you. That value will propagate to all child processes, and ssh will carry it along to your remote shells as well.
    – db48x
    Aug 27, 2020 at 19:32
  • I was using Dracula theme along with emacs (i think thats why I add them all), if I don't have them the theme colors show up pretty messed up in some remote machine.
    – alper
    Aug 27, 2020 at 19:40

Your Answer

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

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