0

I use SSH to work on a Linux computer cluster, emacs is my preferred text editor there.

My local computer is a Windows 10 machine. If I use PuTTY to access the cluster remotely, when I run emacs, it behaves as I'm used to it behaving on a cluster: it starts immediately, and CTRL+- lets you undo things.

I also have a Windows Subsystem for Linux (WSL) version of Ubuntu installed on the same machine, 18.04 LTS. When I SSH into the same cluster and open emacs, it behaves differently: it takes about 4 seconds to start up, and CTRL+SHIFT+- lets you undo things.

It was my impression that when I'm running emacs on a remote system, it is the remote system's emacs executable that runs, and it configures itself with various files also from the remote computer, not from my local machine. But clearly some of my local settings are bleeding over into the remote emacs, since it runs differently depending on whether I access the cluster via PuTTY or SSH-via-Linux-subsystem.

Any advice on what it is on my local machine that affects the remote running of emacs?

Whatever it is, I don't think that it is specific to the cluster, since this behavior is repeatable on two different clusters (emacs 23.1.1, Linux 2.6.32-696.20.1.el6.x86_64; the other emacs 24.3.1, Linux 3.10.0-514.16.1.el7.x86_64) and on the Google Cloud Platform (emacs 24.3.1, Linux 3.10.0-957.27.2.el7.x86_64). The behavior is the same whether or not emacs is installed on the local WSL kernel. Presumably it's still something to do with WSL, though, but I don't know enough about how emacs works to be able to troubleshoot at that end. So any help about what to look for would be greatly appreciated.

Improve this question

1 Answer 1

Reset to default
1

W.r.t the 4s delay, you should probably look at the $TERM env-var (e.g. with echo "$TERM" run from the same shell from which you start emacs) and then try and look at the corresponding terminal-init-<termname> function. My crystal ball suggests the delay is linked to xterm-extra-capabilities.

Regarding the difference in key-binding, the difference is presumably due to the terminal emulators used, again: use C-h l to see what sequence of characters it receives from the terminal emulator. You'll likely see that Emacs doesn't receive the same char sequence when you hit the C-- key in PuTTY as when you hit it into the terminal emulator used for WSL.

Improve this answer
2
  • Thanks, your crystal ball was right on. Should anybody else run into this problem, adding (setq xterm-extra-capabilities nil) to my .emacs file eliminated the long load time.
    – Jack Boyle
    Oct 22, 2019 at 18:37
  • IIRC, that issue typically arises when you are setting TERM to be some xterm* value when it actually isn't one? This workaround might well be fine in practice, but there may also be a more accurate TERM value you could use instead.
    – phils
    Oct 22, 2019 at 19:01

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.