hyper: Pasting into nano removes line breaks

I’m still working at debugging this via the xterm.js demo. There are a decent amount of paste issues on both xterm.js and vscode (which forked xterm.js I believe). It just seems like the issue is deeper than this client which is built on top of xterm and electron but hopefully I’ll have it solved by tomorrow.

Edit: Just an update

I was able to fix this with a modification to xterm.js - however I don’t fully understand why it works thus I’m trying to test some things on windows/ubuntu/osx which is taking me a while.

The closest to an explanation is this jediterm issue which explains that newlines should be sent to a terminal via the \r aka ^M character. This can be shown via showkey in any terminal. The issue then is that pasted strings containing newlines send the \n aka ^J which causes weird behavior.

Hopefully I’ll have a better understanding of the issue tomorrow and some tests to make sure the fix works as expected.

Alright - more reading and I finally understand the issue.

In short: The fix is to translate \n to \r as @menzow initially described. I will open a PR in xterm.js.

note Hyper uses a fork of xterm.js which will need to pull in the fix when it’s merged.

In case you want to understand what’s going on:

This seems to be a bug in any terminal program which doesn’t implement bracketed paste mode (or properly implement it in the case of joe). As noted in this nano bug other editors which don’t paste properly include joe and dit. You’ll notice when you paste with newlines, each of the above editors interprets \n aka ^J to a function. e.g. nano follows pico, and pico decided ^J (ctrl+j) should be used to justify content. Programs without bracketed paste mode may still behave properly in the case of newlines because, similar to emacs, ^J will be mapped to a newline character as expected.

I just experienced this as well.

If I change the files newline option from LF to CRLF I get a different result.

Let’s use the following text as an example;

DB=true
DB_ADAPTER=mysql
DB_HOST=localhost
DB_USERNAME=vagrant
DB_PASSWORD=secret
DB_DATABASE=aware
DB_PORT=3306
DB_CHARSET=utf8
DB_COLLATION=utf8_swedish_ci

If the file is set with LF I get the following result when pasting my text;

DB=true DB_ADAPTER=mysql DB_HOST=localhost DB_USERNAME=vagrant DB_PASSWORD=secret DB_DATABASE=aware DB_PORT=3306 DB_CHARSET=utf8
DB_COLLATION=utf8_swedish_ci

If I then change to CRLF I get the following result;

DB=true

DB_ADAPTER=mysql

DB_HOST=localhost

DB_USERNAME=vagrant

DB_PASSWORD=secret

DB_DATABASE=aware

DB_PORT=3306

DB_CHARSET=utf8

DB_COLLATION=utf8_swedish_ci

None are correct. But this may point someone in the right direction when debugging this issue.

macOS Sierra:

Menu --> Edit --> Paste seems to resolve this (not ideal, but hey it works)

@Scukerman Thank you for your up 😃

@olsonpm Sorry I haven’t seen your question. I will merge your xterm PR in my fork ASAP.

Does anyone care about this issue? We could celebrate a year of inactivity in a couple of months.

It has already been merged in my used fork: https://github.com/chabou/xterm.js/commit/855964fbe10099410edb6dc85ed6b7940130649c

I tried to reproduce without any success. Can anybody confirm me that it has been fixed in our last canary (v2.0.0-canary.16)?

@Scukerman thank you for your feedback. I’m using zsh too and I can’t reproduce 😦

Can you try to reproduce on v2 available on canary update channel?

@Scukerman In any case, PRs are very welcome.

A good example of this is pasting a certificate (in PEM format). It seems it ignores newlines until the content would overflow and then it honours them.