Vscode: Insert key doesn't switch to overtype/overwrite mode

[miroshko]

Insert key should switch between insert and overtype modes but it does not.

Version 0.10.3
Commit 783ecf841a2b21edca6d86853670cae89b4c244f
Date 2015-11-26T14:10:14.207Z
Shell 0.34.1
Renderer 45.0.2454.85
Node 4.1.1
Ubuntu 14.04

[stephenmartindale]

Please fix this! Incidentally, overtype-mode is an open issue in Atom, too: https://github.com/atom/atom/issues/3023

Reproduced in:

VSCode Version: 0.10.11
OS Version: Microsoft Windows 10

[pom421]

I aggre! For some very special use cases, passing in overtype mode can be very useful (for example to create a padded table in ascii mode).
And in OS X there is no physical key to toggle insert/overtype so this future feature will be necessary to be accessed by a command or in the status bar (like Word).

[terenceng2010]

For example, It would be useful when editing a markdown table.

[remcoros]

I am really missing this while working with markdown tables inside vscode. Also for (now and then) editing fixed width ascii files. Would this be possible with a plugin?

[AdamMaras]

As it turns out, this can be done with an extension. So I did it! I put it together pretty quickly, so it could probably use some shakedown time before a 1.0 release.

[octogonz]

+1 I was shocked to discover that Windows Notepad and MS Word don't support this either. I had assumed that this feature was standard across every text editor.

@AdamMaras have you considered making a PR against VS Code?

[AdamMaras]

@pgonzal I have not, I haven't taken the time to get familiar with the contribution guidelines. Also, since the extension's been installed by a handful of people and I'm getting some feedback, I think I'd like to iterate on it a bit more before proposing adding its behavior directly to Code.

[lyngklip]

This does seem like an odd omission indeed. I use it all the time. Other than this quirk, I like vscode so far.

[marekr]

Bump, its so strange its not built into VSCode.

[entozoon]

+1 can't live without this feature.. editing docblocks, etc.

[entozoon]

Thankfully there is a plugin to tide us over in the meantime:
https://marketplace.visualstudio.com/items?itemName=adammaras.overtype

[antcodd]

I think this would be a good candidate for an iteration 'Extension Contribution'/integration directed towards improving VsCodeVim integration, while also being useful for others who do not use the extension.

The current R replace mode in VsCodeVim is rather slow. The extension mentioned above is also quite slow.

As mentioned replace/overtype mode is very useful when editing already aligned tables and definitions, especially in block selection mode. Without this I find myself fighting with alignment plugins fixing alignment multiple times when editing a table row.

I currently use a combination of
https://marketplace.visualstudio.com/items?itemName=siegebell.incremental-search (Ctrl+D for multiple cursors on steroids)
https://marketplace.visualstudio.com/items?itemName=steve8708.Align

'Virtual edit' past the end of the line would also be nice but is more niche.

[jez9999]

It is perplexing that this is not in VS Code. Would the VS Code team tell us why? Is it a design choice??

[ryan-jonesford]

Any updates on this? I would also really like this feature.

[entozoon]

@ryan-jonesford https://github.com/Microsoft/vscode/issues/1012#issuecomment-309411105

[fhurta]

I was surprised this standard editor feature is missing in VS Code.
What's the problem? The issue was filed in 2015. There's even extension created by the community. Is it that hard to implement it? I'm missing here response from VSCode team

[cssjr]

Yeah, some of us older folks still know how to use a keyboard! How can you forget the insert key?

[levininja]

No comment, Microsoft??

[stephenmartindale]

It seems like "overtype" mode is a hot and contentious issue but, frankly, this whole debate is a symptom of a far more serious issue: the "one size fits nobody" approach to modern human-computer interaction design.

Features like these aren't right or wrong: they're preferences. Some want to enable it, some don't, saying that overtype is confusing or somehow difficult to use. One can argue about the correct defaults all day long once it's a preference and not a choice dictated by the current fad or trend but the key thing is to make it a preference. Unfortunately, we are now living in a world where preferences are taboo. Mac keyboards don't even feature an "insert" key and, when I mentioned this to some Mac fans, their response was exactly the same as that of the anti-overtype-types: I don't want that and don't understand why anyone would want it and therefore I conclude that nobody could ever need such a thing.

Alas, I long for the days when one could choose how they wanted to interact with their software and, as muscle memory increased, the only cost that increased was the ever-larger effort required to customise and tweak preferences in any new software that one needed to use.

I know, there's an extension. But I am seriously starting to feel that VS Code relies far, far too heavily on extensions. Extensions should add specific, focused features but basic, basic, basic text-editor functionality that has been standard on PC since the latter half of last century should NOT require the use of an extension.

Please, please fix this. I've been following this issue for over two years, now.

[0x3333]

This can be accomplished using this:

Overtype for Visual Studio Code

[PotcFdk]

@0x3333 You're late. This has already been mentioned here and here

[AlexBillon07]

I really miss this feature.
Even if the extension looks great, I feel this should be a native feature of the text editor !

[apkrieg]

Need overtype to edit comment blocks. Why is this not part of the editor already?

[zwcloud]

Why is this not part of the editor already?

Maybe this is too hard to achieve.

[jez9999]

LOL there's an extension that does this already and it's rather simple.

[FrankSFLYS]

It's amazing that a take-for-granted feature is not supported by oneself but provided by an extension!

[ceefour]

@FrankSFLYS Even WordPad which is installed by default on Windows, comes with "Insert key/overtype" support without installing any extensions (and does not even support extensions). It's so weird why the "hatred" for this feature.

[addictgamer]

+1 like and subscribe. Frankly, I was shocked when hitting the insert key a few minutes ago didn't do anything.

[KerryHess14]

Commenting in the hopes that further public outcry will lead to this being a default feature rather than requiring an extension. *crosses fingers

[FauthD]

+1
Just found this missing mode switch and cannot believe that.

[planetrocky]

Nearly 3 years on and still no update.

[MrMcFortna]

Bump. I echo the sentiments above. When you need this feature, you really need it. Why is this not a standard option for a code editor??

[lucask42]

+1

basic text editing modes should be supported in a text editor.

[nurbles]

Hard to believe that something as fundamental as this hasn't been fixed in over THREE YEARS!
This is an ABSOLUTE necessity in any code editor!
Rather than just +1, people should be giving this plus 1,000,000!

[VictorMazilu]

@nurbles Those are the right numbers!

On Tue, Aug 21, 2018, 6:23 PM nurbles [e-mail] wrote:

Hard to believe that something as fundamental as this hasn't been fixed in
over THREE YEARS!
This is an ABSOLUTE necessity in any code editor!
Rather than just +1, people should be giving this plus 1,000,000!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/1012#issuecomment-414713766,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVPRpRpyMh2sEnKr9I0vVBfdWzVmdEuuks5uTCYBgaJpZM4GuyZJ
.

[vilitormanen]

I'm surprised there is no official comment about the issue. If this is intended and not going to be implemented, please say it in this issue.

[cameronove]

I'm surprised there is no official comment about the issue. If this is intended and not going to be implemented, please say it in this issue.

@vilitormanen 100% agree - what is the stance on this? Can we get an official comment on whether or not your going to work on including this in the main build? Please?

[Joey79100]

I'm surprised this isn't supported, and no dev seem to even care about it, seeing the lack of answers here.
This is a very basic toggle, it's included in the keyboard, so it should be included by default, not through an extension. Otherwise _Caps lock_ could as well be removed from basic features and be included as an extension. Same with _Num pad_ toggle. Or the mouse wheel... the list can go on. I insist, this is a feature of the _keyboard_, it can be disabled literally just by pressing the corresponding key, so it's not the software that should decide whether to use a keyboard's basic feature or not.
At worst, if people are really against having this enabled by default, you can still add a setting to override the keyboard's behavior so it's always Insert, and everyone is happy. But it _should_ be included as a default feature, not with an extension.

[remcoros]

The proposed extension (overtype) registers the 'type' command, which conflicts with other extensions, like VIM, AceJump, Jumpy, etc.

See: https://github.com/Microsoft/vscode/issues/13441

[DaveSlinn]

Count me in the camp of support. I so expected this feature, that I was caught offguard when I clicked the Insert key and it didn't do anything. 15 minutes later, and here I am. And, funny enough, I'm trying to edit a markdown table, like others mentioned. Quickly installed the overtype extension and that works for now, but I did it odd that this isn't built-in.

[WorldofBay]

i can't believe that a modern editor has no built-in way to overtype. however, there's a thing that's disappointing me more and that is that even though alexandrudima and egamma apparently read this in december 2015 (edited labels) and alexandrudima again in november 2017 there isn't a single statement from them even in late 2018.

[chrismarch]

Hmm, wow, I thought this was a modern editor... 2015?!? I guess I need to switch...

[oxysoft]

It's a especially useful when changing values in similar or matching character columns. See the following example:

new Vector3(
   offset.x / period.x,
   offset.x / period.x,
   offset.x / period.x
) * Mathf.PI * 2;

I've just got done copy pasting this line 3 times. As you can see, x needs to be changed in 4 locations. (and no I can't do offset / period, this is with Unity3D) I would go into overwrite, change the first two x on the left, press <END> <LEFT> to move at warp speed and fire away <Z> <UP> <LEFT> <Y>. Without overwrite, I have to introduce 4 new key presses to erase and the hand motion is noticeably more complicated. I bet VS Code developers would lift their hand to pet that mouse instead of using <END>, oof!!!

I have to use the handle of my screwdriver to hammer nails, because the hammer is missing! This is not only a feature, this is an essential tool to professional keyboarding.

[cha0s]

@oxysoft try holding ctrl and clicking after . and before x in the second one on both places. That'll give you 2 'carets'. Then delete and y, then down backspace z :)

Still though, this is just silly that overwrite isn't a thing. Yet another "markdown table" usecase from me.

[WorldofBay]

well that specific use-case is not faster with overtype
assuming cursor is just before the third x (first to be changed)
with overtype:
y down left z end left z up left y
without overtype:
ctrl + d y down backspace z
(actually better approach)

however, there are a lot of use-cases where ctrl + d doesn't work as substitute so you either have to use the mouse (and type single-handed) or do a lot more keystrokes

[DaloLorn]

… Why does this issue even need to exist…?

(On a related note, this discussion explains why I could never use the Insert key in Word... of course a Microsoft function would only be used by non-Microsoft software like OpenOffice. Nothing else would make sense, right?)

[nurbles]

...Why...exist...?

Well, all of Microsoft's _other_ code editor/IDE products support insert/overtype so why shouldn't VSCode? Also, I can speak from experience as someone who has used Microsoft development tools for almost 30 years, it is REALLY frustrating to suddenly need to learn to do without a fundamental editing function.

[RogerCD]

+1

[jamilraichouni]

Must have. Unbelievable that this absolutely common functionality is missing in such a great editor!

[octogonz]

I looked at the plugin, and its implementation is working around a limitation of the underlying Monaco text editor library used by VS Code. I doubt the mainline VS Code would accept this solution.

Perhaps it would be more effective to direct the firehose of community feedback at the Monaco repo, where the real fix needs to occur. ;-) There's already an issue open here: https://github.com/Microsoft/monaco-editor/issues/401

[jamilraichouni]

Ah interesting. But if an extension author found a solution I'd rather expect such workaround being built in since it's really a basic but important feature of a source code editor.

[imkzh]

It's 9102 now and vscode just still don't support this. Can't believe it.

[DaloLorn]

...Why...exist...?

Well, all of Microsoft's other code editor/IDE products support insert/overtype so why shouldn't VSCode? Also, I can speak from experience as someone who has used Microsoft development tools for almost 30 years, it is REALLY frustrating to suddenly need to learn to do without a fundamental editing function.

You misunderstand - I was expressing disbelief at the fact that it was necessary to open the issue in the first place. I'm on your side. 😛

[theelous3]

Can't believe this even has to be requested. Step up ya game, ms.

[lucask42]

octogoz is right, this issue belongs to the editor module which is a separate project. This conversation should be taking place here: https://github.com/Microsoft/monaco-editor/issues/401

[lrineau]

@lucask42 commented on Mar 28, 2019, 2:04 AM GMT+1:

octogoz is right, this issue belongs to the editor module which is a separate project. This conversation should be taking place here: Microsoft/monaco-editor#401

Well, the project https://github.com/Microsoft/monaco-editor is only for bookkeeping (see its README.md), and its code is here, in https://github.com/Microsoft/vscode. It is not a complete non-sense to discuss a feature-request here. But it is also true that the same README.md says:

Issues

Create issues in this repository for anything related to the Monaco Editor. Always mention the version of the editor when creating issues and the browser you're having trouble in. Please search for existing issues to avoid duplicates.

[octogonz]

Could someone point out the place in the source code where the fix would go? Like where a typed character gets inserted into the buffer? I'm curious how much work it would be to implement this mode. Maybe it's easy.

[lucask42]

my guess would be src/vs/editor/common/commands

it'd be trivial to detect when the insert key is pressed, but I'm not sure where the app's state is kept, and we should also have a way of detecting which mode the app should be in (insert/overtype) when the app starts up

[rochacbruno]

I used the extension @AdamMaras thanks!

But why isn't it fixed yet?

[kenlyon]

It's pretty disappointing they still don't support some of these basics of text editing. The "power user" features that save time are being gradually eroded.

On the plus side, I can still use Del, Home, End, Page Up and Page Down. Looks like Ins was the only one voted off the "special keys" island.

[nic-hartley]

+1 for this, it's extremely useful and I keep finding myself missing it.

[sdattalo]

Here's a work around:

Open up your file in VS Code.
Open up the same file in Notepad++, Visual Studio (not VS code), Sublime, emacs, vi, vim, or just about any other editor besides Window's built in notepad.exe or nano/pico.
Press the insert key, except in vi where you intuitively have to press 'r' instead.
Make your changes.
Save your edits.

Done! ;)

[roa-nyx]

Extension has some issues, which I believe should be addressed when core functionality is implemented.

Firstly, typing ( if there is a non-whitespace character under the cursor results in it trying to surround that character with brackets.

E.g., If we tried to overwrite the a in Edward with an ( to get Edw(rd it instead gives Edw(a)rd.

Hitting backspace actually deletes a character instead of just moving the cursor left one character.

Undo'ing results in the last character entered being reset to it's previous value, but that previous value is highlight box selected, and the cursor doesn't move to that previous position making it look like you have a cursor outside the selection range, and it's not clear what the actual cursor/selection state might be.

While the extension could possibly be improved to address some or even all of these issues, I instead have to add my voice that this shouldn't be delegated to extension functionality but should be implemented and maintained as core functionality. If I now build an extension for this, I will be competing with other overtype providers, each of which will have our individual quirks for functionality that is considered pretty universally accessible for most code editors and word processors.

[nurbles]

Hitting backspace actually deletes a character instead of just moving the cursor left one character.

Just FYI, that _is_ what a backspace should do. It is what a backspace has done since I started working with computers in the 1970s.

[roa-nyx]

@nurbles respectfully:

That's a default Git BASH VI, but I seem to recall VI doing this by default regardless. I think the typical code editor behaves similarly. I don't have a key capture overlay, but not including when I overtype some text and backspace to restore the original text, I'm hitting backspace to go further back and it just moves left as if I hit the left key.

The behaviour is probably configurable, but for some of the use-cases here (editting markdown tables for example) this would be the desired overtype behaviour.

[nurbles]

Yet another reason why VI is totally unusable for some of us -- non-standard key usage.

To quote Wikipedia (which is basically a paraphrase of all of the other sites I checked):

Although the term "backspace" is the traditional name of the key which deletes the character to the left of the cursor, the actual key may be labeled in a variety of ways...

On physical typewriters (before auto-correcting selectrics) the backspace key just moved the "input" location one character to the left. In computers (except for a few specific cases, like the one you mentioned) it is expected to deleted the character to the left. Any other behavior would be quite unexpected by most people.

That said, perhaps the VSCode folks (or someone who works on the editor module they use) could find a way to support different editor personalities. Then VI people could use what they like, XEDIT people could use their favorite editor, etc. IMHO, _that_ would be the best solution. Personally, I quite like both KEdit and the editor in Microsoft Visual Studio but I can work with anything that at least has similar functionality to Windows Notepad.

[IvanPizhenko]

Very surprising that overwrite mode is not supported. Please add it.

[wbochar]

Please enable Overwrite Mode

[gnbl]

Please enable Overwrite Mode

[balcortex]

There's a extension called Overtype which allow this functionality

[whpac]

It's very strange that we haven't got this feature built in for 3.5 years

[damufo]

It's very strange that we haven't got this feature built in for 3.5 years
+1

[PsiRadish]

I too would like VS Code to properly support all the standard keys on my keyboard.

[IvanPizhenko]

Surprisingly GitHub's Atom also seems to don't support overwrite mode. And they're build on the same foundation libraries with VS Code. So maybe problem is in the Electron framework? But I don't believe Microsoft can't address it with its resources.

[meustrus]

As someone who absolutely wants overtype support, I am chiming in against this issue. This feature should not be in the core editor.

tl;dr : The experience for new users is terrible, and if you really want overtype (as I do for rare circumstances), installing an extension for it is extremely simple.

My reasoning is based on the memory of "discovering" overtype for the first time in Microsoft Word some 20 years ago. Somehow I accidentally tapped the INS key on my keyboard without realizing, and I thought Word was broken for days. I was trying to figure out workarounds when I started examining the margins of the screen, found the "INS" marker, and finally figured out what happened through experimentation. This was on a 640x480 pixel screen, where it would have been easier to see things on the margin than the 1920x1080 screens (and higher DPI screens at the same scale) that are standard today.

The fact that I was very young when this happens did affect how long it took to figure it out. It also affected my willingness to explore and experiment. And even though we can usually look things up on the internet these days, I'm not sure how to find anything if you press INS by accident and don't know that the feature is called "overtype".

One of VS Code's greatest advantages is that in its default configuration, it has very little in the way of surprises. Much like Sublime Text or Notepad++, it's a simple plain text editor with extra features that never get in the way. Anything that may be confusing to new users tends to be in the extension space.

This means I can give VS Code to kids and let them play around and get familiar with IDE concepts over time. There isn't really anything else that does this.

Please don't break this. We need code editors to be more accessible, not less. Power users like me and everyone else in this thread can easily install an extension. I have a running list of extensions I want installed anyway; adammaras.overtype is just 1 of 28 at this point.

...and if there are problems with that extension, how about making PRs against it to fix the issues instead of demanding that Microsoft engineers reinvent it in the core editor?

[lyngklip]

As someone who absolutely wants overtype support, I am chiming in _against_ this issue. This feature should not be in the core editor.

tl;dr : The experience for new users is _terrible_, and if you really want overtype (as I do for rare circumstances), installing an extension for it is extremely simple.

You must have been so young that you haven't experienced mechanical typewriters. Insert would be the counter-intuitive thing when moving from a typewriter to a word processor. Leaving out the possibility to switch between the two in an editor is stupid. End of discussion.

[meustrus]

I have experienced manual typewriters. Forced overtype sucks. If you make a single mistake, you have to throw away the whole page.

Also, typewriters don't have an INS key, so the switching mechanism on Windows is still unintuitive. Especially since computers never start in overtype mode, and for good reason. VI starts in COMMAND mode and it is a huge barrier that is often impassable to non-technical users.

Just because an older technology worked one way doesn't mean that way is better. Next you'll be telling me that vanilla VS Code needs a way to run in ANSI terminal mode. Which would be cool, but confusing to new users if they happened to launch it that way by accident.

[lucask42]

Great... Another argument of the form "I would like to do X" "Why do you want X? You shouldn't want X! Just do Y"

Facts are it's a basic mode of input and is supported by (most?) other editors and many people desire this feature. If a person has used other editors or office software they have likely encountered this input mode. It isn't some arcane method of torture that people need protection from.

Extensions should be for special behavior like code highlighting, linting, etc. Like, we shouldn't (and don't for good reason) have to install extensions to use PageUp and PageDown keys to navigate within files.

This feature could be disabled by default (like it is in Word, now) and accessible only after toggling a preference. I think that would be acceptable if it really is a usability problem but I would momentarily resent the paternalism.

[meustrus]

I also want X. I have X and can't understand why everyone else is whining that X takes an extension.

Because the most common argument here is that overtype is somehow standard, consider this: there is no indicator light for it on the keyboard. Caps lock is standard and handled by the OS. Num lock too. Insert, however, is used for many different purposes, most of which do not introduce hidden modality.

The overtype behavior of the INS key is not standard. Other Microsoft products no longer support it. Macs never have. VI and Emacs support overtype through completely different mechanisms.

That out of the way, let's discuss specifics. Use cases suggested thus far are: ascii tables and repetitive nearly similar copy pasted lines.

In markdown at least, tables do not need to be properly aligned. They look better that way though, but do you know what's easier than overtype for maintaining them? A table formatting command. No more futzing with input modes that only work with same-size text. Paste a 60-character table cell into a 20-character column and just reformat table.

With repetitive copy pasta, there isn't a strictly better solution. Maybe a regex replace, which offers even more flexibility for when your columns don't align? If you're doing things with that much copy pasta, though, there's nothing wrong with overtype. I would suggest it's not that common, though.

Aside: Neither use case makes any sense without monospace font, so I really don't understand word processors implementing overtype. Maybe I'm missing something critical here.

The negatives are serious, though. Consider the brief comment on implementation from @lucask42:

it'd be trivial to detect when the insert key is pressed, but I'm not sure where the app's state is kept, and we should also have a way of detecting which mode the app should be in (insert/overtype) when the app starts up

VS Code would need to introduce persistent modality to support this feature. The change is significant, both in implementation and in design.

The vanilla editor behavior is stateless. If this were VI, replace mode would fit in naturally. It's not, and it doesn't.

PgUp and PgDn are not modal. Neither is Del, Home, End, Backspace, etc. Caps lock is modal, but is supported by the OS and the mode is effectively communicated back to the user right there on the keyboard. Even with that feedback, though, there's a reason the lock screen in Windows warns you that caps lock is on.

The more I think about overtype and read here, the more convinced I am becoming that it's actually a bad design. I feel like I'm missing something. This comment probably doesn't help, but it would be more useful if this issue had more persuasive argument and less appeal to a somewhat antiquated status quo.

Please, if you have better use cases, share them. If I were Microsoft, I would not prioritize this based solely on people claiming it is standard. Make a more persuasive argument.

[wbochar]

Vs2017 Supports it and a lot of people here used that before moving into VSCode.

I’d rather have it handled internally by the main team then to an extension that’s handled by a person that can let it go after they get bored with making it. I already have a few extensions that are abandon-ware.
A more persuasive argument is that 3 of my main editors support it, I’ve used it for 30+ years and I like to keep using it. It is one of the things that I come back to when using VScode and it gets in the way of me really using it. It would be similar to lose some the control key functions (CTRL arrow key left) and shift select and then someone commenting about modality afterwards. The features you are used to and use every day should be in the program, especially if that feature was there in every other incarnation of it previously (say Visual Studio).
I’m glad you are looking out for the team and the tough problems, but let them figure it out.

From: meustrus [e-mail]
Sent: Saturday, September 28, 2019 11:12 PM
To: microsoft/vscode [e-mail]
Cc: Wolfgang-Aaron Bochar [e-mail]; Comment [e-mail]
Subject: Re: [microsoft/vscode] Insert key doesn't switch to overtype/overwrite mode (#1012)

I also want X. I have X and can't understand why everyone else is whining that X takes an extension.

Because the most common argument here is that overtype is somehow standard, consider this: there is no indicator light for it on the keyboard. Caps lock is standard and handled by the OS. Num lock too. Insert, however, is used for many different purposes, most of which do not introduce hidden modality.

The overtype behavior of the INS key is not standard. Other Microsoft products no longer support it. Macs never have. VI and Emacs support overtype through completely different mechanisms.

That out of the way, let's discuss specifics. Use cases suggested thus far are: ascii tables and repetitive nearly similar copy pasted lines.

In markdown at least, tables do not need to be properly aligned. They look better that way though, but do you know what's easier than overtype for maintaining them? A table formatting command. No more futzing with input modes that only work with same-size text. Paste a 60-character table cell into a 20-character column and just reformat table.

With repetitive copy pasta, there isn't a strictly better solution. Maybe a regex replace, which offers even more flexibility for when your columns don't align? If you're doing things with that much copy pasta, though, there's nothing wrong with overtype. I would suggest it's not that common, though.

Aside: Neither use case makes any sense without monospace font, so I really don't understand word processors implementing overtype. Maybe I'm missing something critical here.

The negatives are serious, though. Consider the brief comment on implementation from @lucask42https://github.com/lucask42:

it'd be trivial to detect when the insert key is pressed, but I'm not sure where the app's state is kept, and we should also have a way of detecting which mode the app should be in (insert/overtype) when the app starts up

VS Code would need to introduce persistent modality to support this feature. The change is significant, both in implementation and in design.

The vanilla editor behavior is stateless. If this were VI, replace mode would fit in naturally. It's not, and it doesn't.

PgUp and PgDn are not modal. Neither is Del, Home, End, Backspace, etc. Caps lock is modal, but is supported by the OS and the mode is effectively communicated back to the user right there on the keyboard. Even with that feedback, though, there's a reason the lock screen in Windows warns you that caps lock is on.

The more I think about overtype and read here, the more convinced I am becoming that it's actually a bad design. I feel like I'm missing something. This comment probably doesn't help, but it would be more useful if this issue had more persuasive argument and less appeal to a somewhat antiquated status quo.

Please, if you have better use cases, share them. If I were Microsoft, I would not prioritize this based solely on people claiming it is standard. Make a more persuasive argument.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/vscode/issues/1012?email_source=notifications&email_token=AAWWEE3QX6KZ57W3OQCSSPDQMAMJRA5CNFSM4BV3EZE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD73G6OA#issuecomment-536244024, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAWWEE3FIWA2Z2KDHCEVAMTQMAMJRANCNFSM4BV3EZEQ.

[lucask42]

The lack of a dedicated LED doesn't have to be a barrier, the cursor changes from a bar to a block or underline. I think this is easier to see than the LED on the caps lock key. I don't think there must be a dedicated key on the keyboard, I'd be happy to map it to Cmd+i or something. Ya know, there are plenty of things VS Code can do that are just not mapped to any key combinations out of the box, that'd be one way to avoid traumatizing the next generation of coders unnecessarily.

That Microsoft and Apple eschew overtype doesn't mean that a code editor needs to follow suit. Like I dont know of any other Microsoft or Apple product that lets you create multiple cursors, but in VS Code you can and it's super awesome and useful. And! There are alternative methods one can use without resorting to multiple cursors.

Also, not sure how this applies to anything but my Mac keyboard doesn't have a numlock key or indicator :) I think that's fine since I never ever intentionally turned numlock off and I'm glad it's gone, hope it never ever comes back, and no I don't see any irony in that at all.

[IvanPizhenko]

Why editor mode should be persistent? No need to complicate this, and unlikely most users need that. Editor can always start with insert mode, and it's easy to press INSERT key and switch back and forth.

[theelous3]

I would not prioritize this based solely on people claiming it is standard. Make a more persuasive argument.

Seems persuasive enough to me. When googling "what does the insert key do" and every single answer is overtype mode, that is enough.

It's the expected behaviour in a code editor, and your editor should behave as expected. This isn't some complex thing that needs to be philosophised about - _"what should the key really do? :O"_

It should do its job.

[mz8i]

I was really surprised that VSCode does not handle the Insert key. I mean, come on, even the Wikipedia article for "Insert key" describes switching between insert and overtype mode as the standard behavior...

[hilari0n]

This seems to be considered a backlog candidate in this issue: #86671
The supporters are asked to upvote there.

[mwpowellhtx]

This is pretty hilarious, editor does not respond as "ordinary" editors respond to the Insert key, overwrite/insert mode.

[Mat-Moo]

Pretty stunned in over 30 years of development that insert doesn't do anything! Really?!

[henrik-jensen]

To all those referring to the otherwise fine extension Overtype by @AdamMaras, it has got a major problem with auto-repeating that hopefully is not inherent to the way it's implemented, but can be fixed.
Anyway, this really should be an internal functionality.

[olfek]

When will this be available? I needed to use this right now.

[nurbles]

@olfek sadly, I don't believe this will ever be corrected. I suspect we must just sit back and enjoy the benefits of object re-use, since the issue is apparently with a component used by vscode, rather than vscode itself. If it were in vscode, I would certainly hope that 3.5 YEARS was enough time to fix something so fundamental. (sorry vscoders, frustration creeping in)

[avm19]

This is very sad. I can confirm that the feature is missing as of

Version: 1.45.1 (user setup)
Commit: 5763d909d5f12fe19f215cbfdd29a91c0fa9208a
Date: 2020-05-14T08:27:35.169Z
...
OS: Windows_NT x64 10.0.18363

[IvanPizhenko]

Unfortunately, Microsoft seem to don't plan to implement it.

[thollins]

So here I am reading through this Issue. I google "vscode how to turn on overwrite mode" and it returns "You idiot you press the INS key OR Ctrl Shift I you big dummy"
It doesn't work.
Someone above has an extension and it has an issue of auto repeating chars.
So someone else had said that overwrite is dangerous bc they didn't learn about the editor before using it and didn't ask an experienced programmer whether this was an issue. So we must all suffer because of his singular experience.
I think the repeating bug in the extension is more dangerous than including a feature that has been in nearly all editors forever.
vi has overwrite.
All Visual studio editors.
All word processors - which btw ALL computer jobs REQUIRE proficiency according to the job postings.
I think I made my point. But looks like the maintainers don't want to take the time to include it.

[mwpowellhtx]

It really boggles the mind that the devs cannot figure out how to debounce a g/d key press gesture. Utterly insane.

[octogonz]

Friends, I'm pretty sure the fix would need to be implemented in the https://github.com/Microsoft/monaco-editor component, not in VS Code. Is there a corresponding issue being tracked over there? If not, that might explain why this is going nowhere.

[hilari0n]

Friends, I'm pretty sure the fix would need to be implemented in the https://github.com/Microsoft/monaco-editor component, not in VS Code. Is there a corresponding issue being tracked over there? If not, that might explain why this is going nowhere.

If you would read through the comments, you would notice, that it was already suggested. An issue was then opened in the Monaco repo. And then all the issues were moved to VSCode repo, as - apparently - the Monaco repo is not for issues, or something.
We were also told there, to vote for that issue/enhancement (even when the brunt of the discussion and voting already happened here) and when the vote passed and issue was supposed to be added to the backlog, someone has suggested to close that one, as it's a duplicate of this one.
All in all a complete mess, or an excuse not to implement this change.

(And I'm deliberately not linking to the items I'm mentioning, so you actually do some reading too.)

[meustrus]

If it's so easy, maybe somebody here should just make a PR. If I cared as much as the angry people here, that's what I would do. As it is though, I'm done watching for the devs to respond. Waking up to notifications containing nothing but attacks on the devs just isn't worth it, and I'm not even one of them.

(I'm just the one who suggested that maaybe this behavior would be confusing and frustrating to new users)

[nurbles]

All word processors - which btw ALL computer jobs REQUIRE proficiency according to the job postings.

Well, perhaps all word processors EXCEPT for the one actually named WORD. I use MS Word from Office 2016 daily and still find I've attempted to toggle insert to over-type with no effect.

[hilari0n]

All word processors - which btw ALL computer jobs REQUIRE proficiency according to the job postings.

Well, perhaps all word processors EXCEPT for the one actually named WORD. I use MS Word from Office 2016 daily and still find I've attempted to toggle insert to over-type with no effect.

Oh, it is there (see here), it's just not turned on, by default. (And this could be the approach to use, so the change in VSCode does not cause the people, who are used to VSC not having the overtype at all.)

[BelegCuthalion]

If it's so easy, maybe somebody here should just make a PR.

Well, I'm a user –who happens to be a dev, I don't know TS anyway– not a maintainer of Code. I would be happy to help [myself, in the first place] doing this; learning the tech stack, reading the docs, setting up environment, not forgetting abiding by the CoC, and implementing features for Code (and I readily contribute where I can), but I guess this procedure, "feature request", is designed so that everyone may get what they want, at least, in a more efficient way.

So, I don't know if it is easy for the maintainers (whose great work I appreciate), but for me, I'm sure it isn't worth nobody's time (as it wasn't, say, for me to implement this in nano).

However, I, as a user, think I need this. If the devs don't think so, then ok, thank you for your product, but I still think I need this, and this "feature request" is just where I'm supposed to tell this.

P.s: I'd decided to unsubscribe from this, some time ago, but then I thought I could enjoy watching people fighting over trivial matters. Now, having to justify why someone just doesn't make a PR, I will continue following up only out of curiosity about it's ultimate fate.

[mbomb007]

There is a VS Code extension adammaras.overtype for this, and it works great!

[IvanPizhenko]

There is a VS Code extension adammaras.overtype for this, and it works great!

Great extension, why not do something like this in the base vs code?

[avm19]

There is a VS Code extension adammaras.overtype for this, and it works great!

Great extension, why not do something like this in the base vs code?

The extension has already been suggested by Adam Maras himself. Please read the discussion before commenting.