Document copy/paste shortcuts in terminal

[timothyclemansinsea]

Triage summary: Document the various keyboard shortcut idiosyncracies for cutting/pasting into the terminal.

Or even better? Implement William's method noted at #1146 (comment)

---

Original title: Make copy/paste work in terminal

I just started using Jupyter Lab. In SageMathCloud terminals one can copy paste with ctrl-c/ctrl-v. Ctrl-c is copy if text is selected. I just tried to copy and paste and couldn't at all.

[blink1073]

Hi @timothyclemansinsea, can you describe your setup? Using the latest development branch on OSX 10.11 in Firefox and Chrome I am able to do what you are describing.

[timothyclemansinsea]

@blink1073 I'm using Chrome on Windows. Seems I can copy using right click but not paste.

[blink1073]

Is your notebook server running on a POSIX machine, or do you have terminals working natively on Windows?

[buddiex]

I still can't copy/paste on the terminal.
my note book is serving from a Linux server.
Right clicking gives only the option "Refresh Terminal" no other options to paste or copy.
and keyboard shortcuts don't work.

[blink1073]

Hi @buddiex, you can get the system right click menu by using shift+right click.

[apcamargo]

I can't copy/paste with the keyboard shortcuts either

[FinLouarn]

I can't copy paste with ctrl+c/ctrl+v (Ubuntu 16.04 on local laptop, Firefox 55.0.2)

[blink1073]

Ah, I think the issue is that Ctrl+C is typically used in Unix to interrupt a process in the terminal.

[keheyndr]

True, but what normally works is Shift+Insert to paste. And as a matter of fact, that does work.

What is missing for a full (quick) terminal experience is that selecting text using your mouse automatically copies text to the clipboard.

[qingpeng]

shift + insert works for windows, but what if I am . using Mac? where is the Insert key?

[allenyllee]

My Firefox 59.0.2 doesn't have copy/paste items in context menu when triggering shift + right click.
But keyboard shortcut Shift + Insert works.
Also, Ctrl+Insert copy selected text to clipboard.

[qingpeng]

Interesting. On my Mac, Chrome, I can use command+c and command+v to copy and paste, as normal.

[danijel3]

Typically copying pasting into and from a GUI terminal in Linux is done using "shift-ctr-c" and "shift-ctrl-v". I think that would be a great addition to the jupyter terminal as well. Is it possible to configure keyboard shortcuts on your own?

[dennisobrien]

In Chrome 65.0.3325.181 on Ubuntu/Linux ctrl+shift+c brings up the Chrome developer tools. And ctrl+c is sent to the terminal as terminate signal. Right clicking the text only displays "Refresh Terminal" in the context menu.

The browser menu Edit -> Copy will copy the text successfully.

Probably the ideal fix would be to include copy and paste in the right click context menu. I like the suggestion from @danijel3 to allow customizing the copy/paste, but honestly I would probably not remember yet another copy/paste shortcut.

[Honghe]

JupyterLab terminal copy/paste shortcut key based on the server side we connect. Such as:

• server side is Windows 10, then the terminal connects to PowerShell, copy/paste is ctrl+c/ctrl+v.
• server side is Ubuntu, then the terminal connects to our set bash/zsh, copy/paste is ctrl+shift+c(conflict with Jupyter Lab Command Tab hotkey)/ctrl+shift+v.

[jasongrout]

I suggest we verify the note above (#1146 (comment)) and add it to the documentation to explain the shortcuts, and then close this issue.

[nfultz]

That seems a little unusual, I would have expected it to match the client OS shortcuts, eg whatever the web browser is running on, not the remote server.

[jasongrout]

@williamstein investigated this behavior of xterm in depth and proposed a solution he uses in cocalc with term.js: https://groups.google.com/d/msg/jupyter/3t1WEY_FFEg/b-NbW3rNCAAJ

[jasongrout]

VSCode documents the different shortcuts: https://code.visualstudio.com/docs/editor/integrated-terminal#_copy-paste

[tgeorgeux]

The way I see it we have two issues:

1. An education issue about how to access the browser context menu.
2. A conflict with Linux machines.

@jasongrout One thing I didn't pick up from William's comments, was how feasible will it be to accomplish what he's done in term.js? I think his solution is quite good.

If it's not feasible to integrate what he's proposed, we can add both accel-c/v and accel-shift-c/v as defaults for copy in the terminal.

Either of these solutions address the second issue but not the first.

[williamstein]

@jasongrout One thing I didn't pick up from William's comments, was how feasible will it be to accomplish what he's done in term.js? I think his solution is quite good.

I didn't know how feasible it was until I did it. It turns out this is one place where xterm.js's public API works really well. Here's basically all you have to do:

    terminal.attachCustomKeyEventHandler(event => {
      if (
        (event.ctrlKey || event.metaKey) &&
        event.key === "c" &&
        terminal.hasSelection()
      ) {
        // Return so that the usual OS copy happens
        // instead of interrupt signal.
        return false;
      }

      if ((event.ctrlKey || event.metaKey) && event.key === "v") {
        // Return so that the usual paste happens.
        return false;
      }

      return true;
    });

I looked up who has been doing the most work on xterm.js recently, and it's https://github.com/Tyriar (@Tyriar); he just happens to be at some local company near me called Microsoft, so I'm meeting with him there tomorrow (Wed, Oct 3)...

[williamstein]

Regarding

1. An education issue about how to access the browser context menu.

There could possibly be some subtlety with that. The problem is that at least in some configurations of xterm.js on some browsers, the context menu doesn't appear at all. For example, xterm.js integration is now live in https://cocalc.com, and when I use it via my Chromebook (using ChromeOS stable channel), I do NOT see the context menu. See screenshot below. This may have to do with using the canvas renderer instead of the DOM renderer. I ended up going with the canvas render, since measuring the size is very robust, and scrollback works perfectly, and copy selection also works perfectly (these are all pretty broken with the DOM renderer for me).

In any case, when documenting/education about the context menu, be sure to point out "this might not work for you", if that's the case.

[Tyriar]

Yes, Terminal.attachCustomKeyEventHandler was added to allow people to intercept any key they want before it's evaluated by xterm.js.

[fonnesbeck]

In Chrome (v70), the edit menu does not allow you to copy/paste with the Terminal. In fact, the entire pull down menu is greyed out.

[Tyriar]

@fonnesbeck I checked the xterm.js demo and it seems to work fine, so this must be a problem with jupyter (maybe CSS changes are missing?)

[jasongrout]

Thinking a bit more about William's suggestion above:

I think having ctrl-c depend on whether text is selected or not is brilliant. +1.

There is a terminal interpretation for ctrl-v, which is to treat the next character literally (e.g., pressing ctrl-v ctrl-h inserts a literal ctrl-h in the text, instead of actually interpreting it and doing a backspace). I only use this occasionally, usually when searching for ^M line endings in vim, and most people probably never use it. However, there may be some people who complain if ctrl-v suddenly pastes instead of doing the standard terminal thing.

[williamstein]

I think having ctrl-c depend on whether text is selected or not is brilliant. +1.

:-)

There is a terminal interpretation for ctrl-v,

I didn't know about that -- thanks for pointing it out.

[...] there may be some people who complain if ctrl-v...

As a data point, no cocalc users have complained about this yet, so the "some people" might be pretty small. In what context is it important to be able to insert a literal ctrl-h in text? It might be a situation that is highly unlikely to come up when using a web-based terminal in the context of JupyterLab.

[tgeorgeux]

I don't think it hurts to go forward with the contextual use of ctrl-v as discussed above. If it's causing a problem we can either roll back the change, or offer a setting to disable it.

It's hard to tell which use case is more common without any data on the topic, but I think merging and iterating is acceptable in this case. Thoughts @jasongrout ?

[jasongrout]

@ivanov also points out that, in addition to inserting characters, ctrl-v is used in vi to enter block select (http://vimdoc.sourceforge.net/htmldoc/visual.html). He said he uses the context menu or application menu to paste outside text into a terminal.

Also, ctrl-v is used for scrolling in emacs, and used in other command sequences as well. There is a cua-mode for emacs that changes ctrl-v to paste, though.

So I think if we do make ctrl-v paste, we should have a setting to disable it.

[Tyriar]

Typically only Windows terminals use ctrl+v to paste, on Linux most use ctrl+shift+v.

[oudarjya718]

ctrl + shift + v isnt also working

[saulshanabrook]

Summary from meeting

Different copy and paste shortcuts for the terminal on Windows, Mac OS, Linux. Someone on here did a survey of the different versions.

We could change how we do copy paste in the terminal or we could document what is there to make it clear how it works on the different operating systems.

The first step would be to verify on each platform what the copy paste shortcut is. This has to do with the server platform possibly not the client. Then we can decide whether to change these or just document what we have.

William's workaround is that if we have selected text and you hit CTRL C in unix, then you intercept it.

1. Document what we have for 1.0. (Every combination of client and server, with the two windows shell).
2. Implement William Stein's workaround for 1.1

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related discussion.