jiebi/CodeConvo huggingface dataset:
Change:
VSCode Version: 1.7.2 OS Version: Ubuntu 16.04 I have yet to find out how to reproduce this, but VS Code creates a Microsoft/TypeScript/node_modules/ directory with the types-registry npm module in it in the home directory. The package readme says This is the source code for the types-publisher service, which publishes the contents of DefinitelyTyped to npm. I never set anything to be shared or published. So what exactly is this and what does it do?
Steps to reproduce: VS Code any JavaScript file It only happens for the first JS file that is opened. Could be a bug, too.
I guess this is from the automatic typings acquisition in recent versions of TypeScript. Are you saying the folder is under ?
is correct - this is location of global cache for acquired type declarations. These files are downloaded on user machine to power JavaScript intelligence and never uploaded anywhere.
What are the paths that are used for this cache on the different platforms? I think on Linux it might make sense to used a folder name with a leading '.' to hide it from default and file explorer behavior - like other tools do. /cc
Now that you mention this I have this too. We should absolutely not be putting the types in . would probably make the most sense, where defaulting to if it is not defined as per the . I'm proposing instead of to prevent potential future conflicts. this is actually quite bad imo, is this a purely upstream problem?
This issue was moved to Microsoft/TypeScript
Let's keep this open on vscode to track it. I'd like to mention the fix in release notes when it comes.
This is going into TypeScript 2.2, so we will not be picking it up in VSCode 1.8. You can install a TS 2.2 insiders build to your workspace to work around this for now.

Discussion:
"resolved": "https://registry.npmjs.org/semver/-/semver-4.3.6.tgz" }, "typescript": { <del> "version": "2.1.4", "from": "typescript@2.1.4", "resolved": "https://registry.npmjs.org/typescript/-/typescript-2.1.4.tgz" </del> <ins> "version": "2.1.5-insiders.20161213", "from": "typescript@2.1.5-insiders.20161213", "resolved": "https://registry.npmjs.org/typescript/-/typescript-2.1.5-insiders.20161213.tgz" </ins> }, "vscode-extension-telemetry": { "version": "0.0.5",

"semver": "4.3.6", "vscode-extension-telemetry": "^0.0.5", "vscode-nls": "^2.0.1", <del> "typescript": "2.1.4" </del> <ins> "typescript": "2.1.5-insiders.20161213" </ins> }, "devDependencies": { "@types/semver": "^5.3.30"
Change:
VSCode Version:1.7.2 OS Version: Windows Steps to Reproduce: on a Highlight (h3) or section (h2) link at the top of the in-product release notes page. The page goes blank. This will also happen if you do the same with Markdown preview on This is a regression with 1.7.2. 1.7.0 and 1.7.1 don't have the issue. investigated and has a fix.

Discussion:
'			if (baseElement && node.href.indexOf(baseElement.href) >= 0 && node.hash) {', '				let scrollTarget = window.document.getElementById(node.hash.substr(1, node.hash.length - 1));', '				if (scrollTarget) {', <del> '					scrollgetTarget().scrollIntoView();', </del> <ins> '					scrollTarget.scrollIntoView();', </ins> '				}', '			} else {', '				window.parent.postMessage({ command: "did-click-link", data: node.href }, "file://");',
Change:
VSCode Version: 1.7.2 OS Version: 10.12.1 Steps to Reproduce: a project that is linked to remote a git repositoty. a clone in another dir or ask a friend to modify a file, commit, and push. the same file locally and try to pull. You will get an error saying (emphasis mine): Meanwhile, in the git console you see a different and correct error: The error is that "stash" is the correct action, staging won't help. Here is the line
Fixed by

Discussion:
var result = this.gitService.checkout(this.branch.name).then(null, (err) => { if (err.gitErrorCode === GitErrorCodes.DirtyWorkTree) { <del> return Promise.wrapError(new Error(nls.localize('dirtyTreeCheckout', "Can't checkout. Please commit or stage your work first."))); </del> <ins> return Promise.wrapError(new Error(nls.localize('dirtyTreeCheckout', "Can't checkout. Please commit or stash your work first."))); </ins> } return Promise.wrapError(err);

protected pull(rebase = false): Promise { return this.gitService.pull(rebase).then(null, (err) => { if (err.gitErrorCode === GitErrorCodes.DirtyWorkTree) { <del> return Promise.wrapError(errors.create(nls.localize('dirtyTreePull', "Can't pull. Please commit or stage your work first."), { severity: Severity.Warning })); </del> <ins> return Promise.wrapError(errors.create(nls.localize('dirtyTreePull', "Can't pull. Please commit or stash your work first."), { severity: Severity.Warning })); </ins> } else if (err.gitErrorCode === GitErrorCodes.AuthenticationFailed) { return Promise.wrapError(errors.create(nls.localize('authFailed', "Authentication failed on the git remote."))); }
Change:
VSCode Version: latest insiders OS Version: macOS Steps to Reproduce: any TS or JS file =! /cc fyi (might be TS lint or JS lint update related?) though I also see this when running out of sources without extensions and I only see it since maybe a couple of days.
I have also seen this message, it caused my pull request build to fail I think: https://travis-
I just spent 30 minutes thinking this was me, and I still don't know where it comes from. I kept refreshing the workbench, while a JS file was open and saw it always. We need two fixes here: Fix the rejected promise problem Improve this specific error reporting to be able to catch the culprit...
This message means that a promise got rejected and no-one has attached a reject-handler to it.
Yeah but where does it come from? Could we somehow do a better job figuring that out?
Comes from here:
Yesterday I spent quite some time trying to figure out if my new git code was the culprit. Having found this out, I figured it wasn't. suspects it is somewhere in TypeScript code. Yet, no one knows for sure, it is speculation. Rephrasing my previous question: can we, as Code, provide a better message to indicate where that promise came from?
No, you cannot and that is in the nature of a promise/async code. In contrast to ing an error a promise can be rejected anytime without a meaningful stack trace. Worst, that in this case the promise is rejected without a 
And then a very complex search revealed this:

Discussion:
this.globalState = globalState; this.pathSeparator = path.sep; <del> let p = new Promise<void>((resolve, reject) => { this._onReady = { promise: Promise.reject<void>(null), resolve, reject }; </del> <ins> const p = new Promise<void>((resolve, reject) => { this._onReady = { promise: p, resolve, reject }; </ins> }); this._onReady.promise = p;
Change:
VSCode Version: 1.7.2 or insiders as of today OS Version: win10 x64 There seems to be an issue with suggestWidgetMultipleSuggestions. I am trying to use the following: { "key": "down", "command": "extension.vim_down", "when": "editorTextFocus && !suggestWidgetMultipleSuggestions" } The key is registered correctly up until a suggestion is shown, then it is not correct until vscode is restarted. I tried it without only suggestWidgetMultipleSuggestions and the issue still occurred so I believe that suggestWidgetMultipleSuggestions is the problem. If I had to make a guess, I would guess that it needs the value to be changed back to 0 in hide() here This is causing an issue in Vim where we are using it
Want to submit a PR for it? At the same time, you should probably use instead.
I will try to build from source tonight, we also use suggest widget visible but it is important for us to have both for a few reasons

Discussion:
private hide(): void { this.suggestWidgetVisible.reset(); <ins> this.suggestWidgetMultipleSuggestions.reset(); </ins> removeClass(this.element, 'visible'); }
Change:
Testing have a file that is empty run type the file is dirty close the window run !
This is tricky: on the main side we open one window as instructed from the command line with the file and we also open another window to restore backups. Since we do not actually know the files to restore on the main side (we just rely on the renderer side to do this), we are opening 2 windows without knowing that the same file ends up being opened 2 times. Imho what should happen is this: if we know that we are restoring empty windows with backups, we just add all the files (as instructed from the command line) to one of those empty windows to avoid that we open multiple windows. This should happen in method ideally. We do the same if we are about to open a window with a folder: all other files to open (or create) end up being opened in that window of the folder.
I have a PR up for this via though I am not sure this is the best fix :). Basically what it does is to see if upon startup we have windows opening with hot-exit files to restore (either folder or untitled). If we find any such window to open, we open files to open files to create files to diff inside the first of these windows that upon as a matter of restoring hot-exit data. So instead of getting an extra window opened for the files to open, they would open into the first window that is being opened as a matter of hot-exit restore. what do you think?
I think this is a pretty good fix. It seems to align with how the CLI works when windows are opened as well; instead of opening the files in the last active window, the first window to be restored is selected.
Ok, merged.

Discussion:
openFolderInNewWindow = (windowConfig.openFoldersInNewWindow === 'on'); } <del> // Handle files to open/diff or to create when we dont open a folder if (!foldersToOpen.length && (filesToOpen.length > 0 || filesToCreate.length > 0 || filesToDiff.length > 0)) { </del> <ins> // Handle files to open/diff or to create when we dont open a folder and we do not restore any folder/untitled from hot-exit if (!foldersToOpen.length && !foldersToRestore.length && !emptyToRestore.length && (filesToOpen.length > 0 || filesToCreate.length > 0 || filesToDiff.length > 0)) { </ins> // let the user settings override how files are open in a new window or same window unless we are forced (not for extension development though) let openFilesInNewWindow: boolean;

// Handle empty if (emptyToRestore.length > 0) { emptyToRestore.forEach(emptyWorkspaceBackupFolder => { <del> const configuration = this.toConfiguration(openConfig); </del> <ins> const configuration = this.toConfiguration(openConfig, void 0, filesToOpen, filesToCreate, filesToDiff); </ins> const browserWindow = this.openInBrowserWindow(configuration, true /* new window */, null, emptyWorkspaceBackupFolder); usedWindows.push(browserWindow); <ins> // Reset these because we handled them filesToOpen = []; filesToCreate = []; filesToDiff = []; </ins> openFolderInNewWindow = true; // any other folders to open must open in new window then }); }
Change:
VSCode Version: 1.7.2 OS Version: Windows 10 Steps to Reproduce: a repo with a config like: a .gitattributes that looks like: a file with crlf line endings the file using git add on the command line and commit bar to baz in VS Code and save to the git tab, select the file, Ctrl-A to select everything, and use the ... menu at the top-right to select stage lines diff --staged Expected: One line changed - bar -baz, with the line endings lf (due to autocrlf=true) Actual: Whole file changed, as the line endings have changed to crlf

Discussion:
} async stage(path: string, data: string): Promise<void> { <del> const child = this.stream(['hash-object', '--stdin', '-w'], { stdio: [null, null, null] }); </del> <ins> const child = this.stream(['hash-object', '--stdin', '-w', '--path', path], { stdio: [null, null, null] }); </ins> child.stdin.end(data, 'utf8'); const { exitCode, stdout } = await exec(child);

return { hash: match[1], message: match[2] }; } <del> } </del>  No newline at end of file <ins> } </ins>
Change:
open vscode repo on click inside a test name ! !
Closing as upstream TypeScript issue:
since this is quite disturbing I would suggest to add the following workaround on our end: If the highlight is for the current document we look at the source and filter the match if enclosed in " or '. I know hacky :-). And we pressure for a better fix in the tsserver for the next update. I proposed that they give us a 'type' information for the document highlight request telling us to which SymbolKind the symbol under the cursor resolved.
Another idea to solve this would be as follows: we don't highlight anything if the result only contains one match and contains the current cursor position. This would then convey the information that there aren't any references in the document for that symbol. This might work for most of the strings.
I'm testing the first workaround now, since it seems like the more scoped fix. I agree that we need some additional information back from TypeScript to handle this properly. Highlighting literal string types for example probably makes sense, but not highlighting content strings.
Thank you!

Discussion:
} return this.client.execute('occurrences', args, token).then((response): DocumentHighlight[] => { let data = response.body; <del> if (data) { </del> <ins> if (data && data.length) { // Workaround for https://github.com/Microsoft/TypeScript/issues/12780 // Don't highlight string occurrences const firstOccurrence = data[0]; if (this.client.apiVersion.has213Features() && firstOccurrence.start.offset > 1) { // Check to see if contents around first occurrence are string delimiters const contents = resource.getText(new Range(firstOccurrence.start.line - 1, firstOccurrence.start.offset - 1 - 1, firstOccurrence.end.line - 1, firstOccurrence.end.offset - 1 + 1)); const stringDelimiters = ['"', ''', '`']; if (contents && contents.length > 2 && stringDelimiters.indexOf(contents[0]) >= 0 && contents[0] === contents[contents.length - 1]) { return []; } } </ins> return data.map((item) => { return new DocumentHighlight(new Range(item.start.line - 1, item.start.offset - 1, item.end.line - 1, item.end.offset - 1), item.isWriteAccess ? DocumentHighlightKind.Write : DocumentHighlightKind.Read);
Change:
VSCode Version: Code - Insiders 1.8.0-insider (, 2016-12-09T12:05:39.439Z) OS Version: Linux x64 4.8.0-28-generic Extensions: Steps to Reproduce: an untitled file and add content: the cursor after the shift, press down and then end, the selection should be shift, press home, the selection should be but it is because the select went to the start of the wrong line.
This used to work till yesterday... something broke. I'm pressing <kbdend</kbdafter going 3 lines above, and the cursor goes to the end of the selectionStart line. !

Discussion:
} public static moveToBeginningOfLine(config: CursorConfiguration, model: ICursorSimpleModel, cursor: SingleCursorState, inSelectionMode: boolean): SingleMoveOperationResult { <del> let lineNumber = cursor.selection.startLineNumber; </del> <ins> let lineNumber = cursor.position.lineNumber; </ins> let minColumn = model.getLineMinColumn(lineNumber); let firstNonBlankColumn = model.getLineFirstNonWhitespaceColumn(lineNumber) || minColumn; let column: number; <del> if (cursor.selection.startColumn === firstNonBlankColumn) { </del> <ins> let relevantColumnNumber = cursor.position.column; if (relevantColumnNumber === firstNonBlankColumn) { </ins> column = minColumn; } else { column = firstNonBlankColumn;

} public static moveToEndOfLine(config: CursorConfiguration, model: ICursorSimpleModel, cursor: SingleCursorState, inSelectionMode: boolean): SingleMoveOperationResult { <del> let lineNumber = cursor.selection.endLineNumber; </del> <ins> let lineNumber = cursor.position.lineNumber; </ins> let maxColumn = model.getLineMaxColumn(lineNumber); return SingleMoveOperationResult.fromMove(cursor, inSelectionMode, lineNumber, maxColumn, 0, true, CursorChangeReason.Explicit); }

moveTo(thisCursor, 1, 8); moveTo(thisCursor, 3, 9, true); moveToBeginningOfLine(thisCursor, false); <del> assertCursor(thisCursor, new Selection(1, 6, 1, 6)); </del> <ins> assertCursor(thisCursor, new Selection(3, 5, 3, 5)); </ins> }); test('move to beginning of line with selection multiline backward', () => {

moveTo(thisCursor, 1, 8); moveTo(thisCursor, 3, 9, true); moveToBeginningOfLine(thisCursor, false); <del> assertCursor(thisCursor, new Selection(1, 6, 1, 6)); </del> <ins> assertCursor(thisCursor, new Selection(3, 5, 3, 5)); }); test('issue #17011: Shift+home/end now go to the end of the selection start's line, not the selection's end', () => { moveTo(thisCursor, 1, 8); moveTo(thisCursor, 3, 9, true); moveToBeginningOfLine(thisCursor, true); assertCursor(thisCursor, new Selection(1, 8, 3, 5)); </ins> }); // --------- move to end of line

moveTo(thisCursor, 3, 9); moveTo(thisCursor, 1, 1, true); moveToEndOfLine(thisCursor, false); <del> assertCursor(thisCursor, new Selection(3, 17, 3, 17)); </del> <ins> assertCursor(thisCursor, new Selection(1, 21, 1, 21)); </ins> }); test('move to end of line with selection single line forward', () => {
Change:
The and should be removed
Sorry for question, but why you don't use native ?
stuff in common is still used in very old browser
Fixed in

Discussion:
import processes = require('vs/base/node/processes'); import nls = require('vs/nls'); import errors = require('vs/base/common/errors'); <ins> import { assign } from 'vs/base/common/objects'; </ins> import { TPromise } from 'vs/base/common/winjs.base'; import { ITerminalService } from 'vs/workbench/parts/execution/common/execution'; import { IConfigurationService } from 'vs/platform/configuration/common/configuration';

]; // merge environment variables into a copy of the process.env <del> const env = extendObject(extendObject({}, process.env), envVars); </del> <ins> const env = assign({}, process.env, envVars); </ins> const options: any = { cwd: dir,

termArgs.push(`''${bashCommand}''`);	// wrapping argument in two sets of ' because node is so "friendly" that it removes one set... // merge environment variables into a copy of the process.env <del> const env = extendObject(extendObject({}, process.env), envVars); </del> <ins> const env = assign({}, process.env, envVars); </ins> const options: any = { cwd: dir,

} } <del> function extendObject<T>(objectCopy: T, object: T): T { for (let key in object) { if (object.hasOwnProperty(key)) { objectCopy[key] = object[key]; } } return objectCopy; } </del> /** * Quote args if necessary and combine into a space separated string. */
Change:
VSCode Version: Code 1.8.0 (, 2016-12-13T17:45:32.595Z) OS Version: Windows_NT ia32 10.0. Extensions: Steps to Reproduce: 3 folders called "Folder 1" , "Folder 2" and "Folder 10" 10 appears in between Folder 1 and Folder 2. !
The macOS Finder, for example, handles this case correctly.
do you recall any reason why we are not using the for folders in ?
This actually happens for files and folders. A good area for a PR
As related, can also be included in February Milestone?
Unlikely.

Discussion:
import scorer = require('vs/base/common/scorer'); import strings = require('vs/base/common/strings'); <del> const FileNameMatch = /^([^.]*)(.(.*))?$/; </del> <ins> const FileNameComparer = new Intl.Collator(undefined, { numeric: true, sensitivity: 'base' }); </ins> export function compareFileNames(one: string, other: string): number { <del> let oneMatch = FileNameMatch.exec(one.toLowerCase()); let otherMatch = FileNameMatch.exec(other.toLowerCase()); let oneName = oneMatch[1] || ''; let oneExtension = oneMatch[3] || ''; let otherName = otherMatch[1] || ''; let otherExtension = otherMatch[3] || ''; if (oneName !== otherName) { return oneName < otherName ? -1 : 1; } if (oneExtension === otherExtension) { return 0; } return oneExtension < otherExtension ? -1 : 1; </del> <ins> return FileNameComparer.compare(one || '', other || ''); </ins> } export function compareAnything(one: string, other: string, lookFor: string): number {

test('compareFileNames', () => { <ins> assert(compareFileNames(null, null) === 0, 'null should be equal'); assert(compareFileNames(null, 'abc') < 0, 'null should be come before real values'); </ins> assert(compareFileNames('', '') === 0, 'empty should be equal'); assert(compareFileNames('abc', 'abc') === 0, 'equal names should be equal'); assert(compareFileNames('.abc', '.abc') === 0, 'equal full names should be equal'); <del> assert(compareFileNames('.env', '.env.example') < 0); assert(compareFileNames('.env.example', '.gitattributes') < 0); </del> <ins> assert(compareFileNames('.env', '.env.example') < 0, 'filenames with extensions should come after those without'); assert(compareFileNames('.env.example', '.gitattributes') < 0, 'filenames starting with dots and with extensions should still sort properly'); assert(compareFileNames('1', '1') === 0, 'numerically equal full names should be equal'); assert(compareFileNames('abc1.txt', 'abc1.txt') === 0, 'equal filenames with numbers should be equal'); assert(compareFileNames('abc1.txt', 'abc2.txt') < 0, 'filenames with numbers should be in numerical order, not alphabetical order'); assert(compareFileNames('abc2.txt', 'abc10.txt') < 0, 'filenames with numbers should be in numerical order even when they are multiple digits long'); </ins> }); });

return 1; } <del> if (statA.isDirectory && statB.isDirectory) { return statA.name.toLowerCase().localeCompare(statB.name.toLowerCase()); } </del> if (statA instanceof NewStatPlaceholder) { return -1; }
Change:
Currently the order is: - This creates a visual issue when using different images for and . Currently we on do so and although the associated files get the correct image, in the selection it shows the image and not the image. Changing the order to: - or - should fix the issue.
The issue refers to this
Submitted

Discussion:
{ "id": "diff", "aliases": ["Diff", "diff" ], <del> "extensions": [".patch", ".diff", ".rej"], </del> <ins> "extensions": [".diff", ".patch", ".rej"], </ins> "configuration": "./language-configuration.json" } ],
Change:
VSCode Version: version 1.8.1 OS Version: Windows 10 Steps to Reproduce: an icon theme. a filename that has no extension. e.g. license a file called and it will work as expected a file called and instead of the expected icon, you will see the icon. It seems that filename associations are created by taking the extension of the file as a separated style, thus providing side-effects with without extension. In my opinion, filenames shouldn't have to take into account the extension as a separate css class. The whole file name should be css parsed and used as a class name instead. This would avoid the described issue. See
Another effect is that filenames starting with a dot, like '.gitignore' are being treated as file extensions. This usually works but I have detected what seems to be another bug. In the docs it says: For what I've seen this is not the case and takes precedence in front a : ! As you can see in the image, is being matched as a extension and if a language id is provided (json in this case), the language id prevails against what the docs claims.
I've submitted a PR for this

Discussion:
else { // Name <del> const name = dotSegments[0]; // file.txt => "file", .dockerfile => "", file.some.txt => "file" </del> <ins> const name = dotSegments.join('.'); // get the whole name </ins> if (name) { classes.push(`${cssEscape(name.toLowerCase())}-name-file-icon`); }

for (let fileName in fileNames) { let selectors = []; let segments = fileName.toLowerCase().split('.'); <del> if (segments[0]) { selectors.push(`.${escapeCSS(segments[0])}-name-file-icon`); } </del> <ins> selectors.push(`.${escapeCSS(fileName.toLowerCase())}-name-file-icon`); </ins> for (let i = 1; i < segments.length; i++) { selectors.push(`.${escapeCSS(segments.slice(i).join('.'))}-ext-file-icon`); }