Vim paste totally screwed up.

Evil_Hamster · 2023-01-06 23:42:08

Hi all.

Not sure if this is the right place, but my vim paste is totally screwed up.

My Spec:
Arch Linux with 6.1.2-arch1-1 Kernel
Alacritty Terminal
Fish shill

My Problem:
When I paste, using CTRL+SHIFT+V, the output is not the same as input.
For example, when I copy "Which", it pasts as "Ch".
"Hi" gets pasted as empty string.
"Post new topic" was pasted as "Nstalled <New Line>St new topic"
(I should point out, that I had copied "Installed at some time in the past before..)".

What I have tried:
I used ":set paste" to go to paste mode in vim.
I moved my .vim folder to .b.vim.
I moved my .config/alacritty folder .config/b.alacritty.
I move my .bashrc and .bash_profile to b.[name].
I typed bash to work from the bash shell rather than fish.
I also tried pasting from the primary clipboard (middle mouse button).
(This did work on xterm in vim! so maybe it has something to do with alacritty?)
However, in alacritty itself, pasting works perfectly fine.

I should also say, that it used to be working not long ago. I do not know, what got screwed up, not precisely when. At some point, I realised that things really did not want to paste properly any more.

Anyone got any ideas?
Cheers.

Trilby · 2023-01-07 00:08:49

I don't know what Ctrl+Shift+V is bound to exactly, but the symptoms are clear: vim needs to be put into insert mode prior to that running as the results you descibe fit with sending all those characters from normal mode.

Evil_Hamster · 2023-01-07 00:24:20

Thank you for your reply.

Unfortunately, as I had already mentioned, I tried that. Sadly, no dice.

cfr · 2023-01-07 00:47:30

Evil_Hamster wrote:

Unfortunately, as I had already mentioned, I tried that.

Perhaps I'm just missing something, but I don't see where you mentioned that?

Edit: Fwiw, ctrl+shift+v has never worked for me in KDE's konsole. However, creating an alternative shortcut and using that does work.

Last edited by cfr (2023-01-07 00:49:31)

just4arch · 2023-01-07 01:41:16

I had this problem when using putty and TERM=putty-256color - neither right click paste nor shift + insert worked (it produced garbled output).
The latest update of ncurses caused this for me.
You can try "TERM=xterm vim ..." to check if this is the same cause.

As a workaround I downgraded ncurses and copied the files for putty:

cp /usr/share/terminfo/p/putty* ~/.terminfo/p/

You'll need to adapt this for your terminal, if you want to try this.

Trilby · 2023-01-07 02:33:21

Actually, I can confirm related problems with the ncurses update. I get similar results with using Shift+Ins while in insert mode so the terminal should send the characters in the primary selection, but apparently an Esc (or similar) gets sent first and puts vim into normal mode, the proper characters from the selection follow, but depending on what they are, they can have a range of different results in vim, but often ending with the tail end of the selection being inserted.

I'm using foot as my terminal, and the new ncurses includes terminfo for foot ... but apparently it's just broken in some way. Just4arch's proposed work-around works for me too (copying the foot terminfo from the old ncurses package).

Last edited by Trilby (2023-01-07 02:35:14)

cfr · 2023-01-07 04:27:30

Trilby wrote:

I'm using foot as my terminal, and the new ncurses includes terminfo for foot ... but apparently it's just broken in some way. Just4arch's proposed work-around works for me too (copying the foot terminfo from the old ncurses package).

Did you downgrade the package or just copy the info? I just got the ncurses update. I've got ncurses 6.3.3 cached. Hoping that is good enough.

Edit: To avoid overwriting pacman's files, you can copy the files you need to $HOME/myterms/k/ or whatever and then use TERMINFO=~/myterms. (From ncurses manual page; tested with konsole - hence the k.)

Last edited by cfr (2023-01-07 04:39:41)

Trilby · 2023-01-07 04:45:46

There's no overwriting of package files and no need for the TERMINFO variable or a nonstandard location. Just copy it to the standard per-user path as described in just4arch's post. Specifically, 1) downgrade to get the old terminfos, 2) copy the packaged terminfo to the user's terminfo path, 3) re-upgrade. That's it.

cfr · 2023-01-07 05:13:39

Trilby wrote:

There's no overwriting of package files and no need for the TERMINFO variable or a nonstandard location. Just copy it to the standard per-user path as described in just4arch's post. Specifically, 1) downgrade to get the old terminfos, 2) copy the packaged terminfo to the user's terminfo path, 3) re-upgrade. That's it.

Oh, thanks. Not sure how I missed the path.

It also works to extract the terminfo without downgrading.

I've been trying to see if there are any bug reports (Arch or upstream), but I can't find anything.

Edit: It would be nice if the ncurses manual page mentioned the per-user config, rather than only /usr/share/... and ~/myterms trickery.

Last edited by cfr (2023-01-07 05:15:29)

Trilby · 2023-01-07 05:35:54

Which page are you looking at? It is in the terminfo man page under "Fetching Compiled Descriptions" and the ncurses man page in the TERMINFO section.

Last edited by Trilby (2023-01-07 05:41:27)

Evil_Hamster · 2023-01-07 09:49:05

cfr wrote:

Perhaps I'm just missing something, but I don't see where you mentioned that?

"I used ":set paste" to go to paste mode in vim."

just4arch wrote:

You can try "TERM=xterm vim ..." to check if this is the same cause.

On xterm, CTRL + V (or with Shift) does not work. But as mentioned in OP, it does work with the middle mouse. So I guess you are right. I did not know about ncurses, I will try to play with that. Thanks!.
I am kinda suspecting, that some update borked something... might be my own incompetence though .

Thanks to all who wrote (was night where I am, so could not respond in a timely fashion).
I will experiment with this, might take me some time, as I am in many ways still a newbie. But if it works, I will write it (and also a detailed way of doing it, for people using alacritty).

Thanks all.
Cheers.

seth · 2023-01-07 09:54:39

http://ncurses.scripts.mit.edu/?p=ncurs … /tags/v6.4
https://bbs.archlinux.org/viewtopic.php … 6#p1948576
?

schard · 2023-01-07 11:05:41

Turning off bracketed paste is a monumentally bad idea.
https://www.bleepingcomputer.com/news/s … et-hacked/

seth · 2023-01-07 11:22:32

"Copypasting random stuff you maybe don't even understand out of untrustworthy sources into an interactive shell is a monumentally ad idea"
ftfy

The point is though, that the recent ncurses commit log has several references to it, so it could b helpful to see whether the bug is around that area.

Head_on_a_Stick · 2023-01-07 12:20:09

schard wrote:

https://www.bleepingcomputer.com/news/s … et-hacked/

Using the PRIMARY instead of the CLIPBOARD avoids that "hack" completely. It's also quicker and more convenient. [/off topic]

Trilby · 2023-01-07 14:07:47

seth wrote:

The point is though, that the recent ncurses commit log has several references to it, so it could b helpful to see whether the bug is around that area.

Given that one of those patches was in response to input from the author of vim, I'm quite confident that this is the case. So the "old" terminfo workaround should be good for now and an upstream fix is likely in the next ncurses release.

cfr · 2023-01-08 02:46:18

Trilby wrote:

Which page are you looking at? It is in the terminfo man page under "Fetching Compiled Descriptions" and the ncurses man page in the TERMINFO section.

I was looking at the ncurses man page where it talks about using TERMINFO=$HOME/myterms to override /usr/share/terminfo. Since it didn't mention any further possibilities, I erroneously assumed those were the only options. If it had said 'see also XXX below', I would have, but I thought I'd found the relevant bit of the page and so tried that.

Trilby wrote:

seth wrote:
The point is though, that the recent ncurses commit log has several references to it, so it could b helpful to see whether the bug is around that area.
Given that one of those patches was in response to input from the author of vim, I'm quite confident that this is the case. So the "old" terminfo workaround should be good for now and an upstream fix is likely in the next ncurses release.

Is the thought that http://ncurses.scripts.mit.edu/?p=ncurs … 8c8ccd09cc may fix it? I don't even understand the acronyms in the summary.

Last edited by cfr (2023-01-08 03:02:57)

cfr · 2023-01-08 03:00:44

schard wrote:

Turning off bracketed paste is a monumentally bad idea.
https://www.bleepingcomputer.com/news/s … et-hacked/

seth wrote:

"Copypasting random stuff you maybe don't even understand out of untrustworthy sources into an interactive shell is a monumentally ad idea"

But we are talking about pasting into a text editor and not an interactive shell ....

Trilby · 2023-01-08 03:15:41

cfr wrote:

Is the thought that http://ncurses.scripts.mit.edu/?p=ncurs … 8c8ccd09cc may fix it? I don't even understand the acronyms in the summary.

That is my thought, yes. I don't know exactly what PS and PE are, but I know who Bram Moolenaar is. So if we are all seeing a problem with bracketed paste in vim, and the author of vim reported a problem with braketed paste to the ncurses people ... then it's a pretty safe inference that our concern was also the topic of his report.

cfr · 2023-01-08 03:53:17

Trilby wrote:

That is my thought, yes. I don't know exactly what PS and PE are, but I know who Bram Moolenaar is. So if we are all seeing a problem with bracketed paste in vim, and the author of vim reported a problem with braketed paste to the ncurses people ... then it's a pretty safe inference that our concern was also the topic of his report.

Thank you. Some of the pre-6.4 patches relate to the same person. I noticed the Arch PKGBUILD still seems to be pulling in 6.3 patches. Perhaps it will pull in some 6.4 ones soon.

seth · 2023-01-08 07:32:46

cfr wrote:

But we are talking about pasting into a text editor and not an interactive shell ....

Yes.
Bracketed pasting is a security measure that inspects the pasted content for certain bytes (I guess a huge problem in this context will be "\n") and warns you that you're probably doing sth. stupid.
It's reasonable when pasting into an interactive shell that will interpret those special (and possibly undesired) input bytes as commands, but makes no sense in the context of a text editor.
The ongoing theory is that it's bleeding into the wrong context (text editor) and disabling the feature will prevent that problem - but on the cost that your pasting input isn't checked in an interactive shell either.

There's no immediate downside to disabling it, because

seth wrote:

Copypasting random stuff you maybe don't even understand out of untrustworthy sources into an interactive shell is a monumentally ad idea

It's just that not everyone has gotten that message because … reddit. I blame reddit.

schard · 2023-01-08 11:45:55

I beg to differ with your conclusion, Seth. Saying that pasting into a terminal from a website without knowing what one's doing is correct, but there is a downside to disabling that security measure. You're basically saying that acrobats don't need a safety net because falling off the wire would be stupid.

seth · 2023-01-08 12:32:53

seth wrote:

no immediate downside

You're basically saying that acrobats don't need a safety net because falling off the wire would be stupid.

No, I'm saying: don't trip on the wire.
It's not like you'd be somehow forced to paste shit into an interactive shell - unlike an acrobat who makes a living by doing risky stuff for entertainment.
And if it's indeed ones job to paste or otherwise enter dangerous stuff into an interactive shell, one is probably best advised to do this in a virtal environment.

I get why that feature is there and I don't oppose its existence at all.
But its sole purpose is to catch *some* unforced user errors that spring out of bad habits.
If you don't express those habits, the feature is effectively moot. There's no immediate downside by just disabling it.
The downside hits when you, once you do stupid.

And ftr:
a) somehow we made it all the way to 2021 w/o the vast majority of users having that enabled in readline.
b) bracketed pasting does by no means catch all unforced user errors that spring out of "i don't know what this bit of code on 4chan does, but will happily paste it into my terminal" - so any notion that it could be the perfect solution to that kind of stupidity creates a false sense of security. Because your safety net has a bunch of enormous gaps.

cfr · 2023-01-08 22:03:10

But isn't the concern that somebody may understand the code they believe they're pasting, while actually being tricked into pasting different code? Admittedly, that requires copy-pasting from an untrustworthy source, but I guess somebody might think it is safe to do that with code they recognise as itself appropriate.

What's the connection between the change you mention in readline and the recent update to ncurses which breaks vim? Is ncurses implementing 'bracketed pasting' in all terminfo definitions? If so, is copying the old definitions equivalent to disabling bracketed pasting anyway?

seth · 2023-01-08 23:03:48

But isn't the concern that somebody may understand the code they believe they're pasting, while actually being tricked into pasting different code?

That's what bracketed pasting is meant to catch, yes.

that requires copy-pasting from an untrustworthy source

Yes.

somebody might think believe it is safe to do that with code they recognise

And they're wrong.
Don't copypaste stuff from the internet directly into interactive shells.
It is, to quote schard, "a monumentally bad idea".
You're oc far more likely to get away w/ that from a nice dude on the bbs or stackoverflow (if there're multiple views/responses) than from reddit or, worse, 4chan or some random dudes blog.
But it is *never* safe.

What's the connection between the change you mention in readline and the recent update to ncurses which breaks vim?

readline is used by *a lot* of stuff and provides /etc/inputrc which allows to control the behavior for readline and maybe some other implementations that parse it.

If so, is copying the old definitions equivalent to disabling bracketed pasting anyway?

No. Hopefully.
It's as equivalent as an appendectomy is equivalent to ripping out your guts.
The common result is that you'll no longer have an appendix…

echo foo | xsel -i

and then paste (Shift+ins) into your terminal.
Even w/ the old ncurses terminfo you'll hopefully get a warning or marked text or whatnot, but not an attempt to run "foo" (echo puts a newline at the end…)
Depending on your TE (and shell) that will change if you disable bracketed pasting - xterm+bash should stand a good chance to expose the difference.

I do not know what the change in the terminfo does - w/o research I'd guess it alters the used escape sequences and fixes newly introduced, vim specific, functionality.
Apparently there're more issues w/ vim itr. and to be fixed by an update of that.
(only skimmed https://www.mail-archive.com/debian-bug … 86311.html )

Arch Linux

#1 2023-01-06 23:42:08

Vim paste totally screwed up.

#2 2023-01-07 00:08:49

Re: Vim paste totally screwed up.

#3 2023-01-07 00:24:20

Re: Vim paste totally screwed up.

#4 2023-01-07 00:47:30

Re: Vim paste totally screwed up.

#5 2023-01-07 01:41:16

Re: Vim paste totally screwed up.

#6 2023-01-07 02:33:21

Re: Vim paste totally screwed up.

#7 2023-01-07 04:27:30

Re: Vim paste totally screwed up.

#8 2023-01-07 04:45:46

Re: Vim paste totally screwed up.

#9 2023-01-07 05:13:39

Re: Vim paste totally screwed up.

#10 2023-01-07 05:35:54

Re: Vim paste totally screwed up.

#11 2023-01-07 09:49:05

Re: Vim paste totally screwed up.

#12 2023-01-07 09:54:39

Re: Vim paste totally screwed up.

#13 2023-01-07 11:05:41

Re: Vim paste totally screwed up.

#14 2023-01-07 11:22:32

Re: Vim paste totally screwed up.

#15 2023-01-07 12:20:09

Re: Vim paste totally screwed up.

#16 2023-01-07 14:07:47

Re: Vim paste totally screwed up.

#17 2023-01-08 02:46:18

Re: Vim paste totally screwed up.

#18 2023-01-08 03:00:44

Re: Vim paste totally screwed up.

#19 2023-01-08 03:15:41

Re: Vim paste totally screwed up.

#20 2023-01-08 03:53:17

Re: Vim paste totally screwed up.

#21 2023-01-08 07:32:46

Re: Vim paste totally screwed up.

#22 2023-01-08 11:45:55

Re: Vim paste totally screwed up.

#23 2023-01-08 12:32:53

Re: Vim paste totally screwed up.

#24 2023-01-08 22:03:10

Re: Vim paste totally screwed up.

#25 2023-01-08 23:03:48

Re: Vim paste totally screwed up.

Board footer