Xterm.js: Improve tmux support

[Tyriar]

Originally reported https://github.com/Microsoft/vscode/issues/18182 from @elithrar:

• VSCode Version: Version 1.8.1 (1.8.1)
• OS Version: OS X 10.11.6

Summary: Highlighting text between tmux splits, and scrolling within tmux, does not work reliably when using the native terminal vs. (e.g.) iTerm2. Mouse support (clicking between splits) is also not supported.

Steps to Reproduce:

1. Have tmux running inside your shell
2. Open a split (prefix + %)
3. Try to highlight text within a split with the mouse (ends up crossing splits, and putting them both into 'normal' mode)
4. Try to scroll within a split, or use PgUp, and it breaks the tmux history.

[Tyriar]

@elithrar are you expecting the selection to only select text in one of the splits? gnome-terminal doesn't seem to do that.

Scrolling seems fine from what I can see, I don't typically use tmux though so you could give exact steps? This is what I was doing:

1. tmux
2. ^B %
3. Page up
   4 Page down
4. Up arrow
5. Down arrow

[elithrar]

"As is" on iTerm2 (not in selection mode): just selecting w/ mouse within a split doesn't bleed across splits):

---

prefix + pgup/pgdn within a split -> does not impact the other split.

Hope that's clear.

[Tyriar]

Thanks, that's super useful :smiley:

[elithrar]

Also @Tyriar - Hyper appears to handle this as expected, so there may be some approaches that xterm.js can look to emulate.

[leonfs]

I think running tmux within vscode termina;, I think it's a great way to enhance the terminal experience within VS Code but I also found the issues mentioned above. I'm happy to help to fix those issues.

[Tyriar]

@leonfs I'm curious how iterm2 does the split. If you have ideas on how they determine when the buffer should be split that would be good. If the terminal does get told to split its buffer somehow like this, actualy doing it would probably be non-trivial.

I also couldn't repro the page up/down thing also.

[wclr]

btw why VS code doesn't take ala VIM's approach to splited winodws, where any window could be filled with any content needed, for example terminal could be placed in any window, then need in terminal multiplexers would be much less (like it is for example in neovim, which has build-in terminal).

[Tyriar]

@whitecolor the terminal in VS Code is contained within a panel which right now must be attached to the bottom and there can only be one. The main reason I'm not particularly for this is because the terminal keybindings/commands need to be reworked and would be a lot less consistent (what does it mean to toggle the terminal). While putting them in editors may seem simpler to some power users, I don't think it would benefit the wider user base.

We need to wait for panel position configurability https://github.com/Microsoft/vscode/issues/2806 and terminal splitting https://github.com/Microsoft/vscode/issues/7504 for movement on this sort of thing.

[mofux]

I wonder if this is related to the following problem 🤔

xterm.js
HTML content is selected, no matter if the app supports mouse integration

hyper/hterm
hterm seems to disable HTML content selection if the app supports mouse integration

Steps to reproduce:

• open a file in vim vim file.txt
• try to select some text, you will get the html selection in both, hyper and xterm
• type :set mouse=a to enable mouse support
• try to select again, hyper will disable the html selection, xterm will still do it

[Tyriar]

Very likely that's the reason.

[parisk]

If this is true, I am curious if we could hack the clipboard mechanism even more in order to let the user copy what is selected in the back-end terminal.

[Tyriar]

This is related to, but not necessarily blocked by https://github.com/sourcelair/xterm.js/issues/207

[Tyriar]

Fixed in https://github.com/sourcelair/xterm.js/pull/670