jiebi/CodeConvo huggingface dataset:
Change:
} } <del> const firstLineRange = (originalRange: IRange) => ({ </del> <ins> const collapseRange = (originalRange: IRange) => ({ </ins> startLineNumber: originalRange.startLineNumber, endLineNumber: originalRange.startLineNumber, <del> startColumn: 0, endColumn: Number.MAX_SAFE_INTEGER, </del> <ins> startColumn: originalRange.startColumn, endColumn: originalRange.startColumn, </ins> }); const createRunTestDecoration = (tests: readonly IncrementalTestCollectionItem[], states: readonly (TestResultItem | undefined)[], visible: boolean): IModelDeltaDecoration => {

Discussion:
Using the test-provider-sample, adding newlines on a line marked as a test duplicates the test icon: ! It sorts itself out on the next update (at least in the sample, I'm still investigating to figure out if there's another issue, or that's in my extension). But it still looks bad - especially if a language is debouncing edits and/or discovery may be slow.. You can make the issue more pronounced (as I did for the GIF) by updating the test-provider-sample to have a delay in its updates:
I was able to repro the full issue I'm seeing in Dart (where the icons never disappear) using the sample too: ! My changes to the sample are here: I changed it so that tests can span multiple lines (since the original code split on lines then searched each line) and use the full range as the for the test. Now when pressing in the test, the original issue (VS Code duplicate the icons) still occurs, but also after the updates, since the range computed by the provider doesn't change from the range VS Code currently has (at least that's my guess), there's no update to the gutter icons so they no longer get cleaned up.
That's correct, we let the editor do its default decoration tracking until an update is received from the extension. for testing decorations, I already set , but is there a similar option to avoid extending the range over lines when edited? Or, alternatively, a way to only apply the glyphMarginClassName to the first line of the range. Reference:
You can create two decorations per test. One which has a range, a hover message, etc. And another one which renders the glyph margin with a collapsed range (perhaps the start position of the range). If you use for the second one, given it begins as a collapsed range, it will never grow, it will always remain a collapsed range.
Change:
this.feedbackDescriptionInput.value = ''; } this.sentiment = 1; <ins> this.maxFeedbackCharacters = this.feedbackService.getCharacterLimit(this.sentiment); </ins> this.aliasEnabled = false; } }

Discussion:
Due to being appended to it !
this looks like a good place to start off, is this something I can help with?
:+1: it's marked help wanted which probably means won't get to it any time soon.
Go for it, this is a great issue to start contributing to Code. Let me know if you need any help.
Awesome, I am on it! :)
Please review :) Couldn't find any unit tests for this, did I miss it?
Change:
this.setEventHandlers(data); ipcRenderer.on('vscode:pidToNameResponse', (event: unknown, pidToNames: [number, string][]) => { <del> this.mapPidToName = new Map<number, string>(); </del> <ins> this.mapPidToName.clear(); </ins> for (const [pid, name] of pidToNames) { this.mapPidToName.set(pid, name);

Discussion:
Steps to Reproduce: the repository the "Tasks: Run Build Task" to the "Debug" view, select the "VS Code" launch configuration and press "Start" CodeOSS starts open the process explorer Expected behaviour: fileWatcher process is running Actual behaviour: fileWatcher process is not running //cc
I am not able to reproduce, but I think sometimes sees it too. Maybe a race condition with the thing.
I think this is what I experienced in
If someone can experience this consistently, it'd be useful to stick a in the "Attach to Shared Process" launch config and share the resulting log file, the location of which is written to the Debug Console (may need to select the specific session in the dropdown)
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
[adding message to avoid auto-close]
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
This was actually a bug in the process explorer: it didn't update its pid/name mapping correctly so it showed the file watcher as a generic "utility-process" in some cases
Is there a way to verify? Seems that the original steps only triggered the issue sometimes.
VS Code the process explorer. Note there is a file watcher process the window, keeping the process explorer open that you see the new file watcher process appear
Change:
inputValidationErrorForeground: (style && style.inputValidationErrorForeground) || inputValidationErrorForeground, listFocusBackground: (style && style.listFocusBackground) || listFocusBackground, listFocusForeground: (style && style.listFocusForeground) || listFocusForeground, <del> listActiveSelectionBackground: (style && style.listActiveSelectionBackground) || listActiveSelectionBackground, </del> <ins> listActiveSelectionBackground: (style && style.listActiveSelectionBackground) || darken(listActiveSelectionBackground, 0.1), </ins> listActiveSelectionForeground: (style && style.listActiveSelectionForeground) || listActiveSelectionForeground, listFocusAndSelectionBackground: style && style.listFocusAndSelectionBackground || listActiveSelectionBackground, listFocusAndSelectionForeground: (style && style.listFocusAndSelectionForeground) || listActiveSelectionForeground,

Discussion:
fyi Notice how I am using the up / down arrow to focus different elements in the tree. However some of those elements are also selected. So the issue is that there is no distinction if an element is selected, or selected + focused. !
After doing some digging, it turns out that I introduced this bug when fixing some accessibility issues (back in July) with I'll need to revisit the colors used here and see if I can re-use the lighten/darken function while still being accessible.
thanks. That would be great. Also note the same is true for light theme.
Here's what I did to try to find a color that works with our lighten/darken function without having to create a new theme token. is the only function that will pass the cc ratio across both light/dark themes. This is because is already at the lowest ratio (4.5:1) in the light theme and anything lighter will fail. I've created to fix this, below is a comparison of the two: <img width="1562" alt="image" src="https://user-"!
Adding verified
Change:
id: 'editor.action.toggleScreenReaderAccessibilityMode', title: { value: nls.localize('toggleScreenReaderMode', "Toggle Screen Reader Accessibility Mode"), original: 'Toggle Screen Reader Accessibility Mode' }, f1: true, <ins> keybinding: { primary: KeyMod.CtrlCmd | KeyCode.KeyE, weight: KeybindingWeight.WorkbenchContrib + 10, when: accessibilityHelpIsShown } </ins> }); }

Discussion:
Testing ! Shows Ctrl + e , but that is mapped to "Go to file"
your image didn't work
Updated the image.
Verified with Windows.
Verified that this is now working with Linux and Orca
Change:
precondition: ContextKeyExpr.and(ContextKeyExpr.or(TerminalContextKeys.processSupported, TerminalContextKeys.terminalHasBeenCreated), TerminalContextKeys.tabsSingularSelection), run: async (c, accessor) => { let color: string | undefined; <ins> let i = 0; </ins> for (const terminal of getSelectedInstances(accessor) ?? []) { <del> color = await terminal.changeColor(color); </del> <ins> const skipQuickPick = i !== 0; // Always show the quickpick on the first iteration color = await terminal.changeColor(color, skipQuickPick); i++; </ins> } } });

Discussion:
From testing Steps to Reproduce: multiple terminals multiple terminals in the terminal view to change their color to red the terminals still select, select again time run instead Bug Only a single terminal at a time is reset
Change:
} interface GruntTaskDefinition extends vscode.TaskDefinition { task: string; <ins> args?: string[]; </ins> file?: string; }

Discussion:
<!-- Please search existing issues to avoid creating duplicates. --I'd like to provide my grunt tasks with a single argument but the VSCode task system doesn't support arguments for grunt tasks. I was shocked to discover this because I rarely have grunt tasks without arguments. I can of course work around this issue by using the "shell" task type to run grunt with arguments. Here's . <!-- Describe the feature you'd like. --
Starting pointer:
I would like to work on this. Can I start if no one else is on it ?
thank you, go for it! If you could make a sample repo to test out your change and link it here when you make a PR that would help me review your PR faster :)
To verify, use the from the PR to test.
Change:
"allowJs": true, "resolveJsonModule": true, "outDir": "../out/vs", <del> "target": "es2021", </del> "types": [ "keytar", "mocha",

Discussion:
Looks like we have broad support for . Static initialisers are the slight exception as they are only in Safari since ~2months. We might want to special case them, but otherwise we should be good to go:
On native privates: using them will be faster than weak-map-privates but slower than normal properties (much, much slower for Safari):
Some, perf number for some new API native privates - , faster than WeakMap privates but slower than conventional privates slower than []-access needs which need broader adoption because of semantic change.
Upstream issues for private property performance v8 - Webkit -
Change:
{ "id": "typescriptreact", "aliases": [ <ins> "TypeScript JSX", </ins> "TypeScript React", "tsx" ],

Discussion:
The name "TypeScript React" nowadays is non-inclusive of all the libraries/frameworks out there that are built on JSX, but that are not React. React is not the only lib/framework that has JSX syntax! Let's make the field a fair play ground for all JSX libs. This is what I'm referring to: ! (it even shows React's logo) I'm writing an app with , for example. I'm not using React, and "TypeScript React" has no meaning in the context of a Solid app.
Other libs/frameworks include , , , etc.
Changing the display name is easy but we can't change the identifier. Also any new name should still mention react for the sake of all the documentation/tutorials out there that talk about . For example:
has the same issue. If I am in a project, it has nothing to do with React. Can there be a deprecated alias instead? For example, TypeScript JSX appears first, but someone can select (and maybe even it notifies them to prefer ?). It would be much better not to automatically teach people that JSX is React, because it isn't.
could be another friendlier option to alternatives.
I don't understand the association with ? Why not :roll_eyes: And I'm sure I missed some...
If there is a concern of keeping the UI consistent with existing (recent) content written about VS code, then why not treat the change as a depreciation of sorts? First change it to: Typescript JSX (previously Typescript React) Then with time docs can be updated to use the correct "Typescript JSX" and any community made docs/blogs could update as well. Then finally just remove the parentheses part completely when first party Docs are all confirmed updated to refer to it as "Typescript JSX". Even if it's not as direct of a fix, this still allows the root concern to be addressed and gives a nice path for it to happen.
I just wana say that the title is the best candidate for the change but not the identifier i.e . If you change that the whole community would break.
Just introduce an alias and deprecate it slowly in a 2-year frame or somewhat
Couldn't the identifier either: a) change over time the same I suggested the title, and/or b) have the old one kept as an alias?
Nope, identifier shouldn't have to change.

You are talking about the old tooling and others century old editors (i.e vim/neovim) that depends on the identifier to detect/set the file type.
How about a new language type with identifier and display name "TypeScript JSX" with the ts logo and clone of the existing grammar definitions. Set it's precedence in the list higher than . Then can be deprecated and eventually removed at some later date.
Change:
this._toDispose.push(this._editor.onContextMenu((e: IEditorMouseEvent) => this._onContextMenu(e))); this._toDispose.push(this._editor.onDidScrollChange((e: IScrollEvent) => { <del> if (this._contextMenuIsBeingShownCount > 0) { </del> <ins> if (this._contextMenuIsBeingShownCount > 0 && e.scrollTopChanged) { </ins> this._contextViewService.hideContextView(); } }));

Discussion:
Issue Type: <bBug</bI haven't been able to reliably reproduce this, but it happens decently often. To repo: -click on a line in an editor (seems to happen more often if it is not the active line) of the time the context menu will open, but sometimes it just flashes in and disappears My guess is that it feels like some sort of conflict between showing a hover vs the context menu. And I'm not sure if GitLens plays a roll here or not (though it never happens with the native menus). Another observation, it seems to be more likely to happen right after you've switched to a editor as well (either that or just becomes less likely after the menu has been shown already or something). VS Code version: Code - Insiders 1.26.0-insider (, 2018-07-18T05:19:07.488Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<!-- generated by issue reporter --
I think vscodebot is drunk This should be tagged and likely assigned to
it just loves to classify things as terminal :sob:
Looks like this happens when the contributor codelens info gets to the editor which may trigger scroll which dismisses context menus. /cc
possibly related
I saw this issue while testing today.
was the behavior unique to the latest insiders or could you reproduce with stable
I tested only on latest insiders did not try on stable
/confirm still repro on 1.30.0 stable version
/confirm
Sorry, I still this one from time to time. Not fixed, but also no steps. can we add logging when programmatically(?) closing a menu, esp. withing 1sec of opening
do you know if yours is the case that a menu item is triggered immediately (because the menu was drawn under the cursor and mouseup triggers the item) or that it is actually dismissed?
That - unless the command is a no op. I think this happens when I open the context menu but not immediately interact with it. Can it be that while the menu is open and context-key events comes in, causing the menu (native. macOS) to hide?
oh, native case, alright, i'll dig into it
This is now reproducing with the custom context menus as well.

The scrollTop change does not appear to work anymore(fully?). Something to note is that in VS Code, with the custom titlebar enabled or using a mac, it is not possible to scroll the editor with the conext menu open. Thus, dismissing due to a scroll event is now wrong (I think). Dismissal due to scrolling seems like it was for the benefit of monaco more than vs code. See Do you think we could switch to event? This way, I believe, monaco's behavior should be preserved and vs code would not have this event triggered because of the blocking div when a context menu is open.
:+1: That could work well.
Change:
assert.strictEqual(result, '2-test.js'); }); <del> test('Increment file name with prefix version with `-` as separator', function () { </del> <ins> test('Increment file name with prefix version with `_` as separator', function () { </ins> const name = '1_test.js'; const result = incrementFileName(name, false, 'smart'); assert.strictEqual(result, '2_test.js');

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --Version: 1.52.1 Commit: Date: 2020-12-16T16:30:02.420Z Electron: 9.3.5 Chrome: 83.0.4103.122 12.14.1 V8: 8.3.110.13-electron.0 OS: Darwin x64 20.2.0 Steps to Reproduce: a file called in the explorer. that file. that file. new file name is , where it should be . <img width="220" alt="Screenshot 2021-01-05 at 11 08 23" src="https://user-"<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.485 --- <!-- score: 0.474 --<!-- potentialduplicatescomment --
I think the code is in Last time I checked there was also no test case for that.
Thanks. I acknowledge the issue. And we would welcome a PR that neatly fixes this and adds a test, thus adding help wanted label.
Not a Typescript magician here, otherwise I would have provided a pull request.
I can submit a PR. looking at the file/folder checks it looks like these two sets should be . If they look right, I will send a PR for them. File without extension - Version number only, without extension =
makes sense. Make sure to cover with tests and no need to go too fancy! Thanks
One other incrementing that I am not sure about. becomes , without the leading 0. Is this right, or should it maintain the number of leading 0s?
If you have zero leading paddings it usually means the amount of characters should be maintained. So making out of 0999 would be wrong IMO. It should just become 1000. Me two cents.

I agree with
it would be great if you can try this out with vscode insdiers from tomorrow and give us feedback. Thanks to for providing a PR
Will there be a release or how do I get my hands on the right version to test locally?
releases every day. Just get the release tomorrow and you should be good.
Tested the latest insider build. I could not break it. Works for me. Thanks a lot for the contribution.
Thanks for letting us know. Adding verified label.
Change:
import schemaVersion1 from '../common/jsonSchema_v1'; import schemaVersion2, { updateProblemMatchers } from '../common/jsonSchema_v2'; <ins> import { IConfigurationRegistry, Extensions } from 'vs/platform/configuration/common/configurationRegistry'; </ins> schema.definitions = { ...schemaVersion1.definitions, ...schemaVersion2.definitions,

Discussion:
Steps to reproduce: clone open a terminal Debug viewlet Launch client Observe that building never finishes Now switch the terminal to the npm: watch task Observe: building finished. Looks like the terminal is not delivering any output as long as the view is not visible.
are there any differences on when onLineData occurs in the terminal with conpty?
discovered a new issue
Change:
contextValue?: string; /** <ins> * The stack trace associated with the message or failure. */ stackTrace?: TestMessageStackFrame[]; /** </ins> * Creates a new TestMessage that will present as a diff in the editor. * @param message Message to display to the user. * @param expected Expected output.

Discussion:
Currently, messages that are shown when tests fail can only be shown at a single . Often (, , among others) folks want to see the full call stack of the test failure. I propose some API to add this information:
does this track that not only the stack but stack + any stdout would show in same UX? /cc
Yes, output is already trackable and associable to a test case via the API
We are using to record all stdout written by tests. In addition, the is used to record the failure message and stack for each test failure.
UI:
Just check with Joh and this looks good to move into finalized!
do we want to bundle this with any of the other testing proposals (, )?
Change:
resolved "https://registry.yarnpkg.com/vscode-textmate/-/vscode-textmate-7.0.1.tgz#8118a32b02735dccd14f893b495fa5389ad7de79" integrity sha512-zQ5U/nuXAAMsh691FtV0wPz89nSkHbs+IQV8FDk+wew9BlSDhf4UmWGlWJfTR2Ti6xZv87Tj5fENzKf6Qk7aLw== <del> xterm-addon-search@0.9.0-beta.41: version "0.9.0-beta.41" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.9.0-beta.41.tgz#0992da36fe01ff6d71449265a9dabeef7f9d0a3f" integrity sha512-b1vuWR5JZ8QIiObbKkwSzpzf4x0B9hdzGCHJG+PXWT/xbxk65DOe/X9rgrRyOnCWe5ylQGG4DIHTiREigTp0lg== </del> <ins> xterm-addon-search@0.9.0: version "0.9.0" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.9.0.tgz#95278ebb818cfcf882209ae75be96e0bea5d52a5" integrity sha512-aoolI8YuHvdGw+Qjg8g2M4kst0v86GtB7WeBm4F0jNXA005/6QbWWy9eCsvnIDLJOFI5JSSrZnD6CaOkvBQYPA== </ins> xterm-addon-unicode11@0.4.0-beta.3: version "0.4.0-beta.3" resolved "https://registry.yarnpkg.com/xterm-addon-unicode11/-/xterm-addon-unicode11-0.4.0-beta.3.tgz#f350184155fafd5ad0d6fbf31d13e6ca7dea1efa" integrity sha512-FryZAVwbUjKTmwXnm1trch/2XO60F5JsDvOkZhzobV1hm10sFLVuZpFyHXiUx7TFeeFsvNP+S77LAtWoeT5z+Q== <del> xterm-addon-webgl@0.12.0-beta.43: version "0.12.0-beta.43" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.12.0-beta.43.tgz#916ed4e390371403aab0d277097cd8a61be436e8" integrity sha512-hGXfwT6TOmp0tBDiS/iF8s0SLHLd3shJ5zQyS4HNtq99B5cEhHhwaUAZAfjLt5rnUt0kvqR9YWtGsDux5dWVLA== </del> <ins> xterm-addon-webgl@0.12.0: version "0.12.0" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.12.0.tgz#2fba8d31890a122adafa1c2fb945482e2ae12973" integrity sha512-3P5ihdjPnxH6Wrvqjki9UD+duoVrp1fvnO/pSpXP2F1L2GwY6TDNExgj8Yg141vMCNgQbcVqmsTLYEYZxjY92A== </ins> <del> xterm@4.19.0-beta.67: version "4.19.0-beta.67" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.19.0-beta.67.tgz#9a7d79be64469c91bb693b9f5a50b5a22e921cd3" integrity sha512-4bYTnT6g91N5QId1qPaiSvkpsxMQYpuPdPJItvBZFOcQLTuFSX85x5NeFuDvhNqi33eMFPimyGhzH/JvAV1v/Q== </del> <ins> xterm@4.19.0: version "4.19.0" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.19.0.tgz#c0f9d09cd61de1d658f43ca75f992197add9ef6d" integrity sha512-c3Cp4eOVsYY5Q839dR5IejghRPpxciGmLWWaP9g+ppfMeBChMeLa1DCA+pmX/jyDZ+zxFOmlJL/82qVdayVoGQ== </ins>

Discussion:
! cmd+f, do a search clear the text in the find input it says "0 of -1"
was this insiders or code - oss? If the latter can you make sure is updated?
need to see if this reproduces in OSS
doesn't reproduce in the demo... I think I updated before the PR checks had finished maybe so that fix wasn't included?
I tested with my branch of symlinked so that's probably why I wasn't seeing it
yep happens in OSS so the fix is to update in vscode
Change:
'--show-versions': localize('showVersions', "Show versions of installed extensions, when using --list-extension."), '--install-extension (<extension-id> | <extension-vsix-path>)': localize('installExtension', "Installs an extension."), '--uninstall-extension (<extension-id> | <extension-vsix-path>)': localize('uninstallExtension', "Uninstalls an extension."), <del> '--enable-proposed-api <extension-id>': localize('experimentalApis', "Enables proposed API features for an extension.") </del> <ins> '--enable-proposed-api (<extension-id>)': localize('experimentalApis', "Enables proposed API features for extensions. Can receive one or more extension IDs to enable individually.") </ins> }; const troubleshootingHelp: { [name: string]: string; } = {

Discussion:
testing : I was running "code-insiders" with the "--enable-proposed-api" option without noticing that the option requires an extension ID. This should be fixed either by reporting an error and aborting "code", or by interpreting a missing extension ID as the semantics "enable proposed API for any extension"
Please support the latter
:+1: I was in an endless loop running and then reading the error message . Please don't make me find out the extension id.
Yeah, the error message should simply print the extension id...
fixed vai