Virtual Space is not implemented.

[gregmarr]

https://blogs.msdn.microsoft.com/zainnab/2010/02/28/understanding-virtual-space/

This is a much needed productivity option that has been available in Visual Studio and other editors for many years.

See also the column select issue that requires it:
#5402

---

Addition from @hediet:

This is (still) the current behavior of VS Code. Only text that exists in the text buffer is selected:

However, the column selection mode should support rectangular selection like this (adding whitespace on demand):

This would fix #5940 (which is just about copy&pasting such blocks) and #115559.

[roblourens]

I'm not sure we need a new issue for this if it's just part of #5402. Looks like there's lots of history there already.

[gregmarr]

Completely fixing #5402 requires this, but this can be implemented without the changes to column selection.

[roblourens]

I see. Virtual Space - https://blogs.msdn.microsoft.com/zainnab/2010/02/28/understanding-virtual-space/

[eric-777]

+1 for this feature. Virtual space is a must-have for me. I really like the editor otherwise, but until this is in I'll have to keep using Visual Studio. I hope it makes it out of the Backlog soon!

[Neurochrom]

+1

[itadapter]

Still no virt space or am I missing something?

[eric-777]

@itadapter: I don't think you're missing something. The feature isn't there. Looking at related threads about column select features, it appears the stance is that column select doesn't require virtual space. To my knowledge, @alexandrudima hasn't responded directly to anyone about virt space, only to questions about column select.

Virtual space isn't available in Atom or Sublime either. I always thought BRIEF was a common background for programmers looking for a non-IDE experience, but apparently not if all 3 of the modern alternatives do not implement the feature.

[ak-hpc]

It would be very nice to have virtual space feature in vscode.

[greggman]

These are common things I do in my other editor. If there's a way to do them in VSCode that would be great. Seems like they need virtual space

If you're not a fan of aligning tables many coding standard align comments

Those are maybe minor examples but I find that I'm missing them quite a bit moving to vscode.
Here's another example

vs VScode

This isn't just about comments, it's about being used to column select with cursors in virtual space. In my editor at least which pre-dates multiple cursors (though it has them now) the main cursor can't go into virtual space (well actually that's configurable), but once column selection is started then it can go through virtual space.

[jeffmadison]

Executing the "Go to Line..." command when specifying a line number past the end of the file (and/or a column number past the end of the line) should also place the cursor into virtual space.

[eric-777]

Would it be possible for someone on the dev team to comment on whether the virtual space feature is even a good fit for the editor internals? I'm wondering if it's something I should be hopeful about being added at some point, or if it's perhaps unlikely due to large refactoring cost vs minimal benefit (small number of users who really want it).

[tksuoran]

Any progress with this?

[BErasmus]

+1. There are a few things that prevent me from switching to VS Code, but this is a big one.

[tkimovski]

+1. Absolutely a must-have. It's a deal-breaker for me too.

[ChrisTuckerNM]

This is a deal killer! Here I go again opening notepad++ becasue an editor does not have a feature that is part of my daily workflow!

[jchatel]

Seriously guys on the Visual code team, communicate to each other in your company because that's one of the most powerful features and it was there for more than 18 freaking years in Visual Studio.

https://blogs.msdn.microsoft.com/zainnab/2010/02/28/understanding-virtual-space/

That's why we use an editor instead of Word (fixed font size and virtual space) when it comes to write code fast.

[eric-777]

@jchatel we have to keep in mind that this product is both free and good when asking for new features. I wouldn't call virtual space a particularly powerful feature. I feel like its absence is more of a high barrier to adoption among many of us who formed our editing technique with it.

Also, I use proportional fonts AND virtual space in VS. They are definitely not mutually exclusive.

I'm encouraged that the issue isn't closed. Perhaps the team is committed to adding the feature but is facing some refactoring costs that need to get planned for. I can imagine that adding virtual space after the fact might break a lot of code that can otherwise assume the cursor is always on a physical character.

On the other hand, I've seen the phrase "cursor floating in air" used by a VS Code developer somewhat pejoratively. This discourages me and makes me wonder if the team instead might be considering closing the editor to those who work that way.

Any comment from the dev team on which way this is heading would be pure gold to many of us.

[greggman]

There's multiple issues conflated here.

For example in my editor of choice I have virtual space off. But, my editor (like Visual Studio but unlike VSCode) has a column select mode. The column can go through virtual space and is an extremely powerful feature that I use many times a day and end up being frustrated having to tediously manually edit when in VSCode. (see gifs above).

Column editing solves a host of issues that multiple cursors do not (and vice-versa). Both features are important and powerful but at the moment it seems like column editing can not be added without support for virtual space.

[eric-777]

Column select discussion is here (I think there are others too): #5402

This thread is about virtual space only, described very well by the link jchatel provided: https://blogs.msdn.microsoft.com/zainnab/2010/02/28/understanding-virtual-space/

Virtual space may be a dependency of fixing 5402 to most people's satisfaction, but they are separate. No need to conflate the two here.

[eric-777]

OMG - @x17jiri - you did it?

Oh please let the PR gods smile upon your changes. Maybe I can stop paying for SlickEdit upgrades. I bought it years ago literally just because VS Code didn't have virtual space and seemed hellbent on ignoring it.

[x17jiri]

It would help if people tried my implementation and reported any problems.

It can be found here: https://github.com/x17jiri/vscode.git , branch virtual-space-1.94.0

I also prepared github actions, so it's possible to use build artifacts from here https://github.com/x17jiri/vscode/actions/runs/11182995789

Notes:

• since this is a fork, I'm not allowed to use the official vscode market place. Instead it uses https://open-vsx.org . This open source market place doesn't contain all extensions from the official one. The missing ones can often be installed from a .vsix file
• Some extensions may break. For example the "fix hover" commit was need, because when hovering the mouse beyond end of line, I would sometimes get intellisense tooltip for code on the next line. When possible, I'll try to fix these on the vscode side, but we may find issues that need to be fixed on the extension side.

[m6502]

@x17jiri this is amazing to read, thank you very much for your work. I would like to try it but I'm not sure about how to proceed. Is it necessary to download the code and build the editor? Or do you have a prebuilt package?

[m6502]

@x17jiri nevermind, found it. I'll test it intensively :-)

[m6502]

It ****ing works! THANK YOU @x17jiri .

To enable it: Control + Shift + P, "Preferences: Open User Settings", add this line to the JSON between the { }

"editor.virtualSpace": true,

No need to reload. It works! I can't believe it. Really, thank you.

[m6502]

For now I just experienced a small bug with virtual space enabled. When changing lines up or down it sometimes calculates the position (one space?) to the side. When returning to the other line it goes to the same position it was, so it seems to be coherent. Even if this was impossible to fix it's already a thousand times better than not having virtual space, but I'm sure this is a pretty small thing to fix :-) I'm still feeling like dreaming.

[x17jiri]

@m6502 Thanks for testing and for bug report. I'll prepare a fix

[m6502]

@x17jiri I took some time to find the cause for the change in position and realized it's just happening in one situation: Editing a JSON file with RGB values in hex, when the little color selection appears. That's what's causing the position to change:

[m6502]

It's the square for the color selector that vscode inserts that is fiddling with the position calculation... Of course that square is not in the text. So this may not be possible to fix. Indeed it may be correct to not fix it, because that square is not in the text... It's a really weird thing. Position calculation in C code is working perfectly.

[m6502]

When more people test this it would be amazing if you could try to do a pull request. I just can't go back now :-)

[Felice-Enellen]

It's the square for the color selector that vscode inserts that is fiddling with the position calculation... Of course that square is not in the text. So this may not be possible to fix. Indeed it may be correct to not fix it, because that square is not in the text... It's a really weird thing. Position calculation in C code is working perfectly.

I'm inclined to agree that elements that are not actually intended by the document's author to be there should not be something this change needs to work around.

That being said, is virtual spacing expected to work with proportional text? I imagine that will have similar issues. Similarly, even with monospaced fonts, a Unicode file may need to be rendered with multiple fallback fonts that fill in the gaps, and they often do not space/kern alike.

[m6502]

About the proportional text problem, taking for example Notepad++, Scintilla tries to approximate the position, but of course it can't do it perfectly. In my opinion it's not a very important thing because in my head the reasons to use virtual space are basically incompatible with the use of non-monospaced text. Having an approximate position is infinitely better than not having virtual space, but I can't personally understand why would anyone want to use proportional text with code.

This is how that situation looks in Notepad++:

[m6502]

This is how it's looking right now with @x17jiri implementation:

Honestly: I couldn't care less. If it can be improved, then nice, but in this state is still less random than not having virtual space... It's a non-issue in my opinion. Code is not writing. There's information in knowing the position of the code. Code has to be in a monospaced font :-)

This just made me think about what a mix proportional fonts and Python could end up being.

[m6502]

Also, mixing rectangular/column selections ( #5402 ) with proportional fonts is just hell.

[x17jiri]

VSCode uses model-view architecture ( https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel ).

So there is:

• document model, which just works with text strings and line/column positions
• view, which renders the model

When you process a command, you are supposed to work with the model representation.

For example, if I press "page up", the line that I'm going to is currently not rendered, so I cannot even get the view representation and the exact pixel positions of characters.

This architecture makes things simpler, but it's difficult to keep the exact pixel position of the cursor. So in the current implementation, I just try to preserve the column number. If there are any proportional elements or elements that are not in text, the cursor may still jump left and right.

@m6502 New build is running here: https://github.com/x17jiri/vscode/actions/runs/11200839841 . It should fix the bug you found

[m6502]

@x17jiri Thanks, I'll be using your releases to work from now on, so I'll be able to give much more feedback.

[m6502]

Happy to report your release has survived a long day of real programming work and it didn't suffer from a single problem. This is amazing. Very well done @x17jiri

[m6502]

And there we go. I've been using @x17jiri 's fork for a whole week, programming a ton of hours each day. I haven't had a single problem. Why isn't his PR already integrated in the main branch?

[indigomirage]

This looks incredible. I'm amazed, and grateful. However, I'm not clear on what I would need to do to run/install it!

Is there a 'how-to' anywhere? (ultimately, I'm not sure on how to start using the fork).

Is there any likelihood that this would make it in to the main vscode universe as an extension? Or am I missing something?

[m6502]

@indigomirage I've been using it for nearly two weeks, it just works perfectly fine. To use it, for now, you need to download a zip archive and unzip it into a folder of your choice. At first I wasn't completely sure about where it was located but the archive (Windows) is here: https://github.com/x17jiri/vscode/actions/runs/11200839841/artifacts/2020552610 Your browser will download the file code-x17-win32-x64.zip

This pull request should end up in the official VSCode itself. As far as I know an extension can't do what is needed to properly implement Virtual Space.

After you test it you may want to move the pull request a bit further to be accepted here: #228680

Go down there and "Add your review". Four are needed to accept the pull request, currently there are two.

[indigomirage]

Thank you so much for the quick response and assistance! I will try this out!

[m6502]

There's a Linux archive too, by the way: https://github.com/x17jiri/vscode/actions/runs/11200839841/artifacts/2020541118

But I haven't tested it yet, maybe next weekend.

Note that after you launch the editor Virtual Space will NOT be enabled by default. Up a few comments I pointed how to enable it:

To enable it: Control + Shift + P, "Preferences: Open User Settings", add this line to the JSON between the { }

"editor.virtualSpace": true,

No need to reload.

[m6502]

Thank you so much for the quick response and assistance! I will try this out!

You are welcome, this is quite a big deal for me :-) Be sure to read the comment about how to enable the Virtual Space!

[indigomirage]

oh - that's good news re Linux version. I'm actually planning to test that when I get a chance. Generally use windows, but linux on old laptops.

[m6502]

So how many weeks are needed for the team to approve a fully working pull request of a feature that was requested a decade ago and that is being already put to work and not showing defects for those of us who downloaded the fork? Is the public face of this project just a charade where the community is routinely ignored?

[danielbayley]

So how many weeks are needed for the team to approve a fully working pull request of a feature that was requested a decade ago and that is being already put to work and not showing defects for those of us who downloaded the fork? Is the public face of this project just a charade where the community is routinely ignored?

It would grate less if Microsoft hadn’t acquired GitHub, before killing off the open source predecessor, Atom—after promising not to—defacto forcing the mass migration to VS Code. It isn’t exactly the usual open source entitlement to expect basic maintenence from a team of highly paid engineers of a multibillion dollar company…

[tilkinsc]

So how many weeks are needed for the team to approve a fully working pull request of a feature that was requested a decade ago and that is being already put to work and not showing defects for those of us who downloaded the fork? Is the public face of this project just a charade where the community is routinely ignored?

It would grate less if Microsoft hadn’t acquired GitHub, before killing off the open source predecessor, Atom—after promising not to—defacto forcing the mass migration to VS Code. It isn’t exactly the usual open source entitlement to expect basic maintenence from a team of highly paid engineers of a multibillion dollar company…

Haha. I see where you are coming from. Let's also throw in, "its open source just do it yourself"

[AnrDaemon]

It would grate less, if you understand that open source doesn't mean there's no organization behind the product.
And each release cycle has a specific number of tasks assigned to it, with team members responsible for each one.
Just be patient and wait for the next release cycle at least. Even bugfixes are taking month+ if they are not critical.

[m6502]

We all understand that. You will also surely understand that if a feature is critical or not is always going to be dependent on each one needs. This is a truly basic feature that has been missing since forever, that was requested literally more than 8 years ago. And there's a pull request now. They just have to click a button. No need to code it anymore. And they are not paying attention. Just as with a lot of other basic features. This is a critical feature for many of us that have been forced to use this tool thanks to the moves of Microsoft. So, if you moved to make us use your tool, at least, allow us to use the community contribution that will make out lifes easier. I don't think asking to approve a fully working pull request is that much, is it?

[eric-777]

Honestly: I couldn't care less. If it can be improved, then nice, but in this state is still less random than not having virtual space... It's a non-issue in my opinion. Code is not writing. There's information in knowing the position of the code. Code has to be in a monospaced font :-)

@m6502 I disagree, although I understand the perspective. I use proportional + virtual space all the time in Visual Studio proper which does it like your Scintilla demonstration. One has to sacrifice some sacred cows of alignment - basically never tab after initial indent and don't try to build quasi-tables in code - but once ingested it's actually pretty consistent, sane, portable to everyone's editor preferences, and has the bonus of looking great with no OCD alignment distractions.

In SlickEdit (my current alternative to VSCode), I cannot use proportional + virtual space. That's okay, if I can only have one, I'll take virtual space every time. I've paid almost $1000 for SE just for the privilege of having one without the other.

@x17jiri I appreciate the explanation of why it's hard in VS Code to implement both things together. I wonder if this is why the issue was never addressed by the core devs? The perfect being the enemy of the good and such. Maybe some sort of lockout to prevent configuration of both a proportional font and virtual space would appease them if that's the case.