Ignore unknown or unimplemented escape sequence input

[tompng]

Description

Some other REPL ignores unknown escape sequence such as

\e🐔
\e[🐧
\eO🐣
\e[1🐦
\e[2;3🐤
# node ignores it all. python and php beep sound in some of these.
# to input, type esc + paste quickly

When you input these escape sequence, IRB will insert it into input buffer and displayed in screen.

Here are other examples irb does not handle and displays escape sequence. (I tried in Mac Terminal.app)
option+up option+down option+[aeghijkmoqrsvyzAEGHIJKMOQRSTVYZ!@#$%... and more] ctrl+o ctrl+w f1 ~ f12 option + f1 ~ option + f12

We cannot implement every existing escape sequence input right now, so we first need to ignore these unknown or unimplemented escape sequence input.

[sshock]

I like the idea of having reline ignore keys that it doesn't have an action for rather than allow them to spew out ugly escape codes.

This is very important for PgUp, PgDn, and Insert, which are very common keys present on most keyboards (well, PC keyboards at least), and which are physically located close to other keys that are actually used (Delete, Home, and End).

I have a PR to ignore PgUp and PgDn here.

The next most important might be the function keys, though it is less likely for someone to hit those on accident or to think they might do something. Nevertheless, it seems like it could be good to ignore them. They can be ignored in the exact same fashion as how PgUp and PgDn are ignored in that PR, by mapping kf1, kf2, etc to :ed_ignore (or :ed_unassigned).

The ctrl+whatever key combinations actions are defined in the emacs.rb, vi_insert.rb, and vi_command.rb key actor files at the top (^A, ^B, ^C, etc.). Many of them are already being mapped to useful and appropriate actions that behave properly for emacs or vi mode. For example, ctrl+w maps to :em_kill_region in emacs mode and :ed_delete_prev_word in vi mode. Some of these map to :ed_unassigned or :ed_ignore, both of which should cause it to be ignored. Any changes to these mappings should be discussed on a case by case basis using arguments that the current mapping is broken / incorrect / doesn't match emacs/vi behavior.

The alt+whatever and ctrl+alt+whatever key combinations mappings to actions are also defined in emacs.rb, vi_insert.rb, and vi_command.rb. Most of these map to :ed_unassigned, which should cause them to be ignored.

The option+whatever on Mac is a little weird because depending on your settings it doesn't really send an alt keycode like the alt key does on a PC. Instead Mac turns those into all kinds of fun special characters, as explained here. Honestly, I don't think reline should or even can do anything about those. Mac is literally changing those into special Unicode characters so that is what you'll get.

Finally, you have these interesting escape sequences that @tompng shared:

\e🐔
\e[🐧
\eO🐣
\e[1🐦
\e[2;3🐤

These are very strange to me and I don't think we should try to ignore them without an actual explanation for where they come from, what they represent, and how they are produced. I'm not aware of any key combination on any keyboard that produces escape sequences like that.

This issue needs to focus on "which keys and key combinations should be ignored", not "what random escape sequences should be ignored".

[tompng]

The escape sequence \e🐔 \e[🐧 are an example of

• Not defined in any specification
• But some other REPL handles (ignores) it

I don't think we should try to ignore them without an actual explanation for where they come from

I know that there are various of opinion about it.
But in my opinion, IRB can implement to ignore it. It's not strange to ignore it because there are other real tools that decided and implemented to ignore it, and actually has a benefit.

[sshock]

I know that there are various of opinion about it. But in my opinion, IRB can implement to ignore it. It's not strange to ignore it because there are other real tools that decided and implemented to ignore it, and actually has a benefit.

If you can point to the exact source code for some tools where these exist with comments (or commit comments) explaining why they were added, and if those comments explain what special keys or key combinations produce them, then I think you'll have more luck getting the reline maintainers to agree to add code to ignore them.

[st0012]

But in my opinion, IRB can implement to ignore it. It's not strange to ignore it because there are other real tools that decided and implemented to ignore it, and actually has a benefit.

I agree with the ignore by default approach. If we haven't handled certain escape sequences, it doesn't help printing weird characters anyway. But since you mentioned that IRB can implement it, do we want to move the issue there? Or we need to first implement some APIs in reline?

I think you'll have more luck getting the reline maintainers to agree to add code to ignore them.

FWIW, @tompng is one of the maintainers of reline 🙂

[sshock]

FWIW, @tompng is one of the maintainers of reline slightly_smiling_face

Well, I feel pretty silly now.

[sshock]

@tompng after looking at #522, I think I understand this a lot better now.

For anyone who is curious, this is why I got confused:

• It was not clear to me that the idea was to dynamically ignore all escape sequences with a known pattern like CSI and SS3 sequences.
• It was not clear to me that the funny list with emojis was just a short list of examples (with no specific meaning) that could be used to test the dynamic matching.

So yeah, my bad, and I am really glad to know that CSI and SS3 escape sequences were designed in such a way that they follow a pattern such that without knowing every escape sequence, you can still know when an escape sequence ends.