jiebi/CodeConvo huggingface dataset:
Code change:
readonly typeNavigationEnabled?: boolean; readonly typeNavigationMode?: TypeNavigationMode; readonly defaultFindMode?: TreeFindMode; <ins> readonly showNotFoundMessage?: boolean; </ins> readonly smoothScrolling?: boolean; readonly horizontalScrolling?: boolean; readonly mouseWheelScrollSensitivity?: number;

Related discussion:
text: Type: <bBug</ba file for which a DocumentSymbolProvider will return some items, for example on the filename in the breadcrumb, then type Ctrl/Cmd+F. The list filter widget looks OK, though it hides the first filename in the list ( ought to help with this once merged). the same but one item to the right in the breadcrumb. The filter widget is transparent. ! VS Code version: Code - Insiders 1.71.0-insider (, 2022-08-22T05:16:19.478Z) OS version: Windows_NT x64 10.0. Modes: Sandboxed: Yes <!-- generated by issue reporter --
/assign
Easier steps: <kbdCtrl F</kbdon an outline breadcrumb
I still see this. It looks like the background of the find widget gets removed, but the contents still scroll up out of the breadcrumbs widget
Did you test this in dev? Because we still didn't get an Insiders build with the fix.
Code change:
readonly typeNavigationEnabled?: boolean; readonly typeNavigationMode?: TypeNavigationMode; readonly defaultFindMode?: TreeFindMode; <ins> readonly showNotFoundMessage?: boolean; </ins> readonly smoothScrolling?: boolean; readonly horizontalScrolling?: boolean; readonly mouseWheelScrollSensitivity?: number;

Related discussion:
text: Originally posted by in
This also happens if step 5 is omitted and Search mode is used. The problem seems to be that to put the 'No elements found.' warning message under the find-in-list's input widget a ContextView is created immediately below it. But when find is occurring in a breadcrumb list, that list is itself in a ContextView which gets hidden and cleared immediately before the one for the warning message is shown. The warning message appears in the top left of the VS Code window in a very narrow column. See below, where I open , click on the filename in the breadcrumb to get a list of sibling filenames, then type "z" which isn't present in any of the filenames. !
Code change:
const ctx = new HitTestContext(this._context, this._viewHelper, lastRenderData); const request = new HitTestRequest(ctx, editorPos, pos, relativePos, target); try { <del> const r = MouseTargetFactory._createMouseTarget(ctx, request, false); </del> <ins> const r = MouseTargetFactory._createMouseTarget(ctx, request); </ins> if (r.type === MouseTargetType.CONTENT_TEXT) { // Snap to the nearest soft tab boundary if atomic soft tabs are enabled.

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.88.0-insider in Safari OS Version: macOS Steps to Reproduce: Safari open a file with: to the right of any the cursor goes to the beginning of the line not the end This does not repro in stable
I didn't do any changes the last couple of milestones that could (easily) explain this. Can you reproduce this in the monaco editor? If so, can you do a bisect?
I bisected it to this commit: (the commit before it) does not repro the issue. This wasn't in Monaco editor, I just used run code web:
This commit is just a rename refactoring. It is very unlikely it causes this... This does not reproduce in chrome, right?
The bug does not reproduce in Edge on macOS, but it repros in Safari.
Unfortunately, I don't have access to Safari. Can you double check that this is caused by that commit? Can you locally rename the class back to the original name and see if it still happens? It does not make any sense that this commit would cause this behavior only on Safari.
Ok and I paired a bit on this and are really stumped. Bad news: That commit I called out seems to be a red herring. Good news: we can repro in the Monaco Editor Playground.
Code change:
const ctx = new HitTestContext(this._context, this._viewHelper, lastRenderData); const request = new HitTestRequest(ctx, editorPos, pos, relativePos, target); try { <del> const r = MouseTargetFactory._createMouseTarget(ctx, request, false); </del> <ins> const r = MouseTargetFactory._createMouseTarget(ctx, request); </ins> if (r.type === MouseTargetType.CONTENT_TEXT) { // Snap to the nearest soft tab boundary if atomic soft tabs are enabled.

Related discussion:
text: Here's a side by side of two versions of the dev build: <img width="1680" alt="image" src=""You can see when I click to the right of a line, the older (working) build has the correct position here, while the newer broken build has column 1. Here are the links to these versions: Working: Broken: I believe this is out of both of our depths at this point so I'm passing to you This is a regression so I think it should be fixed before we release (assuming I'm not the only one to repro)
Did a bisect using and it points to
In that case, it is most likely .
Code change:
} } <del> const lineBreakRe = /r?ns*/; </del> <ins> const lineBreakRe = /r?ns*/g; </ins> class TestMessageDecoration implements ITestDecoration { public static readonly inlineClassName = 'test-message-inline-content';

Related discussion:
text: The fix for at only replaces the first instance of in the string, not all of them. I suspect the regex needs on the end. <img width="1028" alt="Screenshot 2022-03-17 at 14 46 58" src="https://user-" FYI :)
heh, I found that and was going to change it, but GitHub fell over. I can easily add the , but it's not clear to me where/how to write a test against this class (which is actually the part that I get stuck on any time I want to contribute something). I can't find any similar tests in this area to use as a template.
/verified
Code change:
return { enabled: boolean(input.enabled, this.defaultValue.enabled), delay: EditorIntOption.clampedInt(input.delay, this.defaultValue.delay, 0, 10000), <del> sticky: boolean(input.sticky, this.defaultValue.sticky) </del> <ins> sticky: boolean(input.sticky, this.defaultValue.sticky), below: boolean(input.below, this.defaultValue.below), </ins> }; } }

Related discussion:
text: Issue Type: <bFeature Request</bI want the message could display under the variables it refers to. Because the message box blocks the code over the current line. Thank you. VS Code version: Code 1.36.1 (, 2019-07-08T22:59:35.033Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
Can we just change the default to or does this require a setting?
Kind of feel like this is out of scope, but I don't think this should be assigned to me since it's regarding monaco.
Actually I was wrong - it is determined by : I verified if I swap the order then the hovers appear below instead of above (where there's space). I'll make a PR.
Done! Before: <img width="734" alt="Screenshot 2021-06-30 at 08 45 06" src="https://user-"Change the setting: <img width="921" alt="Screenshot 2021-06-30 at 08 45 14" src="https://user-"After: <img width="777" alt="Screenshot 2021-06-30 at 08 45 22" src="https://user-"
Let's continue tracking in
Code change:
command += ' '; } for (const a of args) { <del> command += `${quote(a)} `; </del> <ins> command += (a === '<' || a === '>') ? a : quote(a); command += ' '; </ins> } break; }

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.67.0 OS Version: Windows 10, using as a default shell Steps to Reproduce: When debugging python(I think debuggers of other languages also got effected too), I'm using following to redirect stdin to my custom input file. This method of implementing redirection when debugging using the < character is also introduced in the . According to the document, This approach requires that the "<" syntax is passed through the debugger extension and ends up unmodified in the Integrated Terminal. and it worked like charm before updating to . From , I've noticed that there was a fix related to automatically add escape character() before special symbols such as or (See Terminal on Windows uses cmd /C, this corrupts passed arguments) When I started debugging session, vscode is now really add before . Since character is escaped, I cannot used redirection with the method mentioned in the document anymore. Is this the intended result? If so, how to use redirection 'correctly' after this build? I know a lot of people redirect stdin to and redirect stdout to when debugging, which is actually very convenient. I think that implementing redirection by passing special characters(, , ) as arguments of the debugger is not a very graceful solution, but that method itself should not be eliminated.
Having the same issue with new version in WSL. It seem some characters are prefix with . My is . But in console, the command is , due to prefix , my code is stuck. It was working fine yesterday, So, I think this issue is with new release.
Code change:
command += ' '; } for (const a of args) { <del> command += `${quote(a)} `; </del> <ins> command += (a === '<' || a === '>') ? a : quote(a); command += ' '; </ins> } break; }

Related discussion:
text: VS Code Version: 1.67.0 OS Version: Windows 10, WSL Ubuntu20.04
Judjung from of , I'm sure this issue is related to today's release too.
Yeah this is Thanks for pointing out the docs, I didn't know this was recommended. It's suspicious to me that we would want to put shell-specific syntax in the args here. That isn't what "args" means to me. I wonder whether we could add launch config parameters like "stdinFromFile" and "stdoutToFile" (and add those to the runInTerminal request) so that vscode can come up with the right syntax for the shell. I may want to revert the change until we have a better solution. Thoughts Maybe candidate
I'm not a fan of allowing this. We already try to escape things from those arguments, so people doing this today have only a half-working shell syntax in their arguments. It also only works if you run it in the , and is of course shell-dependent too, which feels weird.
This is super messed up. I 100% require being able to redirect the output. This needs to be fixed. ages: ["",""] was 100% working on windows before this update! My work flow is screwed rn
Args mean arguments as if I was writing it after typing it in console including SHELL commands. I want to redirect output Why in the world it would add ^is crazy to me. This has to be be bug.
Additional sometimes you need to chain aliases that take redirect or pass a redirect back in < These are shell scripts that having the debugger "args" accept <,,| is really important to have. It was an amazing and highly convenient way to debug. I seriously doubt this is a feature that few people would want deprecated. I seriously don't and it's killing me it broke after this update.
Yeah I agree that passing redirection symbols through args is somewhat weird, and I understand the need for escaping shell-specific characters. That's why I've said it's not a graceful solution. However, many people uses the redirection feature through that way now(even if the docs have been mislead the users). It's good improvement to escape that characters in arguments since it is literally "argument", but I think there should be official solution to redirect I/O.
Code change:
command += ' '; } for (const a of args) { <del> command += `${quote(a)} `; </del> <ins> command += (a === '<' || a === '>') ? a : quote(a); command += ' '; </ins> } break; }

Related discussion:
text: As mentioned above, add parameters such as "stdinFromFile" and "stdoutToFile" to might be best solution. BTW, what kind of additional information do I have to add here? I think I mentioned all the details of the sitution but I see the "needs more info" label.
I've spent 3 hours trying to come up with a work around. This is insane. So much of my workflow relied on the ability the redirect stdin and stdout using <,. It's insane that this was deprecated. I don't even get why. It doesn't have to do any crazy checking should just copying what you type in and the shell takes over. This is a serious issue for me. !
If it's about "escaping shell-specific characters" then I could live with this. And if it's about anything else shell then give me something like this:
Sorry for the trouble. Like I said, I didn't realize that people were depending on this behavior, and I agree that it should be supported somehow, since this is a reasonable and useful workflow. To me, "args" means arguments that get passed to the program you are starting. I see a couple solutions Restore the behavior of and require users to shell-escape args in their own config, which is not good, or add which would be shell-escaped Keep the behavior of and add or , or the more specific Any of this will require changes to DAP. I wonder whether anyone is trying to use any shell syntax besides /<, in other words, is there a scenario that adding wouldn't cover?
In my opinion, the second way Keep the behavior of and add or , or the more specific is better workaround since we can prevent use of different way from its real meaning.
just a few comments from vacation... VS Code knows nothing about properties. Some debug extensions introduce in their schema contribution but VS Code cannot provide any direct help with redirecting input/output. VS Code supports/implements the DAP request which some debug extensions use to implement their (private) support. does not allow direct access to shell features (e.g. input/output redirection) because no assumptions can be made about the underlying shell or whether a shell is used at all. So escaping/quoting all shell meta-characters is correct. But we might want to add additional features to the DAP request so that debug adapters can implement / property support themselves.
Code change:
command += ' '; } for (const a of args) { <del> command += `${quote(a)} `; </del> <ins> command += (a === '<' || a === '>') ? a : quote(a); command += ' '; </ins> } break; }

Related discussion:
text: a debug extension can introduce an alternative property that supports shell features, e.g. a property . In order to support this we would have to add support to the DAP request to pass a full command line unchanged to the underlying shell.
is there a scenario that adding stdinFromFile/ stdoutToFile wouldn't cover? Yes. I for one will use aliases that are shell scrips to redirect their input and output to chain together programs.
Yes, this is basically my thinking. But I think I should revert the change as a candidate until we figure out a better solution. could you give me an example so I understand how that wouldn't be covered by this proposal?
"stdinFromFile/stdoutToFile" makes the most sense to me. I would not be in favor of a option in the request since, similar to the initial problem, the DA has no knowledge of the underlying shell.
I wonder whether we could make everyone happy in the meantime by leaving the current fix but special-casing and and not escaping these? You could have the and filename in a single arg but I don't see anyone doing that. And it would make the behavior almost the same as the intended escaping behavior.
If would work with "" instead of "", "" I could live with that. Or what ever you mean by special-casing. I just want it to work again or have some means to do to it again.
I mean the opposite (the in would not be escaped, and in would be escaped)
that seems like an acceptable interim fix to me. As a C++ debug extension author (vGDB), this has also broken my extension on the most recent VSCode build and I've had to suggest users defer on upgrading for now to not break existing workflows.
Thanks. I am going with this solution for the .2 build that will go out next week. Not a perfect fix - as a single argument would have previously redirected output too - but people are using or in all the examples I have seen so far. It will also be in Insiders tomorrow. I noticed another issue with the escaping, , which will also get fixed in Insiders
thanks for the quick fix!
Code change:
@IContextKeyService contextKeyService: IContextKeyService, @ILanguageService private readonly languageService: ILanguageService, @IModelService private readonly modelService: IModelService, <del> @IConfigurationService private readonly _configurationService: IConfigurationService </del> <ins> @IConfigurationService private readonly _configurationService: IConfigurationService, @IAccessibilityService private readonly _accessibilityService: IAccessibilityService </ins> ) { super(); this.element = $('.interactive-result-editor-wrapper'); this.contextKeyService = this._register(contextKeyService.createScoped(this.element)); const scopedInstantiationService = instantiationService.createChild(new ServiceCollection([IContextKeyService, this.contextKeyService])); this.toolbar = this._register(scopedInstantiationService.createInstance(MenuWorkbenchToolBar, this.element, MenuId.ChatCodeBlock, {

Related discussion:
text: We should not translate the PHP parser error messages, but we should localize the strings that appear in the Code UI. !
Code change:
private start(): void { this.textModelResolverService.registerTextModelContentProvider('vscode', { <del> provideTextContent: (uri: URI): Promise<ITextModel | null> | null => { </del> <ins> provideTextContent: async (uri: URI): Promise<ITextModel | null> => { </ins> if (uri.scheme !== 'vscode') { return null; } if (uri.authority === 'schemas') { <del> const schemaModel = this.getSchemaModel(uri); if (schemaModel) { return Promise.resolve(schemaModel); } </del> <ins> return this.getSchemaModel(uri); </ins> } <del> return Promise.resolve(this.preferencesService.resolveModel(uri)); </del> <ins> return this.preferencesService.resolveModel(uri); </ins> } }); } <del> private getSchemaModel(uri: URI): ITextModel | null { let schema = schemaRegistry.getSchemaContributions().schemas[uri.toString()]; if (schema) { const modelContent = JSON.stringify(schema); const languageSelection = this.languageService.createById('jsonc'); const model = this.modelService.createModel(modelContent, languageSelection, uri); const disposables = new DisposableStore(); disposables.add(schemaRegistry.onDidChangeSchema(schemaUri => { if (schemaUri === uri.toString()) { schema = schemaRegistry.getSchemaContributions().schemas[uri.toString()]; model.setValue(JSON.stringify(schema)); } })); disposables.add(model.onWillDispose(() => disposables.dispose())); return model; } return null; </del> <ins> private getSchemaModel(uri: URI): ITextModel { let schema = schemaRegistry.getSchemaContributions().schemas[uri.toString()] ?? {} /* Use empty schema if not yet registered */; const modelContent = JSON.stringify(schema); const languageSelection = this.languageService.createById('jsonc'); const model = this.modelService.createModel(modelContent, languageSelection, uri); const disposables = new DisposableStore(); disposables.add(schemaRegistry.onDidChangeSchema(schemaUri => { if (schemaUri === uri.toString()) { schema = schemaRegistry.getSchemaContributions().schemas[uri.toString()]; model.setValue(JSON.stringify(schema)); } })); disposables.add(model.onWillDispose(() => disposables.dispose())); return model; </ins> } dispose(): void {

Related discussion:
text: There should be an action Switch to Insiders... in the settings gear icon in the bottom left corner, do you have that?
uninstalled installed all extensions, including- C# v2.0.328, autopep8 -for python, ctrl+shift+p - selected -format this document with - seleceted C#- All things worked again.
Code change:
} if (runSource === TaskRunSource.User) { const workspaceTasks = await this.getWorkspaceTasks(); <del> RunAutomaticTasks.promptForPermission(this, this._storageService, this._notificationService, this._workspaceTrustManagementService, this._openerService, this._configurationService, workspaceTasks); </del> <ins> RunAutomaticTasks.runWithPermission(this, this._storageService, this._notificationService, this._workspaceTrustManagementService, this._openerService, this._configurationService, workspaceTasks); </ins> } return executeTaskResult; } catch (error) {

Related discussion:
text: Type: <bBug</bVSCode, create a folder named, for instance, "XXXX". that folder create another called .vscode .vscode create a file named with this content: VSCode sure the setting "task.allowAutomaticTasks" is not set or is set to its defautl value "auto". "XXXX" with VSCode. VSCode will run "echo Hello" without asking you whether you want to run tasks configured with "runOn": "folderOpen" or not. VS Code version: Code 1.70.2 (, 2022-08-16T05:35:13.448Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
This happens because you have presumably opened a trusted workspace - which is now when we allow these to be run if the setting is "auto" for allow automatic task
The described behavior is how it is expected to work. If you disagree, please explain what is expected and what is not in more detail. See also our . Happy Coding!
! If I understood it correctly, the popup that supposedly asks you whether you want to run these tasks is not actually meant to appear ever because if the workspace is trusted it will be executed without asking you and if it is not trusted then it will just not exeute them instead of asking you. Doesn't it look kinda pointless to have in the description of the option of the configuration "Prompt for permission for each folder"? You are never prompted anyways.
I this configuration and I am still not prompted anyways:
No I did not. Please next time ask the user if he did X before assuming it and closing the issue. I tried reproducing the problem with and without a trusted workspace and the problem persists anyways.
i'll investigate this that shouldn't happen
Tasks will only run in trusted workspaces, so I will update the setting description to indicate that. Also need to fix the prompt not happening per folder.