I know what is tries to do: show a highlight of the the inserted text but more often than not it just doesn´t work and I end up manually cleaning the debis away.
Can this feature be disabled?
Have you tried pasting on terminal control shift v?
That happens when you type the quote character then do the paste.
By default the quote character is ctrl-v, ctrl-v is not paste in a terminal.
You can reconfigure the keys in the terminal app and your .bash_profile if you want to avoid this. But at the cost of using non-standard keys.
You can see what the default keys are with stty -a, lnext is the quote character.
I don’t type anything, that is the point. I mark text, right-click copy, and right-click paste at the destination.
right click is ctrl+v
Is this some kind of déjà vu, or am I stuck in a time loop?
I know that I’ve read something about this a long time ago, so imagine my surprise when the two first hits were
- an ubuntu forum
- this forum, Extraneous characters when pasting text
In terminals it is Ctrl+shift+V. You can customize if you want, but it is what it is. It caught me by surprise as a beginner as well but there is no “issue” here.
That is the default in GUI programs.
But it is not the default in GUI terminal emulators like konsole as the use of Ctrl-C and Ctrl-V conflict with half a century of unix TTY use of these keys.
No it is not. Right-Click brings up the konsole menu that you can pick paste from.
Its not CTRL + V for pasting in the terminal, if you would like to change to to Ctrl+V and face many down the road later, go to Edit → Preferences → Shortcuts.
This is 100% correct within a gui. In a terminal the same thing is
Ctrl+Shift+V
Similarly copy is Ctrl+C in a gui and
Ctrl+Shift+C in a terminal.
Or as you said, highlight the text then right click → copy and right click → paste
When I do this in Konsole, the text pastes as expected without any ^[[200~.
No, because Unix terminals using Ctrl + V for “quote Verbatim” predates GUI’s and the use of that key combo, which was introduced for “Paste” by Xerox PARC in the 1970’s, but not really popularised until Apple used ⌘ Cmd + V in 1983. Then in 1990 Microsoft decided to use the same letters with Ctrl in Windows 3.
IBM CUA (1987) is the base standard that this convention is taken from for Windows I recall.
See IBM Common User Access - Wikipedia
Certainly IBMs CUA standard was involved, but it appears to have evolved over time.
for instance, the Wiki page you linked, links to the 1988 IBM doc that clearly shows “Copy” bound to F2 - I searched the text version of that and didn’t notice anything else related.
I had read elsewhere that earlier versions of Windows used another key combo from IBM’s CUA spec; namely the Ins (insert) key Modified by either Ctrl to Copy or Shift to Paste , - which notably still works to this day (on some systems at least).
It is important to note that Shift+Ins pastes from the “selection” buffer (whatever is or last was highlighted, regardless of whether Ctrl+V was typed). Or at least it should. It has been in various states of disfunction for the last several years. Middle-click should also paste from the selection buffer.
I right click and select paste:
so to answer you question this is what is done and probably cause the problem. Typing Ctrl +v does something else in a shell.
Correct. The comment by Marko was to try Ctrl +shift +v in the shell, which is the way a paste is done within a terminal window.
Whether you see the extra characters when copy+pasting depends upon where the text is copied from. I sometimes see it and mostly do not.
This may be a side effect, but its original intention was something else: it is called bracketed paste and it lets the terminal emulator signal the program that is running that the incoming text is pasted in and not typed by the user. This way, the program can choose to not react to, e.g., any newline characters in the pasted text, and thus not immediately execute multiple lines pasted into a shell running in the terminal emulator. Another usecase described in the Wikipedia page is to not autoindent pasted lines on every newline when it may already have been indented before.
If you see these control characters, it means that the terminal emulator is sending them, but the program currently running in your terminal emulator does not know what they are. I suggest you start by tracking down the combination of terminal emulator and program where this happens, and then adjust the configuration of one or the other.
This can be seen with gvim (The graphical vim versions). When you paste in something, it goes into insert mode and also turns off autoindent. With regular vim this does not occur as it is just using the paste feature of the terminal emulation.