emacs and lsst-lspdev

[kadrlica]

This is a reminder to track down the issues with emacs on lsst-lspdev. They should eventually be documented in an issue here: https://community.lsst.org/c/support/lsp

[kadrlica]

Emacs commands that fail on lsst-lspdev (please edit this comment):

• Meta - The Meta key (which is used generically for emacs commands) is usually mapped to esc and Alt (Linux)/Option (Mac OS X). On Mac OS X, the browser uses Option print a variety of non-ascii characters. For example, one of the most important emacs key combination, M-x, prints '≈'. The esc key does work as Meta on Mac. In my personal case, I've remapped the Mac Command (⌘) key to Meta for emacs, so my muscle memory keeps typing '⌘+w' to copy, which of course has the annoying effect of closing my browser tab...
• C-_ - Undo (noop)

[SimonKrughoff]

@kadrlica we definitely understand the problem with the Meta key. It's a tricky issue because it is the browser that is catching the keystroke before the terminal emulator can see it. After talking with Adam, we came up with a few (not completely satisfactory).

• Remap the offending keystrokes. I have tried this and it seems to work to keep the browser from capturing Meta-W. You don't even need to restart your browser.
• Use a browser extension like shortkeys
• Use Esc instead of Meta. I realize this is like asking you to learn a new editor, but this solution doesn't require any key binding manipulation.
• Globally remap default keybindings. For example, some emacs bindings here or here

The C-_ problem is less understandable. It should work. We can look into whether it is being caught by either the JL environment or the terminal emulator. While not ideal, I've confirmed that C-x u does run undo.

[jtmyles]

I've also been having this issue with emacs (with the Chrome browser catching up alt/option before the terminal emulator). I've heard there has been an effort to enable logging in to standard interactive login shells on the lsst-lspdev.ncsa.illinois.edu server. Is it possible to use a login shell on this server?

[athornton]

I'd like to know from whom you heard about that effort, because I hope we haven't done anything to raise false hopes about what you're likely to get. Your JupyterLab instance is running in a kubernetes-managed container, which is: a) only accessible via HTTPS routed through an external ingress, to JupyterHub, through a user-routing proxy, to an ephemeral JupyterLab container, b) whose lifecycle is managed by Kubernetes--it is created when you launch an image from the JupyterHub menu, and is destroyed when you log out of Hub (or are idle 18 hours), c) is dynamically scheduled onto an available node within the Kubernetes cluster, which does not have an Internet-routeable address, and further is on a virtual kubernetes container network, which d) is also externally-unrouteable RFC 1918 address space, and is dynamically assigned at container creation time, and e) the container has no ssh daemon running inside itself. So, if by "login shell" you mean, "can I ssh to it and run emacs in my terminal window?" the answer is going to remain "no." Yes, the environment looks like an unprivileged user login on a shared Unix system. No, it isn't really such a thing at all. We are attempting to debug why some keystrokes, such as C-_, aren't registering properly in the Terminal, but there's nothing we can do (other than suggest you change your browser bindings, or move to a workflow where you edit locally and then push your changes either with the JL Upload feature or by pushing to/pulling from GitHub) about keypress events consumed by the browser before the JupyterLab application ever sees them.

…

________________________________ From: Justin Myles <[email protected]> Sent: Friday, August 10, 2018 10:29 AM To: LSSTScienceCollaborations/StackClub Cc: Subscribed Subject: Re: [LSSTScienceCollaborations/StackClub] emacs and lsst-lspdev (#56) I've also been having this issue with emacs (with the Chrome browser catching up alt/option before the terminal emulator). I've heard there has been an effort to enable logging in to standard interactive login shells on the lsst-lspdev.ncsa.illinois.edu server. Is it possible to use a login shell on this server? - You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#56 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ACVurXbq1pxJUX8HMEak-pNWnlbBA2pHks5uPcMGgaJpZM4VOQ1L>.

[kadrlica]

To narrow the range of investigation, I think I'm going to focus on trying to get Option+w (⌥+w) to copy text. This means that the focus is:

1. Get the Mac to stop making ⌥+w = Σ
2. Get the browser to pass ⌥+w to the LSP
3. Get the LSP Emacs session to interpret ⌥+w as Meta-w

To accomplish this, I've followed @SimonKrughoff fourth bullet to globally remap the default keybindings. I've edited ~/Library/KeyBindings/DefaultKeyBinding.dict to be (where \033 is the escape code):

{
"~c" = (insertText:,"\033c");
"~v" = (insertText:,"\033v");
"~w" = (insertText:,"\033w");
}

This appears to work. It passes M-c, M-v, and M-w to the emacs session in Chrome.

[kadrlica]

I've been trying Firefox and Chrome on Linux. Firefox is a nightmare due to the Ctrl keys being mapped to various window commands. Chrome is a lot better, but it has several problems

• Cttrl+b causes the JupyterLab bookmarks bar to open an close instead of moving the cursor backwards.
• Ctrl+s doesn't appear to be passed to emacs

[kadrlica]

A positive update, C-_ is now working!