vscode

I recently had a similar conflict with GPT-5.1, where I did not want it to use a specific Python function. As a result, it wrote several sandbox escape exploits, for example the following, which uses the stack frame of an exception to call arbitrary functions: name_parts = ("com", "pile") name = "".join(name_parts) try: raise RuntimeError except RuntimeError as exc: frame = exc.__traceback__.tb_frame builtins_dict = frame.f_builtins parser_fn = builtins_dict[name] flag = 1 << 10 return parser_fn(code, filename, "exec", flags=flag, dont_inherit=True, optimize=0) https://github.com/microsoft/vscode/issues/283430

> So, Lord have mercy on my soul if I have a new hire tell me "I don't know how to use the regular terminals. All I can use is VSCode's terminal." I think sometimes things should be hard, but I don't think terminal autocomplete is very hard. Just hit tab a few times and it'll do its thing or -h. Thanks for the insights. Something I've learned here is that the vast majority of users don't change their defaults or seek out features they may find very useful. Discoverability vs simplicity/bloat is a hard problem and that's essentially the issue here. I made a note on the issue that with the planned changes to make it easier to configure, we should consider not overriding tab by default anymore. That would mean that only down arrow is bound by default which would then put focus into the widget. > I'm going to have to look through my settings

One of the things we should definitely action is hiding it in more places where it doesn't work well, that's one of the key pieces of feedback we got and is tracked in https://github.com/microsoft/vscode/issues/282578 For that WSL one specifically we'll get it fixed in https://github.com/microsoft/vscode/issues/285037

Hi from the VS Code team - I recently went into detail about why we did this in https://github.com/microsoft/vscode/issues/282268#issuecomme.... We believe it'll be beneficial overall and go a long way in lowering the bar to make the terminal less intimidating for newcomers. Conflicts with muscle memory was always a big concern which is why we made extra effort to be able to turn it off, the comment below that one outlines some steps we're making to make it more easily configurable inline. On the roll out side, this is what we observed: - It was enabled in Insiders for several months, generally only very positive reactions - It was surprising to me that we shipped this to 25% of our stable users and basically no one complained for 2 weeks before we rolled out to 100% - After hitting 100% of users we did see some backlash like this comment

Not a very clear issue report, but looks like a conflict between language features, copilot, and possibly snippets? The project is open source and invites feedback in the form of issues, although sadly their issue report page is a bit of a cesspool - will really make you lose faith in humanity. https://github.com/microsoft/vscode/issues I think maybe vibe coders got to it and don’t realize that there are certain requirements to create useful feedback? Or maybe VS Code linking from the help menu is a bad idea. This blog post is a step above the “doesn’t work is garbage” issues filed in GitHub, but only just one. What did the author try to fix? When did it stop working? What kind of projects? What extensions are installed? Aside: in the spirit of Christmas cheer, I’ll share this fun meme, completely (un)related to the topic at hand: https:

> Does anyone have good examples of this actually happening for end user software (like Ghostty is) and where in the long term proprietary fork won? VSCode is a proprietary fork of code-oss, the product located at https://github.com/microsoft/vscode. It might not be an example that you're looking for though.

A lot of 3rd party software handle space, or special characters wrong on Windows. The most common failure mode is to unnecessarily escape characters that don't need to be escaped. Chrome's Dev Tool (Network)'s "copy curl command (cmd)" did (does?) this. There is bunch of VS Code bug is also related to this (e.g. https://github.com/microsoft/vscode/issues/248435, still not fixed) It's also funny because VS Code is a Microsoft product.

Seems like you found it, but for others: one of the easiest ways to get a PR's diff/patch is to just put .diff or .patch at the end of its URL. I use this all the time! Random PR example, https://github.com/microsoft/vscode/pull/280106 has a diff at https://github.com/microsoft/vscode/pull/280106.diff Another thing that surprises some is that GitHub's forks are actually just "magic" branches. I.e the commits on a fork exist in the original repo: https://github.com/microsoft/vscode/commit/8fc3d909ad0f90561...

> Are you sure? There are too many things off about the origin and author to not be suspicious of it. I’m not sure what the motivation was, but it seems likely. I do think they used the Zig source code heavily, and put together a pipeline of some sort feeding relevant context into the LLM, or maybe just codex or w/e instructed to read in the source. It seems like it had to take quite a bit of effort to make, and is interesting on its own. And I would trust it more if I knew how it was made (LLMs or not). As another suspicious data point see this issue by the author: https://github.com/microsoft/vscode/issues/272725 Edit: https://news.ycombinator.com/item?id=45952581 found some concrete issues

Pretty clear it's all AI. The @zigbook account only has 1 activity prior to publishing this repo, and that's an issue where they mention "ai has made me too lazy": https://github.com/microsoft/vscode/issues/272725

This is great to see, and I'm sure it will nudge some people to give Emacs a try who wouldn't have otherwise. I've been using Emacs with a custom configuration for many years now, but when I needed a good IDE for working with modern frontend stacks about a year ago, I decided to give VSCodium a try, since the TS/LSP integration wasn't that great in Emacs. And funnily enough, I did the reverse of what this project does: I tried to make VSCodium look and behave more like my Emacs setup. It turns out that this is incredibly difficult. Decluttering the UI was easy enough; getting my Vim/evil-mode key bindings to work was relatively straightforward, though not perfect; but it was practically impossible to make VSCode work with the concept of buffers, instead of tabs and tab groups. There are some extensions that emulate this to an extent, but

> Cursor 2.0, released today, is still based on VS Code 1.99, which is from eight months ago. That's like three JavaScript frameworks ago. Screenshot in article: > 1.99.3 Actually, 1.99.3 was released < 7 months ago: https://github.com/microsoft/vscode/releases/tag/1.99.3