Sublime Forum

Pasting in two places behaves inconsistently

#1

I closed and reopened sublime for the first time in a while, and it seems like multi-selection paste is now broken.

Reproduce:

  1. select a line ending in a carriage return, (triple click)
  2. copy
  3. select another line which appears at least twice (triple click)
  4. command D (mac) to expand selection
  5. paste

Expected behavior: the copied line pastes twice, replacing both previous selections. This was the behavior I had yesterday.

Behavior: Only the first occurrence is replaced, the second occurrence just deletes

Sublime Text Build 3126

Thanks!

0 Likes
#2

I think everything is fine. What is happening:

  1. You copy line with the line break.
  2. Sublime thinks there are two lines in a clipboard.
  3. When you paste this into two selections first line from clipboard replaces your first selection and second (which is empty line) replaces second.

Are you sure before reopening Sublime you did exactly the same steps?

1 Like
#3

Yeah. It’s muscle memory that I can do this, I’ve done it probably O(thousands-to-tens-of-thousands of times), which is why I basically panicked when it didn’t work.

I think we can argue about whether this is a “bug” but I don’t think we can argue about what Sublime used to do. :wink:

0 Likes
#4

It seems very unlikely that this behavior could have changed in core ST without a new release…
More likely that you had a plugin installed that affects the behavior, and that has recently been updated?

0 Likes
#5

Just explored this bug a little more on a fresh install on another machine. No packages on there…

It turns out this only manifests when you want to replace exactly two occurrences with a single line. I.e.

If you triple click line 1 to replace lines 2, 3, 4, the replace works as expected (you replace lines 2, 3, 4). Any number of lines greater than 2 works (or at least I tested a bunch).

However, if you triple click line 1 which you’d like to use to replace lines 2 and 3 only, you only replace line 2 and delete line 3. You don’t add a carriage return on line 3 either…

I checked and this behavior is consistent with ST 3124 and 3114, and the latest version of ST2, so I’m beginning to doubt myself =0

0 Likes
#6

Oh, and also note that if you don’t select the full line you want to paste (i.e. everything but the carriage return, the behavior is what I would expect.

This probably means that when you select a full line with a carriage return, and try to replace two lines, ST thinks you want to replace the first line with the line you selected and the second line with an empty line. This shouldn’t work this way because when you select a full line with a carriage return and try to replace two things, you only have a single selection.

Here’s another way this bug manifests:

Triple click to select a full line, and then shift, right arrow to select the next character which isn’t another carriage return. You’ve selected one, two-line thing. Now select two more identical lines, perhaps with command + d. Paste

Expected behavior: you paste two lines at each selection point, which is consistent with what happens when the selection is 3+ lines.

Actual behavior: you paste the line at the first selection and you paste the next character at the next selection.

0 Likes
#7

The behavior you describe is the intended one. If you have as many selections as you have lines in the clipboard, St will put one line into one selection. If this is not the case, the clipboard is inserted into each selection entirely.

There is only one situation where this is different, afaik: when you copy a line from just having a caret (I. E. Not selecting any characters). However, you run into a different bug when trying to paste this just-copied line into two selections, where the second selection receives a null byte for some reason.

0 Likes
#8

@FichteFoll I don’t think the behavior I’m describing is the intended one: I have 1 selection which I’m trying to paste in 2 places, but it only pastes in the first. That’s a bug, right?

0 Likes
#9

I meant the one in your last post, not necessarily the one in the OP.

It probably is unexpected that an empty line also contributes to the line count for the sake of comparing it to the number of selections.

0 Likes
#10

This was fixed in build 3132

0 Likes
#11

My Hero <3

0 Likes