-
Notifications
You must be signed in to change notification settings - Fork 888
"ctrl-v" keystrokes are not received by (n)curses apps #2588
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I'll make a bug to examine this, though I think that what you're asking for is support for VT clipboard sequences, which we don't yet support. See "Ps = 5 2 -> Manipulate Selection Data" at this link: http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Operating-System-Commands |
I am quite ignorant of pretty much everything on the page you linked, but I don't believe this issue has anything to do with VT clipboard sequences. The only way it could possibly have anything to do with the "VT clipboard sequences" which you say you don't support is if those are the only way to send ctrl-v at all. But that really isn't possible either, because as I said ctrl-v performs as expect at a bash prompt and in other, non-curses applications. I'm sure you have a much (much) better idea of what's going on than I do. I only want to stress that it's the transmission of the natural ctrl-v that is failing in ncurses applications. That keystroke is getting dropped somewhere along the way. It's really only a coincidence that ctrl-v is the key binding for "paste" in textadept. I could bind it to any other function and it still would not work. The proof of that pudding is the edit to core/keys.lua. It changes the statusbar to show any keystroke that is received by the program. This happens before that event is dispatched to take any action in textadept, whether that be to paste, show a message box, save the file, or do anything else I might choose for it to do. Thank you for your kind attention. |
Oh I see, that is curious. That definitely looks wrong to me. Should be easier to debug and fix then adding clipboard sequence support :) Thanks! |
This issue was moved to microsoft/terminal#77 |
Windows build number: Microsoft Windows [Version 10.0.16299.19]
After I upgraded to the Fall Creator's Update, I completely uninstalled and re-installed WSL and installed the new Ubuntu from the app store. This issue is not new, however. I had the same problem prior to upgrading.
Running (n)curses editors that support familiar key bindings for selecting, copying, and pasting text. The two editors I have tried are textadept and tilde. Note that at any time I reference textadept in this bug report, I am talking about textadept-curses, and not the GUI program.
In these editors, I can shift-arrow to select text and ctrl-c to copy text. However when I try to paste text using ctrl-v, nothing happens. Please understand that unlike most of the issues people are reporting about ctrl-c, ctrl-v etc. I neither care about nor want these keystrokes to integrate with the Windows clipboard. The first, last, and only thing I am trying to do is to copy and paste text within the same file and within the same editing session. These apps have their own internal "clipboard" and that is all I want to use.
Textadept is easily configurable (without recompiling) to show keystrokes it receives in its status line by uncommenting the following line in core/keys.lua:
I have done this, and it is not receiving the ctrl-v keystroke at all.
I know that it is ctrl-v, and not ctrl-c, that is the issue, because textadept allows direct entry of lua commands by hitting alt-c. If I hit alt-c and then run the command "buffer.paste", the text I previously copied (into textadept's internal clipboard) with ctrl-c is pasted. Also if I edit core/keys.lua as described above, hitting ctrl-c on my keyboard causes "cc" to show up in the status bar. In the notation that textadept uses for key bindings, the first "c" denotes control and the second denotes "c".
I have tried the micro text editor, which is also a text mode editor that supports these normal key bindings for selecting, copying, and pasting text. In micro, these key bindings work fine. The difference evidently is that micro does not use (n)curses.
All of these programs work as expected in (real) Linux -- for example, on the Linux Mint 18.2 machine next to me.
I ran strace as instructed and did a minimal editing session where I simply selected a line of text, hit ctrl-c to copy, ctrl-v to paste, and ctrl-q to quit. I don't know how helpful this will be but the (rather lengthy) strace output is here:
The text was updated successfully, but these errors were encountered: