0

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:

^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OB^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA^[OA
[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
xterm-256color
$ emacs -nw file.txt
alper
  • 1,238
  • 11
  • 30
  • You mention "hangs", "crashes", and "suspends" which are threee very different things, so you might like to clarify which happens when. – Stefan Aug 31 '20 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 '20 at 20:54
  • Please edit your answer rather than completing it via comments (which aren't always displayed). – Stefan Sep 01 '20 at 01:41

2 Answers2

1

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.

db48x
  • 15,741
  • 1
  • 19
  • 23
  • `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 '20 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 '20 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 '20 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 '20 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 '20 at 19:40
  • Perhaps `TERM` was getting set to the wrong value on those machines, and overriding it when run ran Emacs was improving things. This is why your config files should never set `TERM`; it won't be setting it to the right value in all cases. – db48x Aug 27 '20 at 19:44
  • I also set it in `iTerm2` where Preferences => Terminal => Rport terminal type: `xterm-256color` – alper Aug 27 '20 at 22:22
  • Why would that be the right TERM setting for iTerm2? That's the terminal setting for xterm, a completely different program. Terminal emulators do try to maintain compatibility with xterm because it is (or was) ubiquitous, but there's probably some xterm feature that iTerm2 doesn't support, but which Emacs is trying to use. Find the correct setting for iTerm2, and Emacs will know that it can't use that feature because the terminfo database will tell it what it can and cannot do. – db48x Aug 28 '20 at 00:29
  • Here iterm2 doc (https://iterm2.com/documentation-one-page.html) says: `iTerm2 supports 256 color mode. To enable this for csh shells, set your terminal to xterm-256color (under Preferences > Profiles > Terminal > Report Terminal Type).` But I have not idea is it right setting or not. Some applications may need to be configured to support this mode. I see this suggestions for many other docs but not sure what is the best setting for `emacs` , do you have any idea about this? – alper Aug 28 '20 at 12:38
1

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.

Stefan
  • 26,154
  • 3
  • 46
  • 84
  • 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 https://gist.github.com/avatar-lavventura/ccdd18cf01e16f5bbd17ef59c7255f8d when I keep scroll bottom, but it does not hang just writes `BOBBOBOB...` into the buffer. – alper Aug 31 '20 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 01 '20 at 01:45
  • What would be the normal/acceptable sequence that it should have? – alper Sep 01 '20 at 10:24
  • `ESC O B` is the one that is recognized as mapping to `next-line`. In order to see if those extra `O`s and `B`s (or the lack of corresponding `ESC`s) really come erroneously from your terminal you could try to record all the bytes sent to Emacs with something like `script`. – Stefan Sep 01 '20 at 12:43
  • `script`? is it a `emacs` package? – alper Sep 01 '20 at 20:43
  • @alper: No, on my Debian machine it's provided by `bsdutils`. It might be standard in MacOS (given it has taken a fair bit of code from BSD, AFAIK). Try `man script`. – Stefan Sep 02 '20 at 00:42