Hyper: Copying text highlighted text copies background shell but not from vim

[garyx]

OS: Ubuntu 17.10
Hyper.app version: 2.1.1
hyper.js https://gist.github.com/garyx/a6f42942ce64c94f1012a95dc74313e4

I just installed 2.1.1 and I was going through my usual workflow and needed to copy some text from a file. So I opened the file in vim, highlighted what I needed and pressed ctrl+shift+c. Then when I paste the text it seems the text in the clipboard is equivilant to the shell that was in the same area before opening vim.

Copying from the shell itself works ok it seems. But not from vim for some reason, seems to be a focus issue. This seems to happen in vanilla setup without any plugins enabled.

[garyx]

I did some more testing, this is an issue in 2.1.0 and 2.0.4 as well but not in 1.4.8.

[keichinger]

I can confirm the same issues with less. Freshly installed 2.1.1 from 1.4.8.

[keichinger]

@rauchg @leo Is there anything we can do to help getting this issue resolved? Providing logs or anything like this?

[soleera]

Same issue with neovim; as soon as the window looses focus the text is deselected.

[asbjornenge]

I'm seeing the same on MacOS with 2.1.1 😕

[garyx]

Just installed to test the new 2.0.0 Canary 8 and this is an issue there as well. This is very easy to reproduce, is someone not experiencing this as an issue?

[insanityfarm]

Also seeing this on macOS. When I switched to Canary a few big issues were fixed for me, but copy-paste was rendered nearly useless. For me this is a very high-priority issue.

[albinekb]

Edit: It looks like VS Code is using xterm3, which is more or less a complete rewrite with canvas rendering and a special overlay that proxies the clipboard stuff (afaik). So it could be an issue that's in xterm2, needs more digging.

---

I can reproduce this issue with the latest 2.0.0-canary.8 release, but in VS Code (which uses the same rendering lib for the terminal part, xterm.js) this issue does not exist.

to reproduce:
$ less <any text file>
and copy the text shown, this will give you the contents of the text that was present before running less

That makes me think it's an easy fix, but we need to find why/where it goes wrong. @chabou do you have any idea what the issue could be? 🤔

[albinekb]

Ok, after more digging it looks like I found the source of the issue. It was introduced somewhere between xterm 2.8 and xterm 2.9 https://github.com/xtermjs/xterm.js/issues/1049

Looks like we have these options:

Upgrade to xterm 3

pros

• Canvas rendering 😍
• Clipboard fixed
• Xterm 3 is in active development, will only get better and better

cons

• We will need to mark transparency/vibrancy as a regression since it's not possible to support that currently with xterm 3 due to how the canvas rendering works with a pre-baked character map (for performance reasons)

Revert to working xterm version (2.8.x)

pros

• Clipboard will work
• Transparency will work

cons

• we lose tons of bugfixes and improvements

Fix the issue in xterm 2.9.x

pros

• We get to keep transparency
• Clipboard issue will be solved
• We get to keep all the great bugfixes and improvements

cons

• Someone that knows how xterm works need to fix this, or someone need to get familiar with the codebase and fix it

---

Personally I vote for xterm 3, we only support transparency in macOS, and I prioritize function over form. It not an easy task to make transparency work with xterm 3, and since most users won't need it, it's not high on their priority list.

[bgw]

As a workaround, I have a plugin that will monkey-patch this, along with some other selection-related bugs in xterm.js 2.9.2. All of these bugs have been fixed in xterm 3.x.

The plugin: https://github.com/bgw/hyper-shift-select

The fix for this bug would require a single-line change in xterm.js. I'd be happy to submit a patch to xterm.js, but I get the impression that they're not interested in cutting another 2.x release, and I'd personally like to see hyper switch to xterm 3.x sooner rather than later.

[albinekb]

That sounds reasonable @bgw. @chabou have solved the initial worries with the transparency (by re-rendering the font atlas with transparency when you change to transparent colors), this is done to not slow down rendering for non-transparent terminals (transparency+canvas makes it slower)

so it's on track to be shipped as soon as we roll out the kinks and regressions that have been introduced in this huge refactor.

[garyx]

I just tested the new 2.0.0-Canary.9 and I am glad to say that this copy/paste issue seems to be resolved for me in this new release with the new xterm. It would be good to get other here that ran into this issue to download the newest and confirm here as well.

[bmihelac]

Confirming, 2.0.0-Canary.9 does not have this issue.

[LabhanshAgrawal]

Closing as https://github.com/xtermjs/xterm.js/issues/1049 is closed, we're on latest xterm and it's not reproducing on testing with latest canary builds.
Feel free to open a new issue if face any problems