Raw escape sequences mess up Ruby 2.7 REPL

[aleksandrs-ledovskis]

Describe what happened:

Running CRuby v2.7.0 REPL in Read/write terminal of Live Share session is problematic due to large number of raw ANSI VT100 escape sequences polluting readline'ish interface. A workaround exists, which is described below.

What was your system configuration? Product and Version: Visual Studio Code, version 1.44.2 OS Version: macOS 10.13.6 Live Share Extension Version: v1.0.2048 Target Platform or Language: Ruby v2.7.0+ (irb)

Steps to Reproduce / Scenario:

1. Create Live Share session
2. Share terminal

• Problematic:
  • Read/write terminal, when shared from within same OS/new VS Code windows;
  • Read/write terminal, when shared to another OS/instance (tested in VM).
• No issues observed:
  • Read-only terminal, when shared to Online VS Code/no-install session;
  • Read-only terminal, when shared to another OS/instance (tested in VM).

3. Await connection of remote participant
4. Start irb REPL for CRuby of version v2.7.0+ (latest stable, as of date of report)
5. Write some expression (e.g., 1+1).
6. Witness that it's displayed with literal terminal escape codes, rather than colored output/plain text

Screenshots

---

• This issue is not present prior to CRuby v2.7.0 as syntax highlighting was introduced only recently (see "IRB" section in changelog)
• This issue doesn't manifest itself when run in VS Code terminal of non-shared session or when there's no remote participant
• This issue is present in both Zsh and Bash
• A workaround exists, where launching irb REPL with non-default --nomultiline flag makes it work just perfectly (colors and indentation included).

Curiously, this issue also bears some resemblance to https://github.com/moby/moby/issues/30137#issuecomment-307098844 which was(?) related to PowerShell

If there's any reason to believe that it's Ruby REPL that misbehaves, I can surely pivot and report this bug there.

/cc @aycabta

[jramsay]

@aleksandrs-ledovskis: thanks for filing this issue!

Assigning to @IlyaBiryukov for further investigation.

[IlyaBiryukov]

Live Share doesn't handle any ANSI-sequences the shared terminal may produce, we just broadcast them across the collaboration session participants. If ANSI-sequences rendering becomes broken, the only easy solution I see is to disable them in the shared terminal completely, e.g. by not setting $TERM environment variable. This will beat the purpose of syntax highlighting though, and the customer already has a better workaround for this particular case.

I don't think we'll have resources to make Live Share parse and change ANSI-sequences. Adding a configuration option to disable them in shared terminals may be the short term fix. I think it's not worth it yet, given that this issue already has a better workaround.

@BrunoGuardia I'll leave it up to you to prioritize any work here.

[aleksandrs-ledovskis]

Having looked at this issue another time, I think maybe it's a dupe of https://github.com/MicrosoftDocs/live-share/issues/3422

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed automatically in 2 days.

[derekbekoe]

We’re not able to prioritize this issue over the other higher-impact issues we receive every week, based on the votes and comments from others in the community and our understanding of the issue. We understand this may be disappointing; we've all been there, whether in this project or others we've contributed to. However, rest assured that we love your input. If you feel it deserves to stay open, then clarify your use case and contact us to let us know how severe it’s for you.