jiebi/CodeConvo huggingface dataset:
Code change:
VSCode Version:1.6 insiders OS Version: doesn't matter All settings related to css, sass, less, html, json and markdown. This might be because these come from extensions that are built in?
I've gone through the builtin extensions and opened new issues for each one that is missing setting localization. Please met me know if I missed any

Related discussion:
text: { "markdown.preview.title" : "Open Preview", "markdown.previewSide.title" : "Open Preview to the Side", <del> "markdown.showSource.title" : "Show Source" </del> <ins> "markdown.showSource.title" : "Show Source", "markdown.styles.dec": "A list of URLs or local paths to CSS style sheets to use from the markdown preview. Relative paths are interpreted relative to the folder open in the explorer. If there is no open folder, they are interpreted relative to the location of the markdown file. All '' need to be written as ''.", "markdown.previewFrontMatter.dec": "Sets how YAML front matter should be rendered in the markdown preview. 'hide' removes the front matter. Otherwise, the front matter is treated as markdown content" </ins> }  No newline at end of file
Code change:
VSCode Version: 1.6.0 OS Version: OSX 10.11.6 *.ini files comments-line starts with the SEMI-COLON. but VSCode has insert (or remove) the HASHMARK.
Pull request pushed, thanks a lot !

Related discussion:
text: <ins> { "comments": { "lineComment": ";", "blockComment": [ ";", " " ] }, "brackets": [ ["{", "}"], ["[", "]"], ["(", ")"] ], "autoClosingPairs": [ ["{", "}"], ["[", "]"], ["(", ")"], [""", """], ["'", "'"] ], "surroundingPairs": [ ["{", "}"], ["[", "]"], ["(", ")"], [""", """], ["'", "'"] ] } </ins>  No newline at end of file
Code change:
VSCode Version: 1.6.0 OS Version: OSX 10.11.6 *.ini files comments-line starts with the SEMI-COLON. but VSCode has insert (or remove) the HASHMARK.
Pull request pushed, thanks a lot !

Related discussion:
text: <del> { "comments": { "lineComment": "#", "blockComment": [ "#", " " ] }, "brackets": [ ["{", "}"], ["[", "]"], ["(", ")"] ], "autoClosingPairs": [ ["{", "}"], ["[", "]"], ["(", ")"], [""", """], ["'", "'"] ], "surroundingPairs": [ ["{", "}"], ["[", "]"], ["(", ")"], [""", """], ["'", "'"] ] } </del>  No newline at end of file
Code change:
VSCode Version: 1.6.0 OS Version: OSX 10.11.6 *.ini files comments-line starts with the SEMI-COLON. but VSCode has insert (or remove) the HASHMARK.
Pull request pushed, thanks a lot !

Related discussion:
text: "contributes": { "languages": [{ "id": "ini", <del> "extensions": [ ".ini", ".properties", ".gitconfig" ], "filenames": ["config", ".gitattributes", ".gitconfig", "gitconfig", ".editorconfig"], </del> <ins> "extensions": [ ".ini"], </ins> "aliases": [ "Ini", "ini" ], <del> "configuration": "./language-configuration.json" }], </del> <ins> "configuration": "./ini.language-configuration.json" }, { "id": "properties", "extensions": [ ".properties", ".gitconfig" ], "filenames": ["config", ".gitattributes", ".gitconfig", "gitconfig", ".editorconfig"], "aliases": [ "properties", "properties" ], "configuration": "./properties.language-configuration.json" } ], </ins> "grammars": [{ "language": "ini", "scopeName": "source.ini", <del> "path": "./syntaxes/Ini.plist" </del> <ins> "path": "./syntaxes/Ini.tmLanuage" },{ "language": "properties", "scopeName": "source.properties", "path": "./syntaxes/properties.plist" </ins> }] } }
Code change:
VSCode Version: 1.6.0 OS Version: OSX 10.11.6 *.ini files comments-line starts with the SEMI-COLON. but VSCode has insert (or remove) the HASHMARK.
Pull request pushed, thanks a lot !

Related discussion:
text: <ins> { "comments": { "lineComment": "#", "blockComment": [ "#", " " ] }, "brackets": [ ["{", "}"], ["[", "]"], ["(", ")"] ], "autoClosingPairs": [ ["{", "}"], ["[", "]"], ["(", ")"], [""", """], ["'", "'"] ], "surroundingPairs": [ ["{", "}"], ["[", "]"], ["(", ")"], [""", """], ["'", "'"] ] } </ins>  No newline at end of file
Code change:
VSCode Version: 1.6.0 OS Version: OSX 10.11.6 *.ini files comments-line starts with the SEMI-COLON. but VSCode has insert (or remove) the HASHMARK.
Pull request pushed, thanks a lot !

Related discussion:
text: <ins> <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>fileTypes</key> <array> <string>ini</string> <string>INI</string> <string>inf</string> <string>INF</string> <string>reg</string> <string>REG</string> <string>lng</string> <string>cfg</string> <string>CFG</string> <string>url</string> <string>URL</string> <string>.editorconfig</string> </array> <key>name</key> <string>INI</string> <key>patterns</key> <array> <dict> <key>captures</key> <dict> <key>1</key> <dict> <key>name</key> <string>punctuation.definition.comment.ini</string> </dict> </dict> <key>match</key> <string>^s*(;|#).*$n?</string> <key>name</key> <string>comment.line.semicolon.ini</string> </dict> <dict> <key>captures</key> <dict> <key>1</key> <dict> <key>name</key> <string>punctuation.definition.section.ini</string> </dict> <key>2</key> <dict> <key>name</key> <string>entity.section.ini</string> </dict> <key>3</key> <dict> <key>name</key> <string>punctuation.definition.section.ini</string> </dict> </dict> <key>match</key> <string>^s*([)(.*?)(])</string> <key>name</key> <string>meta.tag.section.ini</string> </dict> <dict> <key>captures</key> <dict> <key>1</key> <dict> <key>name</key> <string>meta.property.ini</string> </dict> <key>2</key> <dict> <key>name</key> <string>punctuation.definition.quote.ini</string> </dict> <key>3</key> <dict> <key>name</key> <string>keyword.name.ini</string> </dict> <key>4</key> <dict> <key>name</key> <string>punctuation.definition.quote.ini</string> </dict> <key>5</key> <dict> <key>name</key> <string>punctuation.definition.equals.ini</string> </dict> <key>6</key> <dict> <key>name</key> <string>meta.value.ini</string> </dict> <key>7</key> <dict> <key>name</key> <string>punctuation.definition.quote.ini</string> </dict> <key>8</key> <dict> <key>name</key> <string>string.name.value.ini</string> </dict> <key>9</key> <dict> <key>name</key> <string>punctuation.definition.quote.ini</string> </dict> <key>10</key> <dict> <key>name</key> <string>comment.declarationline.semicolon.ini</string> </dict> </dict> <key>match</key> <string>^(s*(["']?)(.+?)(2)s*(=))?s*((["']?)(.*?)(7))s*(;.*)?$n?</string> <key>name</key> <string>meta.declaration.ini</string> </dict> </array> <key>scopeName</key> <string>source.ini</string> <key>uuid</key> <string>957acd74-6d7c-4732-a25b-5f66a1e637cd</string> </dict> </plist> </ins>
Code change:
VSCode Version: Code 1.7.2 (, 2016-11-21T22:14:18.217Z) OS Version: Linux x64 4.8.0-26-generic Focus on debug: ! Focus on extensions: ! Can the bright one be on debug as well?
For me all viewlets show the same feedback once focussed: ! Please clarify the issue you see.
Oh I mean via tab focus.
! still they all look the same to me?
I see what you mean, when you focus into the current active viewlet, the orange bar to the left shows up stronger. I am not sure who this, I think might be the one?
This issue has been closed automatically because it needs more information and has not had recent activity. Please refer to our for filing issues. Thank you for your contributions.
Closing as designed, no plans to change it currently.

Related discussion:
text: } public get lineNumbers(): number[] { return this._lineNumbers; }
Code change:
VSCode Version: Code 1.7.2 (, 2016-11-21T22:14:18.217Z) OS Version: Linux x64 4.8.0-26-generic Focus on debug: ! Focus on extensions: ! Can the bright one be on debug as well?
For me all viewlets show the same feedback once focussed: ! Please clarify the issue you see.
Oh I mean via tab focus.
! still they all look the same to me?
I see what you mean, when you focus into the current active viewlet, the orange bar to the left shows up stronger. I am not sure who this, I think might be the one?
This issue has been closed automatically because it needs more information and has not had recent activity. Please refer to our for filing issues. Thank you for your contributions.
Closing as designed, no plans to change it currently.

Related discussion:
text: const renderLineInput: RenderLineInput = new RenderLineInput(true, true, lineRenderingData.content, lineRenderingData.continuesWithWrappedLine, lineRenderingData.isBasicASCII, lineRenderingData.containsRTL, 0, lineRenderingData.tokens, actualInlineDecorations, lineRenderingData.tabSize, lineRenderingData.startVisibleColumn,
Code change:
VSCode Version: Code 1.7.2 (, 2016-11-21T22:14:18.217Z) OS Version: Linux x64 4.8.0-26-generic Focus on debug: ! Focus on extensions: ! Can the bright one be on debug as well?
For me all viewlets show the same feedback once focussed: ! Please clarify the issue you see.
Oh I mean via tab focus.
! still they all look the same to me?
I see what you mean, when you focus into the current active viewlet, the orange bar to the left shows up stronger. I am not sure who this, I think might be the one?
This issue has been closed automatically because it needs more information and has not had recent activity. Please refer to our for filing issues. Thank you for your contributions.
Closing as designed, no plans to change it currently.

Related discussion:
text: } else if (minimapSide === 'right') { this._rootDomNode.style.marginLeft = '0px'; } <ins> this._rootDomNode.style.zIndex = '11'; </ins> } public getId(): string {
Code change:
VSCode Version: 1.7.2 OS Version: Windows Server 2008/2012 Steps to Reproduce: No shortcut (underline) for flie right click context menu. ! Such underline shortcut is very useful to fast open the file with VSCode with keyboard.
Are there any recommendations/specifications as to what the shortcut should be for this?
I think the installer is not in the repo ;)

Related discussion:
text: NameVersion: product.win32NameVersion, ExeBasename: product.nameShort, RegValueName: product.win32RegValueName, <ins> ShellNameShort: product.win32ShellNameShort, </ins> AppMutex: product.win32MutexName, AppId: product.win32AppId, AppUserId: product.win32AppUserModelId,
Code change:
VSCode Version: 1.7.2 OS Version: Windows Server 2008/2012 Steps to Reproduce: No shortcut (underline) for flie right click context menu. ! Such underline shortcut is very useful to fast open the file with VSCode with keyboard.
Are there any recommendations/specifications as to what the shortcut should be for this?
I think the installer is not in the repo ;)

Related discussion:
text: "win32RegValueName": "CodeOSS", "win32AppId": "{{E34003BB-9E10-4501-8C11-BE3FAA83F23F}", "win32AppUserModelId": "Microsoft.CodeOSS", <ins> "win32ShellNameShort": "C&ode - OSS", </ins> "darwinBundleIdentifier": "com.visualstudio.code.oss", "reportIssueUrl": "https://github.com/Microsoft/vscode/issues/new", "urlProtocol": "code-oss"
Code change:
Steps to Reproduce: panel, maximizes the panel out, the panel is no longer maximized but still much larger than usual panel, maximizes the panel
Fixed by

Related discussion:
text: this.statusbarHeight = isStatusbarHidden ? 0 : this.partLayoutInfo.statusbar.height; this.titlebarHeight = isTitlebarHidden ? 0 : this.partLayoutInfo.titlebar.height / getZoomFactor(); // adjust for zoom prevention <ins> const previousMaxPanelHeight = this.sidebarHeight - MIN_EDITOR_PART_HEIGHT; </ins> this.sidebarHeight = this.workbenchSize.height - this.statusbarHeight - this.titlebarHeight; let sidebarSize = new Dimension(sidebarWidth, this.sidebarHeight);
Code change:
Steps to Reproduce: panel, maximizes the panel out, the panel is no longer maximized but still much larger than usual panel, maximizes the panel
Fixed by

Related discussion:
text: const maxPanelHeight = sidebarSize.height - MIN_EDITOR_PART_HEIGHT; if (isPanelHidden) { panelHeight = 0; <ins> } else if (this.panelHeight === previousMaxPanelHeight) { panelHeight = maxPanelHeight; </ins> } else if (this.panelHeight > 0) { panelHeight = Math.min(maxPanelHeight, Math.max(this.partLayoutInfo.panel.minHeight, this.panelHeight)); } else {
Code change:
Test item VSCode Version: Code - Insiders 1.9.0-insider (, 2017-01-24T10:29:13.076Z) OS Version: Darwin x64 15.6.0 Extensions: None Steps to Reproduce: with: after in some size : : Same goes for single line expansions, although there it is not as bad because it is just one arrow-left key to correct.
Another CSS example is . Pressing when done should land the caret at the end of the line.
This is due to the way snippets get expanded. Take the below example of a snippet When you use the above in any file and after you enter the placeholder followed by ENTER, the cursor remains where the entry was made and does not go to end of line Is there any way to get the cursor to the end of the snippet after completion?
Yes, is the final cursor position which default to the end of the snippet. The sample above it is used to place the cursor elsewhere. Changing above to should do it.
! So the being the final cursor position is a standard behavior for snippets in general or is this VS Code specific rule? The reason I ask is, in order to fix this bug if I make an update to then I wonder if I will be breaking any other editor that uses emmet If it is vscode specific, then I'll make the fix on our end
That's a good question. It is default Textmate behaviour but I don't know if emmet is also Textmate...
emmet does borrow from text mate
Very cool!

Related discussion:
text: import * as strings from 'vs/base/common/strings'; import { Range } from 'vs/editor/common/core/range'; import * as editorCommon from 'vs/editor/common/editorCommon'; <del> import * as collections from 'vs/base/common/collections'; </del> import { Marker, Variable, Placeholder, Text, SnippetParser } from 'vs/editor/contrib/snippet/common/snippetParser'; export interface IIndentationNormalizer {
Code change:
Test item VSCode Version: Code - Insiders 1.9.0-insider (, 2017-01-24T10:29:13.076Z) OS Version: Darwin x64 15.6.0 Extensions: None Steps to Reproduce: with: after in some size : : Same goes for single line expansions, although there it is not as bad because it is just one arrow-left key to correct.
Another CSS example is . Pressing when done should land the caret at the end of the line.
This is due to the way snippets get expanded. Take the below example of a snippet When you use the above in any file and after you enter the placeholder followed by ENTER, the cursor remains where the entry was made and does not go to end of line Is there any way to get the cursor to the end of the snippet after completion?
Yes, is the final cursor position which default to the end of the snippet. The sample above it is used to place the cursor elsewhere. Changing above to should do it.
! So the being the final cursor position is a standard behavior for snippets in general or is this VS Code specific rule? The reason I ask is, in order to fix this bug if I make an update to then I wonder if I will be breaking any other editor that uses emmet If it is vscode specific, then I'll make the fix on our end
That's a good question. It is default Textmate behaviour but I don't know if emmet is also Textmate...
emmet does borrow from text mate
Very cool!

Related discussion:
text: } static fromEmmet(template: string): CodeSnippet { <del> return EmmetSnippetParser.parse(template); </del> <ins> let matchFinalStops = template.match(/${0}|$0/g); if (!matchFinalStops || matchFinalStops.length === 1) { return CodeSnippet.fromTextmate(template); } // Emmet sometimes returns snippets with multiple ${0} // In such cases, replace ${0} with incremental tab stops const snippetMarkers: Marker[] = new SnippetParser(true, false).parse(template) || []; let getMaxTabStop = (markers: Marker[]): number => { let currentMaxTabStop = -1; markers.forEach(marker => { if (marker instanceof Placeholder && /^d+$/.test(marker['name'])) { let currentTabStop = Number(marker['name']); let nestedMaxTabStop = getMaxTabStop(marker['defaultValue'] || []); currentMaxTabStop = Math.max(currentMaxTabStop, currentTabStop, nestedMaxTabStop); } }); return currentMaxTabStop; }; let maxTabStop = getMaxTabStop(snippetMarkers); let setNextTabStop = (markers: Marker[]) => { markers.forEach(marker => { if (marker instanceof Placeholder) { if (marker['name'] === '0') { marker['name'] = ++maxTabStop + ''; } setNextTabStop(marker['defaultValue'] || []); } }); }; setNextTabStop(snippetMarkers); const snippet = new CodeSnippet(); _fillCodeSnippetFromMarker(snippet, snippetMarkers); return snippet; </ins> } public lines: string[] = [];
Code change:
Test item VSCode Version: Code - Insiders 1.9.0-insider (, 2017-01-24T10:29:13.076Z) OS Version: Darwin x64 15.6.0 Extensions: None Steps to Reproduce: with: after in some size : : Same goes for single line expansions, although there it is not as bad because it is just one arrow-left key to correct.
Another CSS example is . Pressing when done should land the caret at the end of the line.
This is due to the way snippets get expanded. Take the below example of a snippet When you use the above in any file and after you enter the placeholder followed by ENTER, the cursor remains where the entry was made and does not go to end of line Is there any way to get the cursor to the end of the snippet after completion?
Yes, is the final cursor position which default to the end of the snippet. The sample above it is used to place the cursor elsewhere. Changing above to should do it.
! So the being the final cursor position is a standard behavior for snippets in general or is this VS Code specific rule? The reason I ask is, in order to fix this bug if I make an update to then I wonder if I will be breaking any other editor that uses emmet If it is vscode specific, then I'll make the fix on our end
That's a good question. It is default Textmate behaviour but I don't know if emmet is also Textmate...
emmet does borrow from text mate
Very cool!

Related discussion:
text: for (const originalPlaceHolder of this.placeHolders) { let resultOccurences = []; <del> for (let {startLineNumber, startColumn, endLineNumber, endColumn} of originalPlaceHolder.occurences) { </del> <ins> for (let { startLineNumber, startColumn, endLineNumber, endColumn } of originalPlaceHolder.occurences) { </ins> if (startColumn > 1 || startLineNumber === 1) { // placeholders that aren't at the beginning of new snippet lines
Code change:
This must have broken recently: !
The content is actually there in the DOM: !
Jan candidate?

Related discussion:
text: } public getHeight(tree: ITree, element: any): number { <del> if (element instanceof Variable) { </del> <ins> if (element instanceof Variable && (element.hasChildren || (element.name !== null))) { </ins> return ReplExpressionsRenderer.LINE_HEIGHT_PX; } if (element instanceof Expression && element.hasChildren) {
Code change:
<!-- Do you have a question? Please ask it on --- VSCode Version: 1.9.1 OS Version: Win 7/64 Home Premium SP 1 Please introduce a setting (ideally changeable via API) to allow an output window (panel) to NOT word-wrap. Reason: I've modified the TODO Parser extension () to write its output in tabular form, which is more concise length-wise. However, the unavoidable word wrapping in the output window usually messes up the formatting. In such cases, it would be preferable for an extension to be able to open an output window that DIDN'T word wrap, and allowed the user to scroll horizontally if required. This suggestion was mentioned as an aside at
This should be possible using language specific settings "[Log]": { "editor.minimap.enabled": false }
I think this issue was closed in error. It is not about the minimap, and changing minimap settings does not affect the output window's wrapping. This doesn't make any difference either: "[Log]":{"editor.wordWrap": "off"} Here's an image of the output window as it currently behaves with a single long line of text. I'd like the option to have this displayed as one line with scrollbar. !
Thanks for reopening. :)

Related discussion:
text: options.minimap = { enabled: false }; const outputConfig = this.baseConfigurationService.getValue('[Log]'); <del> if (outputConfig && outputConfig['editor.minimap.enabled']) { options.minimap = { enabled: true }; </del> <ins> if (outputConfig) { if (outputConfig['editor.minimap.enabled']) { options.minimap = { enabled: true }; } if ('editor.wordWrap' in outputConfig) { options.wordWrap = outputConfig['editor.wordWrap']; } </ins> } return options;
Code change:
From For a file such as: We currently do not recognize the file as python even though the internal python extension's contribution matches. The reason is that the entire first line has to match: This seems inconsistent with how TextMate uses , and some of our grammars use patterns that do not work well with this restriction, such as : which fails to match:
and Adding you since I had trouble tracking down who implemented the logic in originally. Do you know why we currently require the entire line to match? Can we do like the xml grammar and add to the end of some of the contributions?
sorry I cannot answer this question, the code was a long time ago (I think by ) and since then has not been touched. I am fine changing this so that we align with TextMate's way of doing things. Happy to review a PR if you are interested.

Related discussion:
text: continue; } <del> // Make sure the entire line matches, not just a subpart. </del> let matches = firstLine.match(association.firstline); <del> if (matches && matches.length > 0 && matches[0].length === firstLine.length) { </del> <ins> if (matches && matches.length > 0) { </ins> return association.mime; } }
Code change:
From For a file such as: We currently do not recognize the file as python even though the internal python extension's contribution matches. The reason is that the entire first line has to match: This seems inconsistent with how TextMate uses , and some of our grammars use patterns that do not work well with this restriction, such as : which fails to match:
and Adding you since I had trouble tracking down who implemented the logic in originally. Do you know why we currently require the entire line to match? Can we do like the xml grammar and add to the end of some of the contributions?
sorry I cannot answer this question, the code was a long time ago (I think by ) and since then has not been touched. I am fine changing this so that we align with TextMate's way of doing things. Happy to review a PR if you are interested.

Related discussion:
text: guess = guessMimeTypes('Randomfile.noregistration', 'RegexesAreNice'); assert.deepEqual(guess, ['text/nice-regex', 'text/plain']); <del> guess = guessMimeTypes('Randomfile.noregistration', 'RegexesAreNiceee'); </del> <ins> guess = guessMimeTypes('Randomfile.noregistration', 'RegexesAreNotNice'); </ins> assert.deepEqual(guess, ['application/unknown']); guess = guessMimeTypes('Codefile', 'RegexesAreNice');