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.

[gregmarr]

@tilkinsc "I don't care about virtual space. Stop touching my whitespace."

Virtual space doesn't change whitespace.

[Felice-Enellen]

@gregmarr @tilkinsc

Virtual space doesn't change whitespace.

Indeed. This is the point of virtual spaces. They only get converted to real spaces when you make an edit that would require them to exist, and only as many as you would have to add yourself to make the same edit.

Like, let's say we type a partial line of text into a new file. It's just my name, "FELICE", six characters.

If virtual spaces are off, we can't move the insertion point any farther to the right, maxing out at column 7. To move it right, it must be supported by actual physical spaces that we have to type manually, essentially making a sideways stack for the insertion point to rest upon.

However, if virtual spaces are on, we can move the insertion point as far to the right as we want. (We can also move it down, but that's another story involving newlines as well.) For now, we'll just move it one column to the right.

At this point, the document doesn't actually change. The end of the physical line is at column 7, and the insertion point is on column 8, supported by a virtual space pretending to exist in column 7. We save the document and check its size: 6 bytes; the virtual space was not saved.

Now we type an "E", which forces the editor to change the virtual space in column 7 to a physical space, in order to support the physical character "E" in column 8. We save. The file is now 8 bytes.

This is more or less how virtual spaces work. They aren't physical until they HAVE to be.

As an aside, trimming trailing whitespace is optional. If you do, then you can delete just the "E" and the space supporting it will also get deleted on save, taking the file down to its original 6 bytes with no extra space. But if trimming is disabled, the "E" alone is deleted and the inserted space remains, and the file is 7 bytes.

It's all down to taste and preference, and in my experience, not just those, but also context. Sometimes virtual spaces are ideal, sometimes they aren't. But not having them can slow a person down by forcing them to do all padding and aligning manually, and it'd be a boon to all engineers to offer the option not to have to do that if they don't want to.

[m6502]

That's the problem, with this feature missing it's really slow to work on the code. Adding comments properly aligned is a chore, moving between long and short lines becomes literally chaotic with big scroll jumps that can even make the code you are working invisible, and more. This editor really needs this feature.

[Chris-70]

@Felice-Enellen

Sometimes virtual spaces are ideal, sometimes they aren't.

I am curious, in what circumstance are virtual spaces not ideal?
I've never experienced a situation where I wished I didn't have virtual spaces. I imagine some must exist but I can't think of any.

[hartmannathan]

@Felice-Enellen

Sometimes virtual spaces are ideal, sometimes they aren't.

I am curious, in what circumstance are virtual spaces not ideal? I've never experienced a situation where I wished I didn't have virtual spaces. I imagine some must exist but I can't think of any.

The only situation in which virtual space is not helpful is when using a variable-pitch font, as when writing prose rather than code.

In any situation involving monospaced fonts, it is extremely helpful to be able to position the cursor beyond the line end, without ugly hacks like the editor inserting unwanted spaces. @Felice-Enellen described so helpfully how virtual space is supposed to work correctly.

Edit: The helpful description mentioned above is here: #13960 (comment)

[gregmarr]

I think I would differentiate between "not helpful" meaning "having it doesn't make things easier than not having it" vs "having it makes things more difficult than not having it". In this case, I would think it's "having it doesn't make things easier than not having it", in that it isn't getting in your way, but it doesn't make things more difficult. Not having virtual space makes things more difficult than having it. Even if it does, if it's implemented the same way as Visual Studio, it's an optional behavior that you can turn off if you don't like it, so having it in the editor only hurts if you consider the potential lost opportunity cost of the effort spent implementing it.

[m6502]

if it's implemented the same way as Visual Studio, it's an optional behavior that you can turn off if you don't like it, so having it in the editor only hurts if you consider the potential lost opportunity cost of the effort spent implementing it.

The effort spent implementing it would be much less than the effort spent closing the creeping issues reported by the people year after year because the editor doesn't have it and behaves in completely weird and unexpected ways like inserting spaces at the start of a line to maintain the indentation level even if you don't type anything else (wrong), but goes to the start of the line if you click on an empty line below instead (wrong).

How many related issues are needed so the project developers understand this is a completely basic feature that is required to be implemented in order to have a competitive code editor and being able to start fixing more issues their users are experiencing? Do they really use the software they create? Do they type at one char per second and spend their days on the mouse so none of these problems are apparent to them?

[m6502]

The only situation in which virtual space is not helpful is when using a variable-pitch font, as when writing prose rather than code.

Even in the hellish situation of editing code with variable-pitch fonts, having virtual space would be better than not having it, it's that sad...

[Chris-70]

I started with the Brief editor on DOS 3.1 which had virtual spaces so it's ingrained in me.
One of my friends learned to type on WordStar and to this day he needs to swap the Caps Lock and Ctrl keys because it's ingrained in his fingers.
All that to say we all want what we are used to.
It would be good to have the option just like VS does. That said if the issue is deep in the core of the editor, changing it may take a herculean effort. I just wish we could get some information from Microsoft as to the location and effort to implement this.

[m6502]

we all want what we are used to

This is correct, but that changes with time and practice when we get better tools that are better suited for our purposes. I have shown virtual space to many young computer engineering students. At first they see it as a curiosity. With time when just being able to write code is already a given and they can start caring about writing it in proper shape, making it beautiful, recognizable, aligned, then they can't live without virtual space. Not having virtual space doesn't make this tool better suited for anything, it's just the opposite, it makes it worse. Way worse. It's not a matter of learning a better way of writing code, it's a matter of having to do it in a worse way. If you care about your code you need virtual space so shaping the code in the way you want is just an organic process instead of an never ending chore.

[m6502]

To the beginners out there who don't know too much about virtual space but one day read this: With the pass of time, when you truly become productive as a programmer, the thousands of hours of practice start to show and you become a magician of text juggling. You write code at a speed pace you can't even imagine now. I have seen that in the faces of many young students watching me writing code in the "real" Visual Studio. They don't know what's going on, they just see the text moving and appearing and disappearing and before they know everything is in place. But for that to happen you need to be able to move in a deterministic way. Not having the freedom to move and play with the text as you need just destroys your flow and gets in the middle of your creativity.

[Felice-Enellen]

@Chris-70 asked,

I am curious, in what circumstance are virtual spaces not ideal?

I can only speak for myself, but I cut my teeth on an editor, Emacs, that (at least at the time) didn't have virtual spaces. I learned a lot of tricks for navigation around newlines that are ingrained in my memory that will not work while virtual spaces are enabled.

For instance, if I'm at the end of a line and I want to go to the start of the next line, I simply cursor right. Similarly in the opposite direction. It's only a tiny improvement over cursor-down and then home, but when you're in the zone and writing fast, incremental speed improvements matter.

A similar thing would be getting to the end of the next or previous line. If I'm past the end of the next or previous line, I can just cursor down or up, respectively, and the insertion point snaps to the end of that line.

I default to non-virtual spaces as a result of these tweaks to my editing style, but there have been numerous times when I'd switch to virtual. It's great for commenting multiple lines to the right of code, as people have said. If you have it on a hotkey, which you should, it just becomes another muscle memory thing and the mode will just change with your intent without really having to think about it.

[Felice-Enellen]

@m6502 said,

Even in the hellish situation of editing code with variable-pitch fonts, having virtual space would be better than not having it

Ideally, with proportional fonts, you would also have the option of using so-called Elastic Tabstops, which is yet another feature VSCode should include (see #3932). It essentially matches the horizontal position of mid-line tabs on neighboring lines by dynamically setting the X position of the tab stop. It's amazing for init blocks or side comments.

(personally, I would actually start advocating for proportional-font programming if every editor supported elastic tabs)

[gregmarr]

I cut my teeth on an editor, Emacs.

Same, and I still use Emacs-based keyboard shortcuts in VS and VS Code. Ctrl+A, Ctrl+E, Ctrl+F, Ctrl+B, Ctrl+N, Ctrl+P.

For instance, if I'm at the end of a line and I want to go to the start of the next line, I simply cursor right. Similarly in the opposite direction. It's only a tiny improvement over cursor-down and then home, but when you're in the zone and writing fast, incremental speed improvements matter.

A similar thing would be getting to the end of the next or previous line. If I'm past the end of the next or previous line, I can just cursor down or up, respectively, and the insertion point snaps to the end of that line.

Unfortunately, the "if I'm at the end of a line" and "if I'm past the end of the next or previous line" are the controlling parts there, and that is often not true, so "move to the end of the next line" for me is Ctrl+N, Ctrl+E, and move the beginning of the next line is Ctrl+N, Ctrl+A (and perhaps Ctrl+A again because the first goes to the start of the text and really I want column 1, but that's less often that beginning of the text).

[Chris-70]

@Felice-Enellen replied:

For instance, if I'm at the end of a line and I want to go to the start of the next line, I simply cursor right. Similarly in the opposite direction. It's only a tiny improvement over cursor-down and then home, but when you're in the zone and writing fast, incremental speed improvements matter.

Yes, I hadn't thought of that, very interesting. Another argument for fast switching between the two styles.

When I started with the Brief editor, the brace position was on their own lines and indented in line with the containing code. It was explained to me that the braces were part of a compound statement and should be indented with the included statements.

while (coding)
   {
   food += cookie;
   eat(food);
   if (full)
      {
      coding = false;
      }
   }

No one else uses this anymore and when they see it some are hostile to this standard.
Being able to switch between the styles is essential. Having choices is always better than being forced to change what is comfortable for you.

[EdyJ]

@Felice-Enellen replied:

while (coding)
   {
   food += cookie;
   eat(food);
   if (full)
      {
      coding = false;
      }
   }

No one else uses this anymore and when they see it some are hostile to this standard. Being able to switch between the styles is essential. Having choices is always better than being forced to change what is comfortable for you.

Hey, I do use that coding style! 😃 It's called "whitesmiths" indentation style.

I fully agree that having the choice to switch styles is a good option. For that, I use a command-line tool called Artistic Style (AStyle). It can be integrated in most code editors as an external tool.

[m6502]

Yeah, that's the thing, nobody here is advocating for changing the way this software works by making virtual space the only way to edit code: we want it to be added as another option that will improve this software a lot for many people. When I submited the PR for Notepad++ to enable virtual space it never crossed my mind to make it the default option for nobody. Unfortunately VSCode is a different project, code is not as straightforward as Notepad++ and because of that adding this mode is harder as it requires a much deeper knowledge of the internals, so we need the developers to do it or wait for someone who can commit an amount of time that I don't have right now :-/

[BradenYonanoCU]

So this is just never going to happen then?

[eric-777]

The only situation in which virtual space is not helpful is when using a variable-pitch font, as when writing prose rather than code.

The two features are not mutually exclusive. I use both in standard VS and it handles the combination extremely well.

Coding in proportional fonts is a readability choice. I thought the first guy I saw using it was crazy, but I tried it and found I liked it quite a bit. It requires one to make some sacrifices to the alignment gods (alignment becomes only useful at the start of a line) but after some time I personally felt it was a good thing for me to lose my OCD impulse to align things. That said, the 'elastic tab stops' feature someone mentioned earlier sounds sexy.

VS Code is never getting virtual space though. I moved on 3 years ago to SlickEdit, after having already waited 5 years on VS Code to even say something about the feature. SlickEdit is very pricey, but the feature is that important to me.

It's not happening, guys.

[indigomirage]

Lack of virtual space (even as a toggled mode) is the main reason I don't see myself adopting VSCode - I'm trying, but it's driving my bonkers. It is such an important feature.

[m6502]

Lack of virtual space (even as a toggled mode) is the main reason I don't see myself adopting VSCode - I'm trying, but it's driving my bonkers. It is such an important feature.

Many of us are using it from time to time for job related reasons but in the end it's never a smooth experience when you have to copy the code and paste it out in a real editor to get your changes done fast, then paste it back on VS Code. Browsing around the code and regular editing is much slower without virtual space. I've been using VS Code for two years already because a customer works with it and I can assure you the feeling (and reality) of coding much slower never dissipates, it's like typing on shackles. When I return to a real programmer's editor the feeling of freedom is difficult to describe, and after the experience of these years with VSCode I now know I will personally never be able to work at my full potential with an editor that doesn't allow to freely move through the code. So in a way this has been educational.

I find it difficult to grasp how anyone who would care about their software would end up willingly ignoring the request for a feature so desperately needed by many people who are all power users. This says a lot about the end product, that for sure.

[dubhlaidh]

...a feature so desperately needed by many people who are all power users. This says a lot about the end product, that for sure.

I find it says a lot about the modern end users too.

[m6502]

I find it says a lot about the modern end users too.

The thing is that VSCode is probably made by people who just don't type too fast and / or who don't do a lot of text processing while coding, besides copying and pasting :-( But that is not how you write code fast. I do a lot of transformations with the text. I paste a structure and go through the fields writing the initializations in an array. Of course the next step will be them telling us "ask the AI to write that for you" :-) Maybe we'll need to ask the AI to write a code editor ;-)

[indigomirage]

My goto tools were Ultraedit (then Notepad++ for an almost-as-good foss opinion), Visual Studio, and Mssql Mgmt Studio (which is obviously limited). They were all so much faster to use. Cranking out fast-written SQL only happens when you do column-mode work with virtual spaces, and the same technique is, for me, essential for other languages.

Come to think of it, for Sql, the only use I had for intellisense was quick field name completion - anything else tended to get in the way. Auto number-sequence insertion is also essential but I popped out to npp for that (vscode has a few flaky extensions floating around).

I think the bottom line is that I probably, and unfortunately need a better equipped IDE/editor than what vscode can be, and it might not be just because of my lack of familiarity with the the tool. It's a shame because it does have a lot of handy tricks available.

[m6502]

I think the bottom line is that I probably, and unfortunately need a better equipped IDE/editor than what vscode can be, and it might not be just because of my lack of familiarity with the the tool.

I don't think anyone can blame the users for "not adapting" when we are talking about users who have literally spent thousands of hours learning multiple tools over the years and how to work fast with all of them. That VSCode is "the big one" nowadays doesn't invalidate that, at all.

[HackerDaGreat57]

I am shooketh to find out that VSCode doesn't support virtual space. I among dozens of thousands of powerusers desperately need this key feature to keep working our magic efficiently.

From a business standpoint, this giant hole in VSCode makes it far less competitive for a large portion of programmers who just need an editor that can manipulate their damn text the way they want.

[avantgardnerio]

+1

[jr-uk]

Finally found a decent simple way with this great extension: https://marketplace.visualstudio.com/items?itemName=jemc.vscode-implicit-indent