Unintended characters pasted #101

Closed
opened 1 year ago by cherti · 5 comments
cherti commented 1 year ago

Sometimes when copying stuff and pasting it into a nvim running inside a foot, things like ^[[<1;17;39M get pasted as well, prepending the pasted text. It looks much like terminal format strings or something like that (however they do not seem to change text after it when saved and cated). Therefore it might be reasonable to strip them away upon pasting?

This is either a foot-specific problem or alacritty does strip those away already, the behavior does reproducibly occur in foot but does reproducibly not occur in alacritty.

Sometimes when copying stuff and pasting it into a nvim running inside a foot, things like `^[[<1;17;39M` get pasted as well, prepending the pasted text. It looks much like terminal format strings or something like that (however they do not seem to change text after it when saved and `cat`ed). Therefore it might be reasonable to strip them away upon pasting? This is either a foot-specific problem or alacritty does strip those away already, the behavior does reproducibly occur in foot but does reproducibly not occur in alacritty.
cherti changed title from 4w to Unintended characters pasted 1 year ago
dnkl commented 1 year ago
Owner

^[[<1;17;39M

That's a mouse motion/click event 😆

I'm guessing you are using the mouse to paste? I think I can see how these events can end up in the paste stream...

> `^[[<1;17;39M` That's a mouse motion/click event 😆 I'm guessing you are using the mouse to paste? I think I can see how these events can end up in the paste stream...
dnkl added the
easy
bug
labels 1 year ago
dnkl self-assigned this 1 year ago
dnkl removed the
easy
label 1 year ago
dnkl commented 1 year ago
Owner

The problem occurs when the application has enabled bracketed paste; in this mode, the application treats everything received between the bracketed paste start and end as pasted data. Including mouse events.

It is a problem in foot since paste data, like everything else sent to the client application, is sent asynchronously (otherwise foot would freeze while sending it). This means other events can get mixed up with the paste data.

Thus, foot needs to block, or preferably queue up "other" data while sending paste data.

The problem occurs when the application has enabled bracketed paste; in this mode, the application treats **everything** received between the bracketed paste **start** and **end** as pasted data. Including mouse events. It is a problem in foot since paste data, like everything else sent to the client application, is sent asynchronously (otherwise foot would freeze while sending it). This means other events can get mixed up with the paste data. Thus, foot needs to block, or preferably queue up "other" data while sending paste data.
Poster

I'm guessing you are using the mouse to paste? I think I can see how these events can end up in the paste stream...

Exactly.

> I'm guessing you are using the mouse to paste? I think I can see how these events can end up in the paste stream... Exactly.
Poster

It is a problem in foot since paste data, like everything else sent to the client application, is sent asynchronously (otherwise foot would freeze while sending it). This means other events can get mixed up with the paste data.

That explains why it only happens sometimes.^^ Given that, it's surprisingly predictable.

> It is a problem in foot since paste data, like everything else sent to the client application, is sent asynchronously (otherwise foot would freeze while sending it). This means other events can get mixed up with the paste data. That explains why it only happens sometimes.^^ Given that, it's surprisingly predictable.
dnkl commented 1 year ago
Owner

Given that, it’s surprisingly predictable.

Could perhaps be a mouse release event for the paste click. That should obviously not be sent to the client, since the press was "consumed" by foot.

Let me have a look...

> Given that, it’s surprisingly predictable. Could perhaps be a mouse release event for the paste click. That should obviously **not** be sent to the client, since the press was "consumed" by foot. Let me have a look...
dnkl closed this issue 1 year ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.