E-key acting as backspace


OK, very new to Atom. We have installed it to a debian 8.4 system using:

wget https://atom.io/download/deb -O atom.deb
$ sudo dpkg -i atom.deb

On a mac, using Xquartz, I run an ssh -X terminal and bring up Atom on the Mac screen. And the e-key is backspace! If I used the keybinding resolver it says the e-key is bound to core:backspace body and a file ending in linux.cson. Of course, in the file core:backspace says it is bound to backspace. Looks like a terminal issue but the terminal works fine, emacs through the terminal works fine, but atom does this odd binding.

Any ideas?



Sounds like some sort of weirdness in that Atom can’t properly detect your keyboard layout because of the X terminal. You may want to try to use the beta version and see if some of the Linux changes we’ve been making will help.


Well, for what it is worth I did do the upgrade to 1.13.0-beta8 without any change. It must be something to do with XQuartz but I haven’t figure it out yet. I run the same setup on the same mac but through a Windows 10 VM using MobaXTerm and it works fine.

I’ll dig further. Any help appreciated.



I am seeing the same problem. It is driving me absolutely nuts. In my case, I’ve:

  1. Created an Ubuntu VirtualBox session running under Vagrant. Atom is installed here.
  2. Configured the vagrant session such that X11 forwarding is enabled.
  3. Run the vagrant session on my Mac using XQuartz.

I have done a number of tests on this problem. If I open other X11 programs running on vagrant, the keybinding works just fine. The only X11 program with the problem seems to be atom. Additionally, if I start an X session on the ubuntu vagrant session, the e-key binding works just fine. This really looks like a problem with atom+xquartz.

As was described above, the keybinding resolver shows the e-key as being backspace. I am able to cut and past “e” values into atom.

I have the problem with 1.12.7 and 1.13.0-beta8.


Same problem with 1.11.2, so it is not a new problem.


I had some concern that the problem may be between electron and XQuartz. I picked another electron program (hyper) and demonstrated a similar problem. In this case the e-key seems to get mapped to “r”.


I’ve confirmed the problem with Brave, another Electron app. e-key gets mapped to r.


Using centos, debian, and ubuntu as the host OS causes the same problem. With centos, atom maps the e-key to “r”.


I have been experiencing this problem for awhile (since September at least) as well.

FWIW, I don’t recall hitting this Issue when I first switched to using Atom as my primary editor early last year, but I use my Mac remotely to Linux somewhat infrequently.


I am experiencing the problem as well. Even after updating to the latest version of Atom on my Ubuntu machine.


I am experiencing the same problem. Without the e key, I can’t use atom on a remote linux server through XQuartz.

Atom : 1.15.0
Electron: 1.3.13
Chrome : 52.0.2743.82
Node : 6.5.0



Same problem on Ubuntu 16.04 tunneling through XQuartz.

Atom : 1.16.0
Electron: 1.3.13
Chrome : 52.0.2743.82
Node : 6.5.0

uname -r


Has anyone created a ticket for this? I have researched it a little and it appears to have been introduced in 1.12.0-beta2. The beta1 code works fine. The beta2 release notes indicate that beta2 was to fix an issue with core:backspace when used with the numlock key, so it seems to reason, that that change is what broke the e-key on linux when using XQuartz.

I’ve diffed the source trees for beta1 and beta2 and the only difference is to the version, of course, and the atom-keymap went from 7.0.3 to 7.0.5 in the package.json file. So, I think this problem was introduced in atom-keymap 7.0.5. I’ve diffed 7.0.3 and 7.0.5, but there are a ton of changes. I’m not familiar with the code at all, so it would be very difficult for me to spot the problem. I didn’t see anything obvious, like a mapping for ‘e’ to ‘backspace’.


This is an issue the continues to plague anyone running Xquartz on mac. Recently I had a number of class students using x2go (remote linux desktop) through a server, to save them from having to do any local installations. If you run atom under x2go through a mac, same error: e is backspace.

@arandrea pointed out that it must be in atom-keymap. Has anyone looked at this yet? The version is now at 8.2.4 so someone is, but the issue remains unaddressed.



This has not been addressed to my knowledge. We did add the public keystroke resolver API. You can see an example of it being used in the flight manual. Using this we might be able to work around the problem.

I can help write the function if you want but I have some questions :zap:

  • If you open the keybinding resolver and press e does it resolve as backspace bound to core:backspace?
  • Can you give the the full output if you run the following in the developer tools console and press e:
document.addEventListener('keydown', e => console.log(e), true)
  • Do you see the same problem (Same event logged to the console) in chrome or other Electron apps? I want to know if it’s a problem in atom-keymap or in chrome.

I realize after typing the questions out that they have already been answered except logging the event. But it wold be great if you could take a look again in the most recent version of Atom (Stable or beta doesn’t matter) :bowing_man: Because if this is a bug in atom-keymap it would be great if we could get this logged in an issue so we can take a look at it :sparkles:


Looking at this I think the problem is that the event has KeyboardEvent.code set to Backspace and KeyboardEvent.key is e or E.

If that is the case then adding something like this in the init.coffee file should work:

atom.keymaps.addKeystrokeResolver ({keystroke, event}) ->
  if event.code is 'Backspace' and (event.key is 'e' or event.key is 'E')
    keystroke.replace('backspace', 'e')

If chrome has the same problem where KeyboardEvent.code is Backspace if you run chrome using x2go or Xquartz you should open an issue for it on their repository.

It would be great if we could remove that workaround we added to Atom that resolves using KeyboardEvent.code because it causes other problems that we have recently discovered. I am going to write an issue for this on the atom-keymap repository.


As they say in the movies, “You sir are a steely eyed missile man” . The init.coffee indeed fixed the problem.

For those not in the know, place the code @Ben3eeE suggest in a file called init.coffee in the ~/.atom directory. I tried this off of an Ubuntu 16.04 box running 1.20.0 atom on OSX 10.11 (El Capitain) using XQuartz 2.7.11 (the latest release I am aware of) and it works. Without the file, the same problem exists (e -> backspace).

Thus it appears it is the KeyboardEvent.code causing the problem. Thanks for the help and for pushing it as an issue. First helpful response since Dec last year.

An Addition: I had not previously tried Chrome, but given the suggestion I downloaded it and can run google-chrome-stable from my Ubuntu box to OSX without difficulty. So it appears the problem is limited to Atom.



I will update in this thread when I have posted the issue so that you, or any other users affected by this issue, can subscribe there for updates.

Did you check the value of KeyboardEvent.code in the Chrome dev tools? It may be that they resolve the key differently from us but still send the incorrect KeyboardEvent.code in the event. If the KeyboardEvent.code is correct on the latest stable version of Chrome then it has likely been fixed already and the fix has not yet reached us. I believe our version of Electron is using Chrome 56.

I’ll try to figure out these tools to see if I can reproduce the issue locally when trying to resolve the issue in atom-keymap.



I posted an issue on atom-keymap about this just now.


@Ben3eeE - thanks for directing me here! So I see above code was for a simliar issue I’m having with atom not interpreting key correctly through VNC… in the example above how do I know what the event.code value should be… assumption is that it should be ‘space’?? What is value for event key for key? Where can I find that information? Thanks again!