jiebi/CodeConvo huggingface dataset:
Code change:
VSCode Version: 1.5.0 OS Version: OS X 10.11.6 Steps to Reproduce: this snippet to use Then the example Focus is on the newly created terminal and not preserved.
Bug for

Related discussion:
text: public $show(terminalId: number, preserveFocus: boolean): void { this._terminalService.show(!preserveFocus).then((terminalPanel) => { this._terminalService.setActiveTerminalById(terminalId); <ins> if (!preserveFocus) { // If the panel was already showing an explicit focus call is necessary here. terminalPanel.focus(); } </ins> }); }
Code change:
VSCode Version: 1.5.0 OS Version: OS X 10.11.6 Steps to Reproduce: this snippet to use Then the example Focus is on the newly created terminal and not preserved.
Bug for

Related discussion:
text: export interface ITerminalPanel { closeTerminalById(terminalId: number): TPromise<void>; <ins> focus(): void; </ins> sendTextToActiveTerminal(text: string, addNewLine: boolean): void; }
Code change:
VSCode Version: 1.5.0 OS Version: OS X 10.11.6 Steps to Reproduce: this snippet to use Then the example Focus is on the newly created terminal and not preserved.
Bug for

Related discussion:
text: return this.show(false).then((terminalPanel) => { this.activeTerminalIndex = index; terminalPanel.setActiveTerminal(this.activeTerminalIndex); <del> terminalPanel.focus(); </del> this._onActiveInstanceChanged.fire(); }); }
Code change:
VSCode Version: 1.5.3 (commit ) OS Version: Ubuntu Linux 14.04 Steps to Reproduce: some code that prints the characters to the output window. are incorrectly turned into a newline. F# Code: Output: This has already been reported as , but that bug was incorrectly closed as "working as designed" because it was assumed that the code in (I couldn't trace it further back than that). The character sequence is not the ANSI escape for a linefeed/newline; in fact, , since ANSI just uses the single character for that purpose. It's pretty clear, looking at the code, that that's what was the regex was intended to be set to in the lines just above the : it is set to . However, is actually an invalid Javascript hex escape. The specifies that must be followed by two hex digits, because otherwise the sequences (U+0007 BELL) and (U+000C FORM FEED) would be ambiguous. So is an invalid sequence, and is instead interpreted by Javascript as the character followed by the character (the backslash is swallowed). So the correct fix to bug is actually to replace that regex with . Then one could notice that the code immediately below is replacing all occurrences of with , which is a no-op since is . So the regex and the line serve no purpose but to slow things down by spending O(N) time doing a no-op regex search. They can safely be removed without affecting any other code, and this would actually speed things up a fraction.
fyi
Yup, we should look into this and fix
might you be interested into doing a PR that fixes this since you have already done this great analysis? If not, we can follow your analysis to do the changes you proposed. Thanks either way!
Sure, why not? Here's the PR. Do you need me to sign a code licensing agreement of some kind before it can be merged in? If so, let me know how. UPDATE: Oh, I see that MSBOT replied on the PR's comment thread. I'm not surprised that no CLA is required for a commit that removed two lines and none.

Related discussion:
text: // Escape codes // http://en.wikipedia.org/wiki/ANSI_escape_code const EL = /x1Bx5B[12]?K/g; // Erase in line <del> const LF = /xA/g; // line feed </del> const COLOR_START = /x1b[d+m/g; // Color const COLOR_END = /x1b[0?m/g; // Color export function removeAnsiEscapeCodes(str: string): string { if (str) { str = str.replace(EL, ''); <del> str = str.replace(LF, 'n'); </del> str = str.replace(COLOR_START, ''); str = str.replace(COLOR_END, ''); }
Code change:
VSCode Version: 1.6.0 OS Version: windows7 Steps to Reproduce: Create a vscode extension project. Pull off the cable to keep offine. Launch Extension (F5) I cant set breakpoint in my source file. And I find some warn information in Extension Development Host Window : I change the code in Its works. fyi
Sounds like a potential PR fyi
Yeah, PR welcome.
can you elaborate why your change is fixing this? If I look at the docs of I can see that host per default is .
can`t be resolved when being offline. And fyi
thanks

Related discussion:
text: return clb(startPort); }); <del> client.connect(startPort); </del> <ins> client.connect(startPort, '127.0.0.1'); </ins> } function dispose(socket: net.Socket): void {
Code change:
VSCode Version: 1.7.2 () OS Version: Windows 10.0. Steps to Reproduce: a file a sentence of text such as Lorem ipsum sit dolar amet. your keyboard cursor after <kbdTab</kbdExpected: Spaces or tabs to be between and Result: word gets converted into an XML tag and auto closed, leaving us with <Lorem</Loremipsum sit dolar amet. !
This is coming from Emmet. To disable this, add: to your settings. Although this is currently the expected behavior, I think we should probably disable emmet expansions in markdown by default because this behavior can be annoying during normal writing. Any thoughts?
this behaviour is a consequence of , which has as the goal to not hard code in which language modes emmet is enabled for. As a heuristic uses the grammar's scope name hierarchy as a hint. This heuristic has worked pretty well. The scope of the markdown grammar is . This means Markdown is treated as a specialization of and since emmets supports , is enabled in Markdown as well. According the emmet doc there is no special syntax profile available for Markdown So a quick fix would be to: hard code an exclusion for markdown in #isEmmetEnableMode change the scope name of the markdown grammar, so that it doesn't inherit from html, not sure what the consequences of this are. do you have other ideas how to improve the support for emmet in Markdown and avoid the surprise described in this issue?
Hello, I see the same way as you suggested above. But, perhaps, we can also disable Markdown in the settings, as it was for . If you decide to disable Emmet inside Markdown, it is better to first option. But my 2 cents: Markdown is a lightweight markup language and it presupposes the existence of HTML constructs within yourself. Thus, it seems to me, to disable Emmet inside Markdown is not correct. P.S. Small news: the creator of Emmet had already started work on the second version aka 2.0.0
thanks for the feedback. I agree with your point that disabling emmet without some way to re-enable it, if someone really wants emmet is better than to totally disable it. Glad to hear about Emmet 2.0.
Could just be in the default setting for ? That would stop most users from triggering emmet unexpectedly in markdown files, while still allowing users to opt back in to emmet for markdown if they wish
the idea is good. It has a small drawback. If someone defines in the settings, then they will not profit from this fix. However, if someone if familiar with this setting and then they know how to disable emmet in markdown, if they are annoyed by it. Bottom line I'm fine with this fix.
Ok, I've merged in which adds to the default list of excluded languages. Not a perfect solution, but it should stop many users from hitting this behavior unexpectedly

Related discussion:
text: }, 'emmet.excludeLanguages': { 'type': 'array', <del> 'default': [], </del> <ins> 'default': ['markdown'], </ins> 'description': nls.localize('emmetExclude', "An array of languages where emmet abbreviations should not be expanded.") }, }
Code change:
VSCode Version: Code - Insiders 1.8.0-insider (, 2016-12-06T16:53:46.634Z) OS Version: Darwin x64 15.6.0 Testing The current message seems to general: "For better performance exclude folders with many files." "better performance" is to weak because the typescript server basically shutdown and won't provide any of the advanced features. "folders with many files" is vague, it should mention JavaScript/TypeScript files that the user does not work on (like packages/libraries). could also mention that this happens in the js-, that would set the right expectation for the 'Configure Excludes' button and also inform the user how this can be done manually. Needs more thought: "Too many JavaScript/TypeScript files: To enable advanced editor features in JavaScript/TypeScript files exclude large folders with source files you do not work on." /cc
Also, the status bar button might benefit from being specific about the language it refers to.

Related discussion:
text: public show(configFileName: string, largeRoots: string, onExecute: () => void) { this._currentHint = { message: largeRoots.length > 0 <del> ? localize('hintExclude', "For better performance exclude folders with many files, like: {0}", largeRoots) : localize('hintExclude.generic', "For better performance exclude folders with many files."), </del> <ins> ? localize('hintExclude', "To enable JavaScript/TypeScript IntelliSense, exclude folders with many files, like: {0}", largeRoots) : localize('hintExclude.generic', "To enable JavaScript/TypeScript IntelliSense, exclude large folders with source files that you do not work on."), </ins> options: [{ title: localize('open', "Configure Excludes"), execute: () => {
Code change:
VSCode Version: Code - Insiders 1.8.0-insider (, 2016-12-06T16:53:46.634Z) OS Version: Darwin x64 15.6.0 Testing The current message seems to general: "For better performance exclude folders with many files." "better performance" is to weak because the typescript server basically shutdown and won't provide any of the advanced features. "folders with many files" is vague, it should mention JavaScript/TypeScript files that the user does not work on (like packages/libraries). could also mention that this happens in the js-, that would set the right expectation for the 'Configure Excludes' button and also inform the user how this can be done manually. Needs more thought: "Too many JavaScript/TypeScript files: To enable advanced editor features in JavaScript/TypeScript files exclude large folders with source files you do not work on." /cc
Also, the status bar button might benefit from being specific about the language it refers to.

Related discussion:
text: }; this._item.tooltip = this._currentHint.message; this._item.text = localize('large.label', "Configure Excludes"); <del> this._item.tooltip = localize('hintExclude.tooltip', "For better performance exclude folders with many files."); </del> <ins> this._item.tooltip = localize('hintExclude.tooltip', "To enable JavaScript/TypeScript IntelliSense, exclude large folders with source files that you do not work on."); </ins> this._item.color = '#A5DF3B'; this._item.show(); this._client.logTelemetry('js.hintProjectExcludes');
Code change:
VSCode Version: Code - Insiders 1.9.0-insider (, 2017-01-20T14:58:38.006Z) OS Version: Linux x64 4.8.0-34-generic Extensions: TypeScript file: ! Press enter: !
verified.

Related discussion:
text: } else if (enterAction.indentAction === IndentAction.Indent) { // Indent once <del> executeCommand = TypeOperations.typeCommand(range, beforeText + 'n' + config.normalizeIndentation(indentation + 't' + enterAction.appendText), keepPosition); </del> <ins> executeCommand = TypeOperations.typeCommand(range, beforeText + 'n' + config.normalizeIndentation(indentation + enterAction.appendText), keepPosition); </ins> } else if (enterAction.indentAction === IndentAction.IndentOutdent) { // Ultra special let normalIndent = config.normalizeIndentation(indentation); <del> let increasedIndent = config.normalizeIndentation(indentation + 't' + enterAction.appendText); </del> <ins> let increasedIndent = config.normalizeIndentation(indentation + enterAction.appendText); </ins> let typeText = beforeText + 'n' + increasedIndent + 'n' + normalIndent;
Code change:
VSCode Version: Code - Insiders 1.9.0-insider (, 2017-01-20T14:58:38.006Z) OS Version: Linux x64 4.8.0-34-generic Extensions: TypeScript file: ! Press enter: !
verified.

Related discussion:
text: if (!enterResult) { enterResult = { indentAction: IndentAction.None, appendText: '' }; } else { <ins> // Here we add `t` to appendText first because enterAction is leveraging appendText and removeText to change indentation. </ins> if (!enterResult.appendText) { <del> enterResult.appendText = ''; </del> <ins> if ( (enterResult.indentAction === IndentAction.Indent) || (enterResult.indentAction === IndentAction.IndentOutdent) ) { enterResult.appendText = 't'; } else { enterResult.appendText = ''; } </ins> } }
Code change:
<!-- Do you have a question? Please ask it on --- VSCode Version: 1.10.2 OS Version: Mac OSX (10.11.6) Steps to Reproduce: VS Code integrated terminal a relative path (eg. ) Description: Let's say you have a build system that outputs a stack trace on a build error or failed test. If this was run from the integrated terminal, the file paths in the output should be included as clickable links which can be clicked to open the file in VSCode. However, this only works if the path is either an absolute path (e.g. ) or a relative path that begins with "./". Many build systems and tools output file paths relative to the directory the command was run, without the leading "./", Karma for example. So the output would be something like: , not . The first is not matched by VSCode as an openable path, but the second is. I believe that what is determined to be a path comes from the Regex in "" Is there a reason why relative paths of this form (e.g. no leading "./") are not included?
The reason was because until 1.11 links aren't validated so there would be heaps of false positives. Performance was also a factor but it shouldn't impact that much really now that I think about it. Now that links are validated maybe we should be more lenient when linkifying.
I'll assign this to April but if someone wants to do a PR before then you're welcome. You will need to: Modify the regex to allow paths that are not qualified with , , etc. Make sure that the new path matcher does not conflict with previously matched links and does not create links with adjacent characters. Eg. we want to avoid this:
Nice. I'll write a PR...
That would be awesome :+1:
Fixed in

Related discussion:
text: import * as assert from 'assert'; import { Platform } from 'vs/base/common/platform'; import { TerminalLinkHandler } from 'vs/workbench/parts/terminal/electron-browser/terminalLinkHandler'; <ins> import { IWorkspace, WorkspaceContextService } from 'vs/platform/workspace/common/workspace'; import URI from 'vs/base/common/uri'; import * as path from 'path'; import * as sinon from 'sinon'; </ins> class TestTerminalLinkHandler extends TerminalLinkHandler { public get localLinkRegex(): RegExp { return this._localLinkRegex; } <ins> public preprocessPath(link: string): string { return this._preprocessPath(link); } </ins> } class TestXterm {
Code change:
<!-- Do you have a question? Please ask it on --- VSCode Version: 1.10.2 OS Version: Mac OSX (10.11.6) Steps to Reproduce: VS Code integrated terminal a relative path (eg. ) Description: Let's say you have a build system that outputs a stack trace on a build error or failed test. If this was run from the integrated terminal, the file paths in the output should be included as clickable links which can be clicked to open the file in VSCode. However, this only works if the path is either an absolute path (e.g. ) or a relative path that begins with "./". Many build systems and tools output file paths relative to the directory the command was run, without the leading "./", Karma for example. So the output would be something like: , not . The first is not matched by VSCode as an openable path, but the second is. I believe that what is determined to be a path comes from the Regex in "" Is there a reason why relative paths of this form (e.g. no leading "./") are not included?
The reason was because until 1.11 links aren't validated so there would be heaps of false positives. Performance was also a factor but it shouldn't impact that much really now that I think about it. Now that links are validated maybe we should be more lenient when linkifying.
I'll assign this to April but if someone wants to do a PR before then you're welcome. You will need to: Modify the regex to allow paths that are not qualified with , , etc. Make sure that the new path matcher does not conflict with previously matched links and does not create links with adjacent characters. Eg. we want to avoid this:
Nice. I'll write a PR...
That would be awesome :+1:
Fixed in

Related discussion:
text: public setHypertextValidationCallback() { } } <ins> class TestURI extends URI { constructor(private _fakePath: string) { super(); }; get fsPath(): string { return this._fakePath; } } class TestWorkspace implements IWorkspace { resource: URI; constructor(basePath: string) { this.resource = new TestURI(basePath); } } </ins> suite('Workbench - TerminalLinkHandler', () => { suite('localLinkRegex', () => { test('Windows', () => {
Code change:
<!-- Do you have a question? Please ask it on --- VSCode Version: 1.10.2 OS Version: Mac OSX (10.11.6) Steps to Reproduce: VS Code integrated terminal a relative path (eg. ) Description: Let's say you have a build system that outputs a stack trace on a build error or failed test. If this was run from the integrated terminal, the file paths in the output should be included as clickable links which can be clicked to open the file in VSCode. However, this only works if the path is either an absolute path (e.g. ) or a relative path that begins with "./". Many build systems and tools output file paths relative to the directory the command was run, without the leading "./", Karma for example. So the output would be something like: , not . The first is not matched by VSCode as an openable path, but the second is. I believe that what is determined to be a path comes from the Regex in "" Is there a reason why relative paths of this form (e.g. no leading "./") are not included?
The reason was because until 1.11 links aren't validated so there would be heaps of false positives. Performance was also a factor but it shouldn't impact that much really now that I think about it. Now that links are validated maybe we should be more lenient when linkifying.
I'll assign this to April but if someone wants to do a PR before then you're welcome. You will need to: Modify the regex to allow paths that are not qualified with , , etc. Make sure that the new path matcher does not conflict with previously matched links and does not create links with adjacent characters. Eg. we want to avoid this:
Nice. I'll write a PR...
That would be awesome :+1:
Fixed in

Related discussion:
text: testLink('c:/a/long/path'); testLink('c:alongpath'); testLink('c:mixed/slashpath'); <ins> testLink('a/relative/path'); </ins> }); test('Linux', () => {
Code change:
VSCode Version: Code - Insiders 1.11.0-insider (, 2017-03-17T08:14:15.805Z) OS Version: Windows_NT ia32 10.0. Extensions: ; Steps to Reproduce: a terminal and run "bash" with a text file containing some lines of text ctrl+v (or right-click) to paste some lines of text What's expected: The text should be appended before the cursor, and the existing text should be there after the cursor. What happens: Existing text disappears, and it seems some extra newlines are when pasting text. Note: there is no such problem when doing the exact same steps with This happens on insider builds, no idea if it happens with standard builds as well.
More information. Here is what happens when I try to paste this text function startagent { echo "Initialising new SSH agent..." /usr/bin/ssh-agent | sed 's/^echo/#echo/' "${SSHENV}" echo succeeded chmod 600 "${SSHENV}" . "${SSHENV}" /dev/null /usr/bin/ssh-add; } In the middle of a file containing this text: existing file with some text Here is what happens with (that's what expected: text is pasted in between existing text): ! Here is what happens with VSCode: text is pasted with extra newlines plus existing text appears in the middle of the pasted text !
Any update on this bug ?
Thanks for the ping. I've validated it's definitely an upstream issue. I tried to fix it a couple of days ago but didn't get anywhere. I'd guess it's related to node-pty or winpty as different shells appeared to handle it differently. It also seemed somewhat inconsistent. No plans to invest further in fixing it just yet.
This is probably a bug with VSCode's JS xterm module, not a node-pty or winpty bug. I placed these two lines in an untitled editor window: I then set the environment variable , started VSCode, and copy-and-pasted the two lines above into VSCode's integrated terminal. This appeared in the winpty trace: The clipboard has CRLF-delimited lines, because we're on Windows. However, in the VT/100 input format, CR means Return, and LF means Ctrl-Return. Something (probably the JS xterm) is copying the clipboard contents into the pty, and that something should normalize LF and CRLF into CR. I described this bug in detail the last time I saw it:
thanks! This is likely the culprit then which replaces all end of line chars with on Windows:
Yeah, I think your change will fix the issue. The function looks like it might also need a change. Maybe something like this?
FYI I think you may have run into these issues before? It would be a good idea to test these changes in in tomorrow's Insiders build.
I've certainly experienced aspects of this issue from the Python extension when running selections of code in the terminal.
I was unable to reproduce the problem anyway, so have no way of testing this. But thanks for letting me know :-)

Related discussion:
text: } export class TerminalInstance implements ITerminalInstance { <del> private static readonly EOL_REGEX = /r?n/g; </del> <ins> private static readonly WINDOWS_EOL_REGEX = /r?n/g; </ins> private static _terminalProcessFactory: ITerminalProcessFactory = new StandardTerminalProcessFactory(); private static _lastKnownDimensions: Dimension = null;