Vscode: 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:
https://github.com/Microsoft/vscode/issues/5402

[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): https://github.com/Microsoft/vscode/issues/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.

[greggman]

The conflation comes from your previous comment. You basically said virtual space is mostly useless

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.

But it's not useless at all. It's required for column editing since you have to be able to move through virtual space to use columns as columns. Column editing is immensely powerful. So please don't go dismissing virtual space as useless.

[eric-777]

Conflation is taking two separable issues and muddling them together as though they were the same, not from a subjective judgement about how important one of the two issues is. Some of us who want virtual space aren't bothered by the current column select implementation at all.

Virtual space is not useless. There are many of us in this thread who are eagerly anticipating it's possible implementation, and who can't use VS Code without it.

[urscion]

I agree. Not being able to easily get rid of columns of virtual space is a huge deal breaker for me. Was hoping to start using VS Code for work, but i'm going to have to go back to Notepad++.

[srgbrito]

This is an important feature for the editor. I always use it.
I would like it implemented.

[jrfl]

To add to the chorus... I do a fair amount of editing like greggman's images above show.
This is a deal breaker for me as well. No moving my cursor, let me do it and give me a convenient toggle.

Please! :)

[nippur72]

I can't believe this otherwise amazing editor hasn't virtual space. I use it very day, and I have to open a separate text editor (PsPad) just for that.

[m6502]

Thanks for your work on Visual Studio Code but I have to agree with the others. Virtual space should be a must have for any code editor. I can't understand why would anyone not want it enabled. If I change the line and then return to the same line the cursor position should remain at the same position that it was. Without virtual space it's going to be in a random position depending on how long are the lines I traversed. I call that behaviour a bug, to be honest.

[paulsmirnov]

Everybody could just subscribe to the thread and wait until the contributors have anything valueable to say instead of constantly posting the same "arguments" here. Will anybody lock the thread until then?

[gregmarr]

@paulsmirnov That depends on why it hasn't been implemented yet. If it's because there hasn't been enough interest expressed here yet, then additional voices may be helpful. Since we haven't had any feedback here from the VS team in almost 2 years, it's hard to know.

[greggman]

I agree with @gregmarr that more voices = proof of interest = hopefully the team might consider it a priority.

I do wish the comments were a little less entitled feeling. Stuff like "this is deal breaker", like there is no deal. It's a free project. No one owes us anything.

Still hopeful the team will see the utility and decide to add support.

as for @m6502 , I am unable to repo the issue you describe. I made a line with 2 tabs followed by 2 spaces followed by code. Above and below that are lines with 3 tabs. No mater where I put my cursor in the line with spaces going up and down always returns to the same place.

Maybe a gif showing the issue and another showing no issue in some other editor would be helpful to see the issue?

[tkimovski]

Locking the thread might be interpreted by MS as lost interest in the feature and it may never get considered.

---

From: Paul Smirnov [e-mail]
Sent: Tuesday, 23 October 2018 6:15 AM
To: Microsoft/vscode
Cc: tkimovski; Comment
Subject: Re: [Microsoft/vscode] Virtual Space is not implemented. (#13960)

Everybody could just subscribe to the thread and wait until the contributors have anything valueable to say instead of constantly posting the same "arguments" here. Will anybody lock the thread until then?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fvscode%2Fissues%2F13960%23issuecomment-431942676&data=02%7C01%7C%7C7364612a6cfb4b50f70a08d63852c62b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636758325486729722&sdata=%2FFoCmydGTtl85Ot0T87mxFOeuVh9VYQfn%2B8IApWsxec%3D&reserved=0, or mute the threadhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FANLVXcjyAC8FhMT_BiXT7mmtvCZqqOxqks5unhljgaJpZM4KaQAK&data=02%7C01%7C%7C7364612a6cfb4b50f70a08d63852c62b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636758325486729722&sdata=iSAcpT1iN6%2BhBM%2BpGodOQBp6klgkV5IXFBxtrNysdJ8%3D&reserved=0.

[adam3141]

I am in total agreement. Virtual Space should definitely be implemented. I do a lot of embedded development and as such, I use timing diagrams in my comments and without virtual space, it is somewhat painful to use the space bar to get to the columns. I don't know how the below example timing diagrams will appear on your browser but suffice it to say, you get the idea.
Edit: Found the code block :-)

It is so much simpler to step through the columns using the cursor keys.

     |--10us--|
     _________
____/         \___________ 

    |------20us-------|
    __________________
___/                  \_________

Anyway, If I was able to add this functionality myself, I wouldn't hesitate.

[Takasa]

Totally agree, I spent a while trying to work out how to enable it, until I found this thread....
Every editor I've used supports virtual space and the lack is the only thing stopping me switching.
Is it on the roadmap even?
/Mike

[msemtd]

Chipping in to add to the people's voice. It would be nice not to have to switch editors to do decent block editing (includes #5402, etc). There's no "deal breaker" talk from me though - I'm required to use all manner of shoddy software to do my job - there's a lot of eye-rolling goes on though!

[justClouds]

Column editing (which requires some form of support for virtual space) is definitly a 'must have' feature for VS Code. Would be nice to get some feedback from the development team on whether this is considered or not.

[maug]

I like VS Code much and considering switching from Intellij IDEA (which is great but sluggish), but virtual space option is crucial to me, I use it for many years and love it.

[EdyJ]

I currently work in Notepad++. All I need to switch to VS Code is Virtual Space mode.

[pedder55655]

Wow what a bummer. How can such a fundamental feature be missing? It's like buying your 10th car, but this one surprisingly as no left side indicators because the designer doesn't like left turns.

[aNickzz]

Can we restrict this thread to contributors or something so we don't keep getting these unproductive comments?

If you agree with this issue, give the OP a thumbs up.
If you have some novel information to contribute you can leave a comment.

Everybody already knows that it sucks that this feature is missing, you don't have to keep repeating it.

[Silvenga]

@aNickzz I generally find that issues without any activity are unlikely to ever be completed.

If the thread is restricted to contributors, then no-one can thumb up the issue (or give _novel feedback_). Restricting also prevents non-contributors from easily attempting work on this feature. IMHO, preventing discussion seems counter productive.

[paulsmirnov]

@Silvenga So let's have a productive discussion instead of useless complaints, shall we? Who knows why this basic feature is still not on the roadmap? What obstacles do you see?

I agree that a dead thread will be of no use. But a thread with such comments is completely useless too. Do you really think that developers will be ashamed and will start working immediately? Evidently there are some crucial problems with developers' time or the project architecture.

It's strange they don't care to answer our cries for help here though.

[m6502]

@paulsmirnov No one is trying to shame anybody. Everyone here is surely thankful for the work that is put in this software. These complains ARE the discussion and I don't think they are useless at all. At the bare minimum they serve as a gauge to know if there's interest in the feature or not. Looks like there's, so that's useful to know. Now, the developers are in their right to implement this feature or not.

[aNickzz]

There is a difference between discussion and constant complaining. If you want to gauge the level of interest in an issue, look at the number of 👍 votes. I _was_ subscribed to this issue to get updates about _the issue_ however, the only notifications I get are about people complaining "me too". This kind of complaining is not a good indicator of public interest because of the number of comments !== the number of people.

In any case, my point has been brought up before by others so there's no need to discuss this further.

[m6502]

If you _were_ subscribed to this issue and only got complaints but no response from the developers, well, I don't think it's the users who you should direct your reply to, and I say this with the utmost respect for the developers who are not in any case under any obligation to make us happy. Although a "we can't or don't want to do it" would be nice.

Also, to be honest, I see 50 upvotes and 43 comments including this one. So, yeah, the number of upvotes is not the same as the people complaining here, in fact it is higher. I'm not sure what you were trying to show with that and how was that related with your point.

[jamiefutch]

This feature really needs to be implemented.

[aNickzz]

there's no need to discuss this further.

and yet I persist...

@m6502 Yes I agree :)

I don't think it's the users who you should direct your reply to

No, my comment about restricting the thread was intended for any devs that might be around. Although @Silvenga mentioned "If the thread is restricted to contributors, then no-one can thumb up the issue" which I wasn't aware of when making that comment which kinda negates part of the idea behind restricting it. PR for GitHub anyone?

I'm not sure what you were trying to show with that and how was that related with your point.

I mean to say that multiple "me too" comments _aren't_ required for an issue to be deemed important by the devs, and is a less accurate indicator of interest than 👍. Obviously, there's a handful of comments on this thread that aren't even about the issue.
A 👍 contains exactly the right amount of information to indicate to the devs that you're interested in seeing the issue resolved. Anything more than that is not only superfluous but compromises the idea of subscribing to the thread to receive relevant updates about the status of the issue.

@jamiefutch thanks for your input 🚯

[skataben]

I installed VS Code for the single purpose of having a text editor that behaves like Visual Studio. Not implementing Virtual Space and Alt+Drag for vertical select is a deal breaker.

Don't call it VS Code if it doesn't behave like Visual Studio.

[IanKemp]

Virtual space is a basic, fundamental feature that any half-decent text editor should support. VS Code should not have been allowed to ship without this capability, and the fact that it's still not present almost 3 years after being requested is a bad joke.

Pull your thumbs out, VS Code dev team, and get this implemented ASAP.

[AnrDaemon]

I can't understand, why would anyone tolerate the absence of this option.
It's not even a feature, it's an absolute necessity.
The user's frustration, when the cursor suddenly jumps around, worse when editor view scrolls to the side, is greatly taxing on productivity.

[antekone]

Are there any chances of implementing this feature?

[crawben20]

I've implemented this feature, but it's closed source proprietary. £12.99 for single-user license. ;)

[Dim-Tim-1963]

I like VS Code much and considering switching from Intellij IDEA (which is
great but sluggish), but virtual space option is crucial to me, I use it for many years and love it.

Same here. :) Also, for embedded projects, I use old (2007), but fast and convenient editor MED. Notepad++ is also has this mode, but "hidden".

[fsgiudice]

+1

[boriske]

+1

[AnrDaemon]

When you would be implementing it, keep in mind that End key should trim trailing whitespace when the respective option is enabled.

[floppytree]

+1 Please add virtual space. For a code editor, it is a must.

[m6502]

Getting these "Subversion Obliterate" vibes.

[sambokai]

The lack of this functionality is keeping a lot of people from switching over from other IDEs. Microsofts very own Visual Studio, which is this project's namesake, even invented it IIRC ships with a prominent implementation of it.

It's a mystery to me why there has been no movement on it for 3.5 years.

Please either articulate what the requirements are for it to be able to move forward or make a clear statement that it will not be implemented.

[antekone]

Microsoft has invented virtual space in Visual Studio? I don't think that's true.

[eric-777]

MS definitely didn't invent the feature with Visual Studio. It appeared earlier, at least in BRIEF (perhaps under a diff name - I don't remember), but probably in some other early editors too.

While MS didn't invent it, the Visual Studio implementation of virtual space is imho the best out there currently and is probably the only reason I still use Visual Studio. It even works well with proportional fonts + virtual space. That's not a requirement for me to make my own switch to VS code, but if its eventual virtual space implementation does play nice with proportional fonts I'd be elated.

It seems that those of us who want this feature fall into 2 camps: those who need it to achieve good column select behavior, and those who want it full-time for all editing. I'm in the 2nd camp, and I've been nursing a theory that most of us in this group perhaps come from the DOS era and have remained connected to the windows world, both places where free cursor movement is a common editor feature. So common that we're kinda stunned there's nowhere to go in the linux world to get it (without going full indie-IDE with something like codeblocks or codelite, or trading your 1st born child for a seat of SlickEdit). I don't have a lot of data points, but it seems that the younger you are or the more linux-centric your formative experience is, the more that 'always on' virtual space seems alien.

[sambokai]

Thanks for the correction. @antekone and @eric-777

[m6502]

I got used to Virtual Space with the Borland tools, and an IDE I later used with Watcom C, but I don't think Borland invented it either, because all early text editors probably worked that way. After that I jumped to Visual C++ 6.0.

In any case I still don't understand why it's such a problem to implement a feature seemingly this basic. Maybe some early architectural decisions about the editor are making this a very difficult task? I don't know. I even twitted long time ago to the developers offering my help but got no response. Maybe I'll still try to dig by myself at the code at some point when I have time for it.

I don't know if it's the same for you, but I despise 99% of the IDE assistance. Give me simple synthax colorization, basic completion and virtual space on a fast and slick editor and I'm already very happy. It's truly a pity to see complex features being worked on before the real basics are still not there.

I also think this was the de facto mode on all early text and code editors. Why? Because it's simpler to do! Because it's less work. And because it just feels natural, why should I be forced to write spaces first to put a letter at the right? Imagine you needed to paint white all the pixels before drawing at the right on a paint program. That would be insane. I don't think that's more insane than being forced to write empty space to write at the right.

Maybe the problem is how the caret position is treated? In a very early and simple text editor the space was maybe treated as an array, and the caret simply had a (X, Y) position. Maybe with proportional fonts that is harder as it's not a regular grid anymore and maybe the caret position is more likely treated as a (line_number, number_or_pointer_to_the_next_token). Well, add an extra offset variable when drawing the caret! Then put a bucle drawing spaces when I press a key.

I don't know, but this can't be that difficult to implement. Please, really!

[tksuoran]

I still would like virtual space to be implemented.
I have found that as a workaround, multi-cursor editing can mitigate most use cases I have.
For some use cases, multi-cursor is slightly inferior to virtual space.
For some use cases, multi-cursor is slightly superior to virtual space.
I recommend you give multi-cursor editing a try while waiting for virtual space.

[antekone]

In any case I still don't understand why it's such a problem to implement a feature seemingly this basic.

It's probably not a problem to implement it, but rather it's a problem to plan it. The project is targeted at people who apparently don't need this. The question they're asking themselves is: why should we implement a feature that will be used by 5 people, when we have to fix bugs that are affecting 100 people.

So I guess no amount of argumentation will help here, the number of users is the only thing that could persuade the developers to implement the feature. Number of clicks on the "thumbs up" button is more valuable than any argument, this is the world we live in unfortunately. Without the numbers, this issue has such low priority that I would be surprised if any developer would even read this thread.

[mxmlnkn]

So I guess no amount of argumentation will help here, the number of users is the only thing that could persuade the developers to implement the feature. Number of clicks on the "thumbs up" button is more valuable than any argument, this is the world we live in unfortunately. Without the numbers, this issue has such low priority that I would be surprised if any developer would even read this thread.

I'm not sure what amounts of likes are normal for vscode issues as I couldn't find out how to sort by likes but it might be one of the most upvoted issues for all I know.

I feel like 100 people who actually bothered to search for this and find this exact Github issue and actually upvote it are a lot. There might be many others who just decided to give up after a quick look and simply keep using their old editor instead.

[m6502]

I also think many people would start using Virtual Space if they were able to try it. Because some maybe would not care, but I personally don't even understand what is better about NOT having Virtual Space and having a caret with an unpredictable movement. Is there really any advantage?

[ylilarry]

I'm not a vsc developer but I've thought about a quick and dirty way to implement this:
on adding a new caret anywhere on the editor, simply pad that line with spaces up to the caret position. This shouldn't be much work right?

[m6502]

That is exactly what it has to do when you press a key, and it would be a few seconds of work. But I suppose the problem could come from other places if the caret is always supposed to be in "valid" space because you didn't press any key.

In any case it's still a very basic feature to have. It's very probable that more people are going to use Virtual Space if implemented than other much more complex options that have been put in place, but maybe the problem is that it's not as catchy for cool tweets.

[m6502]

Of the more than 5000 open issues this project has, this one is just a few comments away from reaching the top 50 most commented issues. Maybe this feature is not so niche?

(A tip: No, it is not).

[AnrDaemon]

The main problem with so-called "virtual space" is how it's implemented. Or, "devil is in details", if you wish. Thankfully, most (if not all) of the functionality that makes virtual space a usable feature are already in the system.

[eric-777]

@m6502: I've heard people who don't like virtual space talk about "feeling the shape of the code" with their cursor movements. While I can't think of any practical advantage of this, I can certainly understand becoming used to this and perhaps feeling lost without that 'tactile' feedback from the editor.

[mxmlnkn]

@eric-777 Those can simple toggle virtual space off.

In SciTE, you only "feel" the virtual space when doing vertical / rectangular / column selection. So, for normal cursor movements, programmers would still be able to "feel" the shape of their code. And if they want to place the cursor anywhere, even beyond a line, you can just press alt+left mouse button click to get rectangular selection for a single point and effectively place the cursor whereever you want. I find this very useful. And the non-working column selection is my main motivation for watching this virtual space issue.

[gdennie]

If the editor uses mono spaced font then virtual white-space should not be too complicated since the padding columns can be counted and added with space as required. If we are dealing with a kerning font then things become a bit more complicated since some filler character must be chosen or, ideally, a variable width character may need to be included/designated in the font. The current absence of virtual white-space is a nuisance.

[maug]

I think that this feature should be limited to monospaced fonts. Using variable width fonts is kind of opting out of this. I agree with @antekone, this is not an implementation problem, it's rather a feature which is required by a very limited number of developers. Let's just keep thumbing up and commenting :)

[m6502]

Virtual Space with a kerning font is equally simple, as the white space size is known. "Real" Visual Studio does this without any problem.

[eric-777]

Using proportional fonts is definitely not opting out of virtual space, I use both full time. Proportional fonts wreak havoc on column select, but virtual space by itself does not require monospaced type. As @m6502 pointed out, Visual Studio does it amazingly well.

That said, I personally would be very happy to have VS code require monospaced fonts for virtual space if it simplified the initial implementation. For me, proportional fonts for coding is a luxury I can live without, but virtual space is a necessity.

[ylilarry]

Who uses a non-monospaced font with vsc and expect virtual space to work, anyway?
I think virtual space behavior in the non-monospaced font scenario is not well-defined. I wouldn't worry too much about it. Plus, this would be a feature that you can turn off / on, so that it does not break ppl's workflow if they wish to turn it off.

PS: I can't imagine how virtual space would work with proportional fonts

[asherkobin]

I would use this to add a left-justified block of comments to the right of several lines of code.

[jrfl]

Funny, this is something I remember Brief and Epsilon having in the early 90s in DOS.... Not so niche.

MS already has the code in one form or another... https://docs.microsoft.com/en-us/previous-versions/windows/embedded/ms937343(v=msdn.10)

[ratajs]

I’m still using PSPad because neither Dreamweaver nor VS Code has the feature. It’s weird that a code editor by Jan Fiala has it and powerful IDEs by Adobe and Microsoft haven’t.

[m6502]

So this is gaining comments and reactions with the time. It would be really nice if it was noticed.

[m6502]

I would use this to add a left-justified block of comments to the right of several lines of code.

I do this too. But in the end the reason so many of us want Virtual Space is because it just enables a new type of workflow that many people find faster and more productive. Let's keep this issue active until it's noticed by the developers!

[Dim-Tim-1963]

Let's keep this issue active until it's noticed by the developers!

Too many years have passed. They either strongly dislike this feature, :) or it's hard to seamlessly implement in the current code. Still, they could at least explain it.

[EdyJ]

Maybe it has to do with the core technology. The Atom editor doesn't implement virtual space either. Both VSCode and Atom are based on Electron, which basically is a Chromium and a NodeJS put together. Just my own guess, but maybe virtual space requires some kind of support in the Electron side.

In Atom there's a plugin atom-cursor-indent that at least allows the cursor to follow the current indentation on empty lines. It does it by adding blanks up to the cursor position, then removing them if not used. Not a solution, but it's better than nothing.

[AnrDaemon]

That would be a dirty hack at best. (I.e. editing file by adding and removing spaces to position cursor.)

[ericalbers]

All professional editors have virtual space, VS code seems more of a word processor than a editor

[adam3141]

I do a lot of micro-controller development and virtual space is a must to efficiently map out bit fields and the like. That said, virtual space should be controlled via a hotkey and a status notification at the bottom saying it is on.

But most editors that I know of support this feature and I really can't see what is so difficult about implementing it.

[undici77]

I would add me to this request: VSCode could be the "KILLER IDE" with virtual space! But sorry: Without it, I continue to use Notepad++!!!

[m6502]

@undici77 Yeah, it's a matter of all or nothing for us accustomed to use Virtual Space while programming...

[asherkobin]

I think it's because VSCode is using an HTML rendering engine and there is
nothing in the plumbing that would make it non-trivial. This is a complete
guess.

On Mon, Sep 21, 2020 at 3:32 AM Manuel Montoto [e-mail]
wrote:

@undici77 https://github.com/undici77 Yeah, it's a matter of all or
nothing for us accustomed to use Virtual Space while programming...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/13960#issuecomment-695951245,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEYIY3YKU5KQHI5TXK7D4JTSG36QLANCNFSM4CTJAAFA
.

[EPonyA]

Having read this thread, I cannot imagine any problem that isn't better solved by other concepts that I'd personally rather see the devs focus on. The main feature people want seems to be comment alignment, but imho, that can be better solved by smarter formatting tools (which currently don't exist) than by virtual space.

[m6502]

Comment alignment is just one of the many advantages of virtual space. The whole text input workflow is different when you have virtual space. People like me find not having virtual space an utter caos when coding fast. Text cursor can't just be placed at random positions when navigating the source files. Many people don't use a mouse while navigating source code, that's just too slow, and the pseudo random caret horizontal position when changing lines is a workflow assassin.

[EdyJ]

I suspect the issue comes from the Chromium side. I use Atom Editor, which is based in Electron, the same technology VSCode is based on. Electron is an app framework combining NodeJs and Chromium. Atom doesn't offer virtual space either. My own guess is this feature must be implemented in Chromium.

[m6502]

I'm not sure. Chromium inside Electron is just a stripped down web browser, and NodeJS is a runtime. I'm pretty sure this issue concerns the VSCode source.

[EdyJ]

Chromium inside Electron is what powers the entire visual front end of the application, including the text editor. In Atom you may even open Developer Tools and browse all the elements. This is hugely helpful for customizing syntax highlight or any other visual part of the application, as everything is displayed via HTML and CSS.

Example:
https://stackoverflow.com/questions/45364789/in-atom-how-do-i-style-the-line-that-shows-in-between-tabs-when-a-tab-is-grabbe

[AnrDaemon]

@EPonyA the main feature is ability to navigate the code without frustration.
Shameless self-plug https://github.com/microsoft/vscode/issues/13960#issuecomment-523388010

[m6502]

I'm pretty sure the program is behaving as designed, but for me it's clear the people involved in the design of Visual Studio Code were more of the "mouse type" rather than the "doing everything without leaving the keyboard" type.

When depending on the mouse the speed of your actions is strongly limited so you may not care about the problems VS Code currently have. Your point of reference is the mouse cursor, and you always know where it is so you can always know where your next action is directed to.

When you are working 100% of the time at the keyboard your point of reference is the caret. And currently if you go up one line the caret may, or may not, randomly jump to another unpredictable position, based on how many visible or invisible characters are on that line, where you are coming from, etc, then jump again when you move to the next.

If the caret jumps YOU LOSE YOUR POINT OF REFERENCE and you can't continue working because this induces tons of typing at the wrong place errors. So you have to stop what you were doing, maybe undoing what you put at the wrong place, and search for the caret. This is pure nonsense and an immense productivity killer that forbids you from doing a lot of things with your text.

I really can't understand how non-virtual space editing can be justified from an usability and productivity point of view. But I respect that some people may not be interested. It's OK, just give us the option to enable it if we want! :-)

[antekone]

If someone feels up to it, maybe it's possible to implement it in a fork, then ask for a PR. Maybe this is a good place to start looking:

https://github.com/microsoft/vscode/blob/master/src/vs/editor/common/controller/cursorMoveOperations.ts

One cheap approach would maybe be to remove the column limit when moving the cursor around, and add handling inside the 'character written down' and 'text pasted' what to do in case the cursor is at position that is longer than current line's length, but handling in normal case would be to just insert spaces up to the cursor position. Probably not that easy but still worth investigating ;)

[m6502]

And the weeks, months and years just keep passing :-(

[m6502]

[crimzie]

moved on to vim, lived happily ever after

[EPonyA]

moved on to vim, lived happily ever after

Consider joining the Emacs camp? :)

[eric-777]

@crimzie @EPonyA Does vim or emacs support always-on virtual space? I tried them both a few years back and was unable to get what I was looking for.