That is a limitation of how the inline diff is implemented. I wonder if we can alleviate this limitation by adding a button somewhere in there (copy or revert this change) that would show up on hover

Instead of buttons, there can be code actions in the diffs for Previous | Next | Copy original | Revert to original like the one provided with git merge. I have requested the feature at #30519

With all due respect, please just fix the inline diff implementation. No need for extra buttons. If you've had this bug around for a year, you should just make the right fix at this point.

Note that this also prevents ctrl-F from working correctly, since it can't find results in the removed lines. "Copy original" buttons don't avoid that issue.

Edit: this is a daily source of frustration, missing relevant changes because I don't get the results I should when using ctrl-F, and being unable to quickly select removed code for pasting into a search box. I rescind my "due respect", this is absolutely stupid behavior and ridiculous that there has been no action on this item. Literally any other diff program (windiff, odd, VS, etc) will allow you to select text from both files and get search results from both files.

This is one of the reasons that I have to open Visual Studio or another diff tool. When traveling the side by side is not an option on small laptops screens and not being able to find or copy the deleted code it is a significant loss.

I think this is a very necessary function !

Yes, this limitation basically forces the user to revert the whole batch of changes just to be able to get a single deleted line back. Its not a big deal if the line was just deleted - that is ctrl+z is for, but if I did a bunch of changes since already it's obviously not an option. I often just need to copy one single chunk of text and put it back into the file. Often not even at the location where it was removed from. But I can't.

I think it has something to do with the fact that the removed text is not a part of the surrounding, still present text - so you can't select them together, but I think if the user started selction inside the removed (red) line - he could/should be limited to selecting (and copying) the text only in the same red region.

Any news on this?

/cc @alexandrudima @rebornix @bpasero

A quick workaround is to switch to side by side view that allows copy/paste.

This is just painful and makes me so sad.

It is surprising to see such a common feature request pending from 2016. Or was it solved in some intermediate vscode releases and reappeared again in 1.31? Also right click doesn't work on left side.
Even in side by side view, I was able to select the deleted text, but can't copy it.

@drdebmath I searched the VS release notes, I don't think this was ever fixed in earlier versions. There have been multiple such requests over time, so a lot of people do want this.

My current "workaround" is to just have Sublime Text open as well - which I use as my git tool - using its amazing GitSavvy plugin.

It is a bit frustrating to be able to see deleted text and not being able to select it haha

@russeg
Because of this, and others "not aligned with the community" ideas from this text editor (or IDE, I don't know anymore),
I changed to another text editor. Sad, but for me I already said goodbye,

@hediet if you can point me to the file that handles this, I can try to fix it myself and make a PR.

First time I see a text editor that can select text that can't copy, super annoying

I am trying to refactor a fairly large file and this is hindering my productivity so much. Refactoring in large code bases is basically impossible without this. This def needs to be fixed.

While I'm fully 👍-ing this request and personally would love to see this feature implemented, I'm subscribed to this thread for a long and some comments people leave here are pretty hilarious (no offence intended), like "prevents me from using vscode", "refactoring is impossible", "moved to another editor because of that". Is it so hard to temporarily switch to side-by-side view and copy the needed text? You can even add a keyboard shortcut for that, to speed-up the flow.

With that said, I see this as only a small part of a much bigger problem which is much more limited implementation of deleted chunks in inline editor as compared to side-by-side implementation. One much worse manifestation of it is the fact that review comments are just not shown on deleted lines in inline view. Now this is really a bug and not just missing functionality. The corresponding issue #164729 is closed as fixed but actually it's not.

Also looking at this query, this seems to be most +1-ed feature requests taged with "papercut" tag so I assume that the fix is difficult otherwise it would be done long ago.

So I'm surprised that one from vscode team gave a proper explanation of the problem and team's thoughts on fixing it.
@hediet, @alexr00 may be you can invest some time and describe the challenge?

may be you can invest some time and describe the challenge?

The challenge is that we would have to create a new code editor for every deleted block. This scales very poorly and might cause freezes when a diff contains many (probably >20) deleted/modified blocks. I actually have a prototype, but without virtualization this is not going to work.

@hediet

Curious, what kind of virtualization do you mean here?
I understand that in side-by-side diff both sides are implemented as full-blown text editor widget. So what happens in inline mode? Can't we have something like "sparse" editor that renders subset of line (the deleted ones)? Can you point to code that implements side-by-side and inline diff views?

Can't we have something like "sparse" editor that renders subset of line

That is quite involved!

So what happens in inline mode?

We use the line-rendering logic of the editor to render the deleted lines, but we don't create an widget for it. Thus there is no selection/copy/etc. support.

Apologizes in advance, I do not know if my solution has already been considered and I'm going based on some assumptions of what I am guessing is happening internally.

If I understand it correctly, currently a diff editor is based on some source file that is being edited. So for added lines it's as simple as highlighting them as they already exist in the source file. But it's not the same for deleted lines because they don't exist in the source file. So they have to rendered in manually. I assume this is how you are able to edit a diff, because you're just editing the source file.

My solution would be to compute the text content necessary to display a diff and put that into an editor instead. This way added or deleted lines could be highlighted the same way. Mark the deleted lines read only. Whenever the user makes an edit, apply it to the source file instead.

My solution would be to compute the text content necessary to display a diff and put that into an editor instead. This way added or deleted lines could be highlighted the same way. Mark the deleted lines read only. Whenever the user makes an edit, apply it to the source file instead.

Interesting idea, but then side-by-side and inline view would have to operate on different text models.
Also, you would need to project edits in this virtual text model back to the original one. That is very tricky.

Also, you would need to project edits in this virtual text model back to the original one. That is very tricky.

I'm not sure if monaco has a concept of being able to read the edits that are being made to one editor and apply them to the other, so that could be tricky. A simpler way to do this would be to take the contents of the virtual text and then remove the lines that are read only. That should leave you with just the content that should be put back into the source file.

Related on Stack Overflow: Enable text selection on changed lines on VS Code Open Changes editor tab

8 years

Yay, it's growing so fast ;)

LET ME SELECT THE TEXT, VSCODE!!!!!!!

Literally please add this feature.

Another reason to appreciate Rider 🤷‍♂️

2025, I’m still here waiting for VSCode to let me select the text. 🙃

The answer on StackOverflow is helped me to return deleted lines selection:
https://stackoverflow.com/questions/78413438/enable-text-selection-on-changed-lines-on-vs-code-open-changes-editor-tab

But to enable Side-by-side view you should disable "Use inline view when space is limited"

To be clear, the above workaround should not be considered an acceptable solution to this issue. Sure, we can figure out all sorts of roundabout ways to copy the text. But what this issue is asking for is to just allow the text to be selected and copied.

Can't believe this hasn't been implemented yet, I started using IntelliJ IDEA because of it lol. Unsubscribing from this as probably won't be even considered. Cheers.

Added a 100$ bounty for this issue to gitpay - https://gitpay.me/#/task/1064

🙏 🙏 Can't wait to pay that out to the person/people who solve this one! 🙏 🙏

I'm absolutely flabbergasted this is even a thing and it's been known for so long. I was just doing some refactoring and realized I needed a small block of code within some deletions. Of course I thought to myself "The diff is one click away. I'll grab it from there!" I clicked the margin change indicator and quickly found I could only look at the code block I wanted. The frustration is compounded by the fact I can select the green text but not the red. It's absurd for an app, whose most core feature is the display and editing of text, to not allow one of the most essential interactions with that text.

@tnrich I've raised a PR regarding this #243399, please have a look

@amit-s19 if that change makes it in and indeed fixes this issue I will be more than happy to award you the bounty! Gotta say if the fix is just a one liner I'll be pretty blown away though 😅🙏