[BUG] option+enter doesn't add newline in REPL like it does in Julia at commandline

[NHDaly]

Please search existing issues to avoid duplicates.

Details

• Atom version: 1.39.1
• Julia version: v1
• OS: macOS
• Package versions:
  • Atom.jl: v0.8.7
  • Juno.jl: v0.7.0
  • julia-client: v0.9.1
  • ink: v0.10.12

Steps to reproduce

1. At the Juno REPL
2. Press optionenter
   • This should add a newline, but instead it executes the current prompt.

This can be quite annoying if you're editing a long function definition or begin ... end block, and try to add a newline in the middle. It's easy to build-up that muscle memory from working with julia in the terminal, and it's surprising when that doesn't work in Juno.

[NHDaly]

Based on some experimentation at the terminal, it looks like option+enter is maybe sending "\e\n"?

I used vim to edit my terminal command to insert the option+enter key via ctrlV + optionenter, to get this:

$ julia -i -e 'x="^[
"'
...
julia> x
"\e\n"

julia> x[1]
'\e': ASCII/Unicode U+001b (category Cc: Other, control)

[NHDaly]

Aha! And after reading about U+001b, that's apparently escape!

And yes, in fact, at the Juno REPL, you can achieve the same thing by pressing escape+enter! :) Good to know.
It would still probably be nice to support optionenter sending \e\n as well.

[NHDaly]

Handled here in Julia:
https://github.com/JuliaLang/julia/blob/f87bc8d90af508a637a4cf4c994d8d70063e0814/stdlib/REPL/src/LineEdit.jl#L2082-L2083

[NHDaly]

Per @pfitzseb: This is an upstream issue that comes from our terminal emulator: xterm.js.

Possibly relevant issues there:

• Capture ctrl/meta/shift key modifiers in "data" event. xtermjs/xterm.js#1884
• Come up with good story for custom (non-xterm) keybindings support xtermjs/xterm.js#487

Also maybe relevant, is this macOptionIsMeta option:
https://github.com/xtermjs/xterm.js/blob/4d9d6fbd8697ca1d47b8b25f9f820e965999d330/typings/xterm.d.ts#L130

There's an option for that in the julia-client, but i don't think it's related to this behavior.
The problem seems to be parsing option+enter or meta+enter as escape+enter, not whether option is treated as meta.

[pfitzseb]

X-Ref xtermjs/xterm.js#2364.

[NHDaly]

Just a heads up, on the latest release this seems to be fixed: option+enter does insert a newline, and doesn't enter the line on the REPL.

But, on my machine, option+enter is now adding two newlines, not just one. 😅 I don't really mind, that's just formatting, but just wanted to let you know.

---

EDIT: Indeed, it looks like optionenter is sending '\e\r\e\r'.

[pfitzseb]

Does the Option As Meta option change anything about this? I'm very explicitly sending a single \e\r here, so it's really weird that this is going wrong on Macs...

[pfitzseb]

The double new-line bug should be fixed in the latest release (or on master). Turns out I was listening to both key-down and key-up events... Not sure how I didn't notice that locally.

[NHDaly]

Haha cool, thanks! :) looking forward to it! 🚀

[NHDaly]

Just wanted to note that xtermjs/xterm.js#2718 was finally merged, so it's possible that you can remove whatever mac-specific hacks you had to do here?

(Also, 😬 i don't think we ever got this to be working quite right... As things stand right now, on my mac, option+enter now enters two newlines and still submits the line in the repl 😢. So maybe integrating the changes from xterm will help?)

[pfitzseb]

Oh, for real? It's been working great for me on Linux ;)

But yeah, we'll upgrade to xterm.js 4.6 once it's out.

[NHDaly]

haha yeah i know, sorry. I think it was working for a little while? And then regressed, and i never updated the issue.. Sorry! 😅

But yeah, cool, sounds good!