Question: <!-- Do you have a question? Please ask it on --- VSCode Version: Version 1.12.1 (1.12.1) OS Version: Windows 64 bits This issue is not a bug but just a suggestion/idea to improve CodeLens performance for TypeScript when and are activated. In this case tsserver command which can take times and response can be big is called twice: one call of navtree for providing references CodeLens. one call of navtree for providing implementation CodeLens. I tell me if CodeLens provider could manage a shared context to store some data that other code lens provider could use it. For instance in this case, we could have just one call of navtree: one call of navtree for providing references CodeLens and store the result in a shared context. the implementation CodeLens provider search navtree from the shared context.

export default class TypeScriptImplementationsCodeLensProvider extends TypeScriptBaseCodeLensProvider { public constructor( client: ITypeScriptServiceClient, <del> private readonly language: string </del> <ins> private readonly language: string, cachedResponse: CachedNavTreeResponse </ins> ) { <del> super(client); </del> <ins> super(client, cachedResponse); </ins> } public updateConfiguration(): void {


Question: <!-- Do you have a question? Please ask it on --- VSCode Version: Version 1.12.1 (1.12.1) OS Version: Windows 64 bits This issue is not a bug but just a suggestion/idea to improve CodeLens performance for TypeScript when and are activated. In this case tsserver command which can take times and response can be big is called twice: one call of navtree for providing references CodeLens. one call of navtree for providing implementation CodeLens. I tell me if CodeLens provider could manage a shared context to store some data that other code lens provider could use it. For instance in this case, we could have just one call of navtree: one call of navtree for providing references CodeLens and store the result in a shared context. the implementation CodeLens provider search navtree from the shared context.

import * as Proto from '../protocol'; import * as PConst from '../protocol.const'; <del> import { TypeScriptBaseCodeLensProvider, ReferencesCodeLens } from './baseCodeLensProvider'; </del> <ins> import { TypeScriptBaseCodeLensProvider, ReferencesCodeLens, CachedNavTreeResponse } from './baseCodeLensProvider'; </ins> import { ITypeScriptServiceClient } from '../typescriptService'; import { tsTextSpanToVsRange, vsPositionToTsFileLocation } from '../utils/convert';


Question: <!-- Do you have a question? Please ask it on --- VSCode Version: Version 1.12.1 (1.12.1) OS Version: Windows 64 bits This issue is not a bug but just a suggestion/idea to improve CodeLens performance for TypeScript when and are activated. In this case tsserver command which can take times and response can be big is called twice: one call of navtree for providing references CodeLens. one call of navtree for providing implementation CodeLens. I tell me if CodeLens provider could manage a shared context to store some data that other code lens provider could use it. For instance in this case, we could have just one call of navtree: one call of navtree for providing references CodeLens and store the result in a shared context. the implementation CodeLens provider search navtree from the shared context.

export default class TypeScriptReferencesCodeLensProvider extends TypeScriptBaseCodeLensProvider { public constructor( client: ITypeScriptServiceClient, <del> private readonly language: string </del> <ins> private readonly language: string, cachedResponse: CachedNavTreeResponse </ins> ) { <del> super(client); </del> <ins> super(client, cachedResponse); </ins> } public updateConfiguration(): void {


Question: <!-- Do you have a question? Please ask it on --- VSCode Version: Version 1.12.1 (1.12.1) OS Version: Windows 64 bits This issue is not a bug but just a suggestion/idea to improve CodeLens performance for TypeScript when and are activated. In this case tsserver command which can take times and response can be big is called twice: one call of navtree for providing references CodeLens. one call of navtree for providing implementation CodeLens. I tell me if CodeLens provider could manage a shared context to store some data that other code lens provider could use it. For instance in this case, we could have just one call of navtree: one call of navtree for providing references CodeLens and store the result in a shared context. the implementation CodeLens provider search navtree from the shared context.

import DiagnosticsManager from './features/diagnostics'; import { LanguageDescription } from './utils/languageDescription'; import * as fileSchemes from './utils/fileSchemes'; <ins> import { CachedNavTreeResponse } from './features/baseCodeLensProvider'; </ins> const validateSetting = 'validate.enable';


Question: <!-- Do you have a question? Please ask it on --- VSCode Version: Version 1.12.1 (1.12.1) OS Version: Windows 64 bits This issue is not a bug but just a suggestion/idea to improve CodeLens performance for TypeScript when and are activated. In this case tsserver command which can take times and response can be big is called twice: one call of navtree for providing references CodeLens. one call of navtree for providing implementation CodeLens. I tell me if CodeLens provider could manage a shared context to store some data that other code lens provider could use it. For instance in this case, we could have just one call of navtree: one call of navtree for providing references CodeLens and store the result in a shared context. the implementation CodeLens provider search navtree from the shared context.

this.disposables.push(languages.registerCodeActionsProvider(selector, new (await import('./features/refactorProvider')).default(client, this.formattingOptionsManager, commandManager))); this.registerVersionDependentProviders(); <del> const referenceCodeLensProvider = new (await import('./features/referencesCodeLensProvider')).default(client, this.description.id); </del> <ins> const cachedResponse = new CachedNavTreeResponse(); const referenceCodeLensProvider = new (await import('./features/referencesCodeLensProvider')).default(client, this.description.id, cachedResponse); </ins> referenceCodeLensProvider.updateConfiguration(); this.toUpdateOnConfigurationChanged.push(referenceCodeLensProvider); this.disposables.push(languages.registerCodeLensProvider(selector, referenceCodeLensProvider)); <del> const implementationCodeLensProvider = new (await import('./features/implementationsCodeLensProvider')).default(client, this.description.id); </del> <ins> const implementationCodeLensProvider = new (await import('./features/implementationsCodeLensProvider')).default(client, this.description.id, cachedResponse); </ins> implementationCodeLensProvider.updateConfiguration(); this.toUpdateOnConfigurationChanged.push(implementationCodeLensProvider); this.disposables.push(languages.registerCodeLensProvider(selector, implementationCodeLensProvider));


Question:
Currently blocked by:
Branch is at
The arg is causing the issue on Windows. This: Calls which passes to .
It may not work because out-build doesn't exist. I can repro when doing:
After spending quite a bit of time looking into this, I'm pretty stumped on why this is failing. any help would be great as I'm not sure where to go from here. Here's what I've found so far: I can reproduce using the following: Unit tests on Windows fail at random times Passing shows the window and all tests complete, with KeyboardMapper tests failing which I frequently when running unit tests on Windows. ! Listening to the in addition to printing test names seems to stop at random spots, telling me that this isn't related to a single test. Here are the end of some logs from test runs:The test runner pauses for 2-5 seconds after a the last output and then exits.
I just tried to reproduce on Windows, for me the tests are looking all OK. Do you see the test failures on the command line as output?
the output stops before any failures example output: etc.
does this reproduce with mocha tests (and the exact same version that electron 1.7.4 uses) too?
Seems to happen when using node 7.9.0 as well which ships with 1.7.4. Currently the build machine is set up to use 7.10.0 (set in ).
Ok so it seems electron unrelated then. Can you explain this, are you saying the keyboard mapper test is causing this?
No, the keyboard mapper tests on Windows just have always seemed to fail for me a lot on most of my Windows machines.
Created to track upstream. It appears to be happening only when using because calls stop making it to the main process after a short period.
Possibly related:
Update: It appears is an issue with my home desktop only and is different to what we're seeing on the VSTS build server. So I started to add some logs and run more builds on VSTS to see what is going on and it appears like the tests are exiting with but is being set to 255. I made a change to the test script to change error code 255 to 0 to get around this issue since the tests were passing anyway After doing this I did a full build and it succeeded, however it does not launch. running with gives this:
That's pointing at , perhaps it's related to the snapshot stuff?
Commenting out the "Create loader snapshot" step from fixes the exception on launch Also integration tests are not running on VSTS for Windows, this may have caught the snapshot issue earlier.
When updating electron you must also bump the version of . Unsure if there is electron migration guide that should have been updated...
Added to the guide
Discussed with we will shift this to August.
could you look into the exit code issue when you get a chance? We're seeing VSTS giving an exit code of 255 even though appears to be getting called. The change for that is here:
When I log in to the build machine and try to run , the unit tests don't even run at all. All I see is two processes stuck. Do you see this too? ! I also can't find the build where you had a 255 exit code.
interestingly I just noticed that Electron marks 1.7.5 as "latest release" while 1.7.4 is still a pre-release. We should consider being on the latest official release if possible imho. ! !
well I've never been able to log into the machine, I an echo %errorlevel% and it was printing 255 after the tests. It looks like VSTS has discarded the build as it wasn't marked as retain. If the Windows builds succeed after this line is removed then all is well:
Update: I have Electron 1.7.5 on the branch , I'm running into build issues on VSTS/macOS though which appear to be related to using the new file watcher in the build? Not sure why an updated Electron would make this error occur yet though.
We got that error in the official smoke tests and Andre said in Slack that the Mac build machine was messed up. Try it again.
Will do

{ "name": "code-oss-dev", "version": "1.16.0", <del> "electronVersion": "1.7.4", </del> <ins> "electronVersion": "1.7.5", </ins> "distro": "724097db097bfde7796fcca70aaac83ba80a95f8", "author": { "name": "Microsoft Corporation"


Question: Loosely related to ! We can use the 'files to include' box to do a search in an arbitrary folder, but it has to be an absolute path. It should also work when using a ~ to indicate the user's home directory.

import * as glob from 'vs/base/common/glob'; import * as paths from 'vs/base/common/paths'; import uri from 'vs/base/common/uri'; <ins> import { untildify } from 'vs/base/common/labels'; </ins> import { IWorkspaceContextService, WorkbenchState } from 'vs/platform/workspace/common/workspace'; import { IPatternInfo, IQueryOptions, IFolderQuery, ISearchQuery, QueryType, ISearchConfiguration, getExcludes, pathIncludedInQuery } from 'vs/platform/search/common/search'; import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; <ins> import { IEnvironmentService } from 'vs/platform/environment/common/environment'; </ins> export interface ISearchPathPattern { searchPath: uri;


Question: Loosely related to ! We can use the 'files to include' box to do a search in an arbitrary folder, but it has to be an absolute path. It should also work when using a ~ to indicate the user's home directory.

constructor( @IConfigurationService private configurationService: IConfigurationService, <del> @IWorkspaceContextService private workspaceContextService: IWorkspaceContextService) { } </del> <ins> @IWorkspaceContextService private workspaceContextService: IWorkspaceContextService, @IEnvironmentService private environmentService: IEnvironmentService ) { } </ins> public text(contentPattern: IPatternInfo, folderResources?: uri[], options?: IQueryOptions): ISearchQuery { return this.query(QueryType.Text, contentPattern, folderResources, options);


Question: Loosely related to ! We can use the 'files to include' box to do a search in an arbitrary folder, but it has to be an absolute path. It should also work when using a ~ to indicate the user's home directory.

return paths.isAbsolute(segment) || /^..?[/]/.test(segment); }; <del> const segments = splitGlobPattern(pattern); </del> <ins> const segments = splitGlobPattern(pattern) .map(segment => untildify(segment, this.environmentService.userHome)); </ins> const groups = collections.groupBy(segments, segment => isSearchPath(segment) ? 'searchPaths' : 'exprSegments');


Question: Loosely related to ! We can use the 'files to include' box to do a search in an arbitrary folder, but it has to be an absolute path. It should also work when using a ~ to indicate the user's home directory.

import { IWorkspaceContextService, Workspace, toWorkspaceFolders } from 'vs/platform/workspace/common/workspace'; import { TestConfigurationService } from 'vs/platform/configuration/test/common/testConfigurationService'; import { QueryBuilder, ISearchPathsResult } from 'vs/workbench/parts/search/common/queryBuilder'; <del> import { TestContextService } from 'vs/workbench/test/workbenchTestServices'; </del> <ins> import { IEnvironmentService } from 'vs/platform/environment/common/environment'; import { TestContextService, TestEnvironmentService } from 'vs/workbench/test/workbenchTestServices'; </ins> import { ISearchQuery, QueryType, IPatternInfo, IFolderQuery } from 'vs/platform/search/common/search';


Question: Loosely related to ! We can use the 'files to include' box to do a search in an arbitrary folder, but it has to be an absolute path. It should also work when using a ~ to indicate the user's home directory.

mockContextService.setWorkspace(mockWorkspace); instantiationService.stub(IWorkspaceContextService, mockContextService); <ins> instantiationService.stub(IEnvironmentService, TestEnvironmentService); </ins> queryBuilder = instantiationService.createInstance(QueryBuilder); });


Question:
VSCode Version: Code 1.17.1 (, 2017-10-10T14:24:50.851Z) OS Version: Windows_NT x64 10.0. Current default keybindings on Windows: has two key bindings, which seems unnecessary. On Linux the default key bindings are (IIRC): Which makes a lot more sense IMHO. Also using this default on Windows would also align Windows/Linux key bindings and maybe even avoid complications like . (same for of course)
We will not change this. See

kbOpts: { weight: CORE_WEIGHT, kbExpr: EditorContextKeys.textInputFocus, <del> primary: KeyMod.CtrlCmd | KeyMod.Shift | KeyMod.Alt | KeyCode.UpArrow, </del> <ins> primary: KeyMod.CtrlCmd | KeyMod.Shift | KeyCode.UpArrow, </ins> linux: { primary: 0 } } }));


Question:
VSCode Version: Code 1.17.1 (, 2017-10-10T14:24:50.851Z) OS Version: Windows_NT x64 10.0. Current default keybindings on Windows: has two key bindings, which seems unnecessary. On Linux the default key bindings are (IIRC): Which makes a lot more sense IMHO. Also using this default on Windows would also align Windows/Linux key bindings and maybe even avoid complications like . (same for of course)
We will not change this. See

kbOpts: { weight: CORE_WEIGHT, kbExpr: EditorContextKeys.textInputFocus, <del> primary: KeyMod.CtrlCmd | KeyMod.Shift | KeyMod.Alt | KeyCode.DownArrow, </del> <ins> primary: KeyMod.CtrlCmd | KeyMod.Shift | KeyCode.DownArrow, </ins> linux: { primary: 0 } } }));


Question:
VSCode Version: Code 1.17.1 (, 2017-10-10T14:24:50.851Z) OS Version: Windows_NT x64 10.0. Current default keybindings on Windows: has two key bindings, which seems unnecessary. On Linux the default key bindings are (IIRC): Which makes a lot more sense IMHO. Also using this default on Windows would also align Windows/Linux key bindings and maybe even avoid complications like . (same for of course)
We will not change this. See

weight: CORE_WEIGHT, kbExpr: EditorContextKeys.textInputFocus, primary: KeyMod.Shift | KeyCode.UpArrow, <del> secondary: [KeyMod.CtrlCmd | KeyMod.Shift | KeyCode.UpArrow], </del> mac: { primary: KeyMod.Shift | KeyCode.UpArrow }, linux: { primary: KeyMod.Shift | KeyCode.UpArrow } }


Question:
VSCode Version: Code 1.17.1 (, 2017-10-10T14:24:50.851Z) OS Version: Windows_NT x64 10.0. Current default keybindings on Windows: has two key bindings, which seems unnecessary. On Linux the default key bindings are (IIRC): Which makes a lot more sense IMHO. Also using this default on Windows would also align Windows/Linux key bindings and maybe even avoid complications like . (same for of course)
We will not change this. See

weight: CORE_WEIGHT, kbExpr: EditorContextKeys.textInputFocus, primary: KeyMod.Shift | KeyCode.DownArrow, <del> secondary: [KeyMod.CtrlCmd | KeyMod.Shift | KeyCode.DownArrow], </del> mac: { primary: KeyMod.Shift | KeyCode.DownArrow }, linux: { primary: KeyMod.Shift | KeyCode.DownArrow } }


Question:
Generalization of Steps to Reproduce: a markdown file: the js code block, type Bug inserted. Root cause* Markdown defines and as auto closing pairs. Js does not. It appears that we always use the document language's autoclosing pairs instead of the autoclosing pairs of the embedded language at the current cursor position
Good catch, auto close should check language around cursor instead of model.
Another case: Based on JS's auto closing rules, we would expect completion to

} } <del> return true; </del> <ins> return false; </ins> } public getSurroundingPairs(): IAutoClosingPair[] {


Question:
Generalization of Steps to Reproduce: a markdown file: the js code block, type Bug inserted. Root cause* Markdown defines and as auto closing pairs. Js does not. It appears that we always use the document language's autoclosing pairs instead of the autoclosing pairs of the embedded language at the current cursor position
Good catch, auto close should check language around cursor instead of model.
Another case: Based on JS's auto closing rules, we would expect completion to

test('shouldAutoClosePair in empty line', () => { let sup = new CharacterPairSupport({ autoClosingPairs: [{ open: '{', close: '}', notIn: ['string', 'comment'] }] }); <del> assert.equal(testShouldAutoClose(sup, [], 'a', 1), true); </del> <ins> assert.equal(testShouldAutoClose(sup, [], 'a', 1), false); </ins> assert.equal(testShouldAutoClose(sup, [], '{', 1), true); }); test('shouldAutoClosePair in not interesting line 1', () => { let sup = new CharacterPairSupport({ autoClosingPairs: [{ open: '{', close: '}', notIn: ['string', 'comment'] }] }); assert.equal(testShouldAutoClose(sup, [{ text: 'do', type: StandardTokenType.Other }], '{', 3), true); <del> assert.equal(testShouldAutoClose(sup, [{ text: 'do', type: StandardTokenType.Other }], 'a', 3), true); </del> <ins> assert.equal(testShouldAutoClose(sup, [{ text: 'do', type: StandardTokenType.Other }], 'a', 3), false); </ins> }); test('shouldAutoClosePair in not interesting line 2', () => { let sup = new CharacterPairSupport({ autoClosingPairs: [{ open: '{', close: '}' }] }); assert.equal(testShouldAutoClose(sup, [{ text: 'do', type: StandardTokenType.String }], '{', 3), true); <del> assert.equal(testShouldAutoClose(sup, [{ text: 'do', type: StandardTokenType.String }], 'a', 3), true); </del> <ins> assert.equal(testShouldAutoClose(sup, [{ text: 'do', type: StandardTokenType.String }], 'a', 3), false); </ins> }); test('shouldAutoClosePair in interesting line 1', () => { let sup = new CharacterPairSupport({ autoClosingPairs: [{ open: '{', close: '}', notIn: ['string', 'comment'] }] }); assert.equal(testShouldAutoClose(sup, [{ text: '"a"', type: StandardTokenType.String }], '{', 1), false); <del> assert.equal(testShouldAutoClose(sup, [{ text: '"a"', type: StandardTokenType.String }], 'a', 1), true); </del> <ins> assert.equal(testShouldAutoClose(sup, [{ text: '"a"', type: StandardTokenType.String }], 'a', 1), false); </ins> assert.equal(testShouldAutoClose(sup, [{ text: '"a"', type: StandardTokenType.String }], '{', 2), false); <del> assert.equal(testShouldAutoClose(sup, [{ text: '"a"', type: StandardTokenType.String }], 'a', 2), true); </del> <ins> assert.equal(testShouldAutoClose(sup, [{ text: '"a"', type: StandardTokenType.String }], 'a', 2), false); </ins> assert.equal(testShouldAutoClose(sup, [{ text: '"a"', type: StandardTokenType.String }], '{', 3), false); <del> assert.equal(testShouldAutoClose(sup, [{ text: '"a"', type: StandardTokenType.String }], 'a', 3), true); </del> <ins> assert.equal(testShouldAutoClose(sup, [{ text: '"a"', type: StandardTokenType.String }], 'a', 3), false); </ins> assert.equal(testShouldAutoClose(sup, [{ text: '"a"', type: StandardTokenType.String }], '{', 4), false); <del> assert.equal(testShouldAutoClose(sup, [{ text: '"a"', type: StandardTokenType.String }], 'a', 4), true); </del> <ins> assert.equal(testShouldAutoClose(sup, [{ text: '"a"', type: StandardTokenType.String }], 'a', 4), false); </ins> }); test('shouldAutoClosePair in interesting line 2', () => { let sup = new CharacterPairSupport({ autoClosingPairs: [{ open: '{', close: '}', notIn: ['string', 'comment'] }] }); assert.equal(testShouldAutoClose(sup, [{ text: 'x=', type: StandardTokenType.Other }, { text: '"a"', type: StandardTokenType.String }, { text: ';', type: StandardTokenType.Other }], '{', 1), true); <del> assert.equal(testShouldAutoClose(sup, [{ text: 'x=', type: StandardTokenType.Other }, { text: '"a"', type: StandardTokenType.String }, { text: ';', type: StandardTokenType.Other }], 'a', 1), true); </del> <ins> assert.equal(testShouldAutoClose(sup, [{ text: 'x=', type: StandardTokenType.Other }, { text: '"a"', type: StandardTokenType.String }, { text: ';', type: StandardTokenType.Other }], 'a', 1), false); </ins> assert.equal(testShouldAutoClose(sup, [{ text: 'x=', type: StandardTokenType.Other }, { text: '"a"', type: StandardTokenType.String }, { text: ';', type: StandardTokenType.Other }], '{', 2), true); <del> assert.equal(testShouldAutoClose(sup, [{ text: 'x=', type: StandardTokenType.Other }, { text: '"a"', type: StandardTokenType.String }, { text: ';', type: StandardTokenType.Other }], 'a', 2), true); </del> <ins> assert.equal(testShouldAutoClose(sup, [{ text: 'x=', type: StandardTokenType.Other }, { text: '"a"', type: StandardTokenType.String }, { text: ';', type: StandardTokenType.Other }], 'a', 2), false); </ins> assert.equal(testShouldAutoClose(sup, [{ text: 'x=', type: StandardTokenType.Other }, { text: '"a"', type: StandardTokenType.String }, { text: ';', type: StandardTokenType.Other }], '{', 3), true); <del> assert.equal(testShouldAutoClose(sup, [{ text: 'x=', type: StandardTokenType.Other }, { text: '"a"', type: StandardTokenType.String }, { text: ';', type: StandardTokenType.Other }], 'a', 3), true); </del> <ins> assert.equal(testShouldAutoClose(sup, [{ text: 'x=', type: StandardTokenType.Other }, { text: '"a"', type: StandardTokenType.String }, { text: ';', type: StandardTokenType.Other }], 'a', 3), false); </ins> assert.equal(testShouldAutoClose(sup, [{ text: 'x=', type: StandardTokenType.Other }, { text: '"a"', type: StandardTokenType.String }, { text: ';', type: StandardTokenType.Other }], '{', 4), false); <del> assert.equal(testShouldAutoClose(sup, [{ text: 'x=', type: StandardTokenType.Other }, { text: '"a"', type: StandardTokenType.String }, { text: ';', type: StandardTokenType.Other }], 'a', 4), true); </del> <ins> assert.equal(testShouldAutoClose(sup, [{ text: 'x=', type: StandardTokenType.Other }, { text: '"a"', type: StandardTokenType.String }, { text: ';', type: StandardTokenType.Other }], 'a', 4), false); </ins> assert.equal(testShouldAutoClose(sup, [{ text: 'x=', type: StandardTokenType.Other }, { text: '"a"', type: StandardTokenType.String }, { text: ';', type: StandardTokenType.Other }], '{', 5), false); <del> assert.equal(testShouldAutoClose(sup, [{ text: 'x=', type: StandardTokenType.Other }, { text: '"a"', type: StandardTokenType.String }, { text: ';', type: StandardTokenType.Other }], 'a', 5), true); </del> <ins> assert.equal(testShouldAutoClose(sup, [{ text: 'x=', type: StandardTokenType.Other }, { text: '"a"', type: StandardTokenType.String }, { text: ';', type: StandardTokenType.Other }], 'a', 5), false); </ins> assert.equal(testShouldAutoClose(sup, [{ text: 'x=', type: StandardTokenType.Other }, { text: '"a"', type: StandardTokenType.String }, { text: ';', type: StandardTokenType.Other }], '{', 6), false); <del> assert.equal(testShouldAutoClose(sup, [{ text: 'x=', type: StandardTokenType.Other }, { text: '"a"', type: StandardTokenType.String }, { text: ';', type: StandardTokenType.Other }], 'a', 6), true); </del> <ins> assert.equal(testShouldAutoClose(sup, [{ text: 'x=', type: StandardTokenType.Other }, { text: '"a"', type: StandardTokenType.String }, { text: ';', type: StandardTokenType.Other }], 'a', 6), false); </ins> assert.equal(testShouldAutoClose(sup, [{ text: 'x=', type: StandardTokenType.Other }, { text: '"a"', type: StandardTokenType.String }, { text: ';', type: StandardTokenType.Other }], '{', 7), true); <del> assert.equal(testShouldAutoClose(sup, [{ text: 'x=', type: StandardTokenType.Other }, { text: '"a"', type: StandardTokenType.String }, { text: ';', type: StandardTokenType.Other }], 'a', 7), true); </del> <ins> assert.equal(testShouldAutoClose(sup, [{ text: 'x=', type: StandardTokenType.Other }, { text: '"a"', type: StandardTokenType.String }, { text: ';', type: StandardTokenType.Other }], 'a', 7), false); </ins> }); test('shouldAutoClosePair in interesting line 3', () => { let sup = new CharacterPairSupport({ autoClosingPairs: [{ open: '{', close: '}', notIn: ['string', 'comment'] }] }); assert.equal(testShouldAutoClose(sup, [{ text: ' ', type: StandardTokenType.Other }, { text: '//a', type: StandardTokenType.Comment }], '{', 1), true); <del> assert.equal(testShouldAutoClose(sup, [{ text: ' ', type: StandardTokenType.Other }, { text: '//a', type: StandardTokenType.Comment }], 'a', 1), true); </del> <ins> assert.equal(testShouldAutoClose(sup, [{ text: ' ', type: StandardTokenType.Other }, { text: '//a', type: StandardTokenType.Comment }], 'a', 1), false); </ins> assert.equal(testShouldAutoClose(sup, [{ text: ' ', type: StandardTokenType.Other }, { text: '//a', type: StandardTokenType.Comment }], '{', 2), true); <del> assert.equal(testShouldAutoClose(sup, [{ text: ' ', type: StandardTokenType.Other }, { text: '//a', type: StandardTokenType.Comment }], 'a', 2), true); </del> <ins> assert.equal(testShouldAutoClose(sup, [{ text: ' ', type: StandardTokenType.Other }, { text: '//a', type: StandardTokenType.Comment }], 'a', 2), false); </ins> assert.equal(testShouldAutoClose(sup, [{ text: ' ', type: StandardTokenType.Other }, { text: '//a', type: StandardTokenType.Comment }], '{', 3), false); <del> assert.equal(testShouldAutoClose(sup, [{ text: ' ', type: StandardTokenType.Other }, { text: '//a', type: StandardTokenType.Comment }], 'a', 3), true); </del> <ins> assert.equal(testShouldAutoClose(sup, [{ text: ' ', type: StandardTokenType.Other }, { text: '//a', type: StandardTokenType.Comment }], 'a', 3), false); </ins> assert.equal(testShouldAutoClose(sup, [{ text: ' ', type: StandardTokenType.Other }, { text: '//a', type: StandardTokenType.Comment }], '{', 4), false); <del> assert.equal(testShouldAutoClose(sup, [{ text: ' ', type: StandardTokenType.Other }, { text: '//a', type: StandardTokenType.Comment }], 'a', 4), true); </del> <ins> assert.equal(testShouldAutoClose(sup, [{ text: ' ', type: StandardTokenType.Other }, { text: '//a', type: StandardTokenType.Comment }], 'a', 4), false); </ins> assert.equal(testShouldAutoClose(sup, [{ text: ' ', type: StandardTokenType.Other }, { text: '//a', type: StandardTokenType.Comment }], '{', 5), false); <del> assert.equal(testShouldAutoClose(sup, [{ text: ' ', type: StandardTokenType.Other }, { text: '//a', type: StandardTokenType.Comment }], 'a', 5), true); </del> <ins> assert.equal(testShouldAutoClose(sup, [{ text: ' ', type: StandardTokenType.Other }, { text: '//a', type: StandardTokenType.Comment }], 'a', 5), false); </ins> }); });


Question:
VSCode Version: 1.18.0 / 1.19.0-insider OS Version: Windows 10 Steps to Reproduce: a Project with Workspace (Typescript) one external method inside other method in whatever class. Alt+F12 to open "Peek Definition" the method opened in peek definition .. bug reproduced.. file opened in peek definition now be opened in workspace. Even after save the file on peek definition, the file opened on workspace continue without save. <!-- Launch with to check. --Reproduces without extensions: No
Can you please clairify what the problem is. Here's what I see: ! Is the error that file from the peek definition ( in my gif) still has the unsaved indicator in the workspace, even after you save it?
Yes, even after I save the file (). Pointer with focus inside peek definition, and I press and after to save and close peek definition the file continue with unsaved indicator. This behavior did not happen, even after I change file inside peek definition the file changed would not open.
See my gif. Note that the focus is on the peek definition and when I press the saved file is not , but . I believe this behavior is wrong. !
As designed, we open editors that are dirty to prevent data loss.
But this is nothing intuitive See my image, not would be interesting working like this? When change file, show the little ball in peek definition. ! When click to or , then show the confirmation: !
and what should happen when you close the tab?
In this case if close the would could execute one stack of confirmation of files changed starting by
And if close vscode, then would be open the file on tab with changes before close. Like this no data is lost.
I do not like that behaviour, I prefer that one modified editor maps to one opened tab, anything else makes it very hard for the user to track dirty files.
ok.
I've been in Visual Studio to see how it behaves and actually vscode is behaving the same way it does. However, in visual studio when we save the file in focus inside peek definition the file opened in the tab is saved. I think vscode should behave the same way. In this case, I reiterate that saving the and not file when I am with the cursor in peek definition when pressing is a bug. ! Now, see this behavior on vscode on press !
?
Yeah thats a good one, lets take this issue to reflect that.
has there been any updates on this issue? I think this behaviour is rather reasonable and intuitive, though I'm kinda surprised this issue hasn't seen more activity (I'd expect more people to want this). I had someone ask about this very thing on my extension: and this could really help us:
I've found that adding the following to accomplishes nearly the same thing: Works for me since I don't tend to keep unsaved files open often. Might be useful for CSS Peek.
Hi I agree with guys, that is really annoying, I'm wondering why they still didn't fix this problem ... !!! why Ctrl+S work in peek preview ?!? its fine in Visual Studio
! I pushed a change to enable this by default if the embedded editor is focused. Pressing or will now save both the main editor and the embedded editor. Feedback welcome, it will be in tomorrows insider build:

import { IEnvironmentService } from 'vs/platform/environment/common/environment'; import { UNTITLED_WORKSPACE_NAME } from 'vs/platform/workspaces/common/workspaces'; import { coalesce } from 'vs/base/common/arrays'; <ins> import { ICodeEditorService } from 'vs/editor/browser/services/codeEditorService'; import { EmbeddedCodeEditorWidget } from 'vs/editor/browser/widget/embeddedCodeEditorWidget'; import { ITextFileService } from 'vs/workbench/services/textfile/common/textfiles'; </ins> // Commands


Question:
VSCode Version: 1.18.0 / 1.19.0-insider OS Version: Windows 10 Steps to Reproduce: a Project with Workspace (Typescript) one external method inside other method in whatever class. Alt+F12 to open "Peek Definition" the method opened in peek definition .. bug reproduced.. file opened in peek definition now be opened in workspace. Even after save the file on peek definition, the file opened on workspace continue without save. <!-- Launch with to check. --Reproduces without extensions: No
Can you please clairify what the problem is. Here's what I see: ! Is the error that file from the peek definition ( in my gif) still has the unsaved indicator in the workspace, even after you save it?
Yes, even after I save the file (). Pointer with focus inside peek definition, and I press and after to save and close peek definition the file continue with unsaved indicator. This behavior did not happen, even after I change file inside peek definition the file changed would not open.
See my gif. Note that the focus is on the peek definition and when I press the saved file is not , but . I believe this behavior is wrong. !
As designed, we open editors that are dirty to prevent data loss.
But this is nothing intuitive See my image, not would be interesting working like this? When change file, show the little ball in peek definition. ! When click to or , then show the confirmation: !
and what should happen when you close the tab?
In this case if close the would could execute one stack of confirmation of files changed starting by
And if close vscode, then would be open the file on tab with changes before close. Like this no data is lost.
I do not like that behaviour, I prefer that one modified editor maps to one opened tab, anything else makes it very hard for the user to track dirty files.
ok.
I've been in Visual Studio to see how it behaves and actually vscode is behaving the same way it does. However, in visual studio when we save the file in focus inside peek definition the file opened in the tab is saved. I think vscode should behave the same way. In this case, I reiterate that saving the and not file when I am with the cursor in peek definition when pressing is a bug. ! Now, see this behavior on vscode on press !
?
Yeah thats a good one, lets take this issue to reflect that.
has there been any updates on this issue? I think this behaviour is rather reasonable and intuitive, though I'm kinda surprised this issue hasn't seen more activity (I'd expect more people to want this). I had someone ask about this very thing on my extension: and this could really help us:
I've found that adding the following to accomplishes nearly the same thing: Works for me since I don't tend to keep unsaved files open often. Might be useful for CSS Peek.
Hi I agree with guys, that is really annoying, I'm wondering why they still didn't fix this problem ... !!! why Ctrl+S work in peek preview ?!? its fine in Visual Studio
! I pushed a change to enable this by default if the embedded editor is focused. Pressing or will now save both the main editor and the embedded editor. Feedback welcome, it will be in tomorrows insider build:

// Save / Save As / Save All / Revert <del> function saveSelectedEditors(accessor: ServicesAccessor, options?: ISaveEditorsOptions): Promise<void> { </del> <ins> async function saveSelectedEditors(accessor: ServicesAccessor, options?: ISaveEditorsOptions): Promise<void> { </ins> const listService = accessor.get(IListService); const editorGroupsService = accessor.get(IEditorGroupsService); <del> return doSaveEditors(accessor, getMultiSelectedEditors(listService, editorGroupsService), options); </del> <ins> const codeEditorService = accessor.get(ICodeEditorService); const textFileService = accessor.get(ITextFileService); // Save editors const editors = getMultiSelectedEditors(listService, editorGroupsService); await doSaveEditors(accessor, editors, options); // Special treatment for embedded editors: if we detect that focus is // inside an embedded code editor, we save that model as well if we // find it in our text file models. Currently, only textual editors // support embedded editors. const focusedCodeEditor = codeEditorService.getFocusedCodeEditor(); if (focusedCodeEditor instanceof EmbeddedCodeEditorWidget) { const resource = focusedCodeEditor.getModel()?.uri; // Check that the resource of the model was not saved already if (resource && !editors.some(({ editor }) => isEqual(toResource(editor, { supportSideBySide: SideBySideEditor.MASTER }), resource))) { const model = textFileService.models.get(resource); if (!model?.isReadonly()) { await textFileService.save(resource, options); } } } </ins> } function saveDirtyEditorsOfGroups(accessor: ServicesAccessor, groups: ReadonlyArray<IEditorGroup>, options?: ISaveEditorsOptions): Promise<void> {


Question: Default order in keybindings (default keybindings and intelliSense) is: ==When you copy from keybindings view and paste: ==

this.selectEntry(keybinding); this.reportKeybindingAction(KEYBINDINGS_EDITOR_COMMAND_COPY, keybinding.keybindingItem.command, keybinding.keybindingItem.keybinding); const userFriendlyKeybinding: IUserFriendlyKeybinding = { <del> command: keybinding.keybindingItem.command, key: keybinding.keybindingItem.keybinding ? keybinding.keybindingItem.keybinding.getUserSettingsLabel() : '' </del> <ins> key: keybinding.keybindingItem.keybinding ? keybinding.keybindingItem.keybinding.getUserSettingsLabel() : '', command: keybinding.keybindingItem.command </ins> }; if (keybinding.keybindingItem.when) { userFriendlyKeybinding.when = keybinding.keybindingItem.when;


Question:
Given , I should be able to Run In parent directory prompt, enter Get popup
Hasn't this issue been solved before ? If it hasn't I'll try to fix it.
Actually it seems the current solution can only handle in the config setting... but not in the input box!
hello I could take a look at the issue if no one is already assigned. It would be my first one. Regards, Pascal.
Hi let me know if you're working on the issue. I think I've found a solution.
go for it !

return ''; } <ins> private handlePathTilde(path: string): string { return path.replace(/^~/, os.homedir()); } </ins> private static cloneId = 0; @command('git.clone')


Question:
Given , I should be able to Run In parent directory prompt, enter Get popup
Hasn't this issue been solved before ? If it hasn't I'll try to fix it.
Actually it seems the current solution can only handle in the config setting... but not in the input box!
hello I could take a look at the issue if no one is already assigned. It would be my first one. Regards, Pascal.
Hi let me know if you're working on the issue. I think I've found a solution.
go for it !

const config = workspace.getConfiguration('git'); let value = config.get<string>('defaultCloneDirectory') || os.homedir(); <del> value = value.replace(/^~/, os.homedir()); </del> const parentPath = await window.showInputBox({ prompt: localize('parent', "Parent Directory"), <del> value, </del> <ins> value: this.handlePathTilde(value), </ins> ignoreFocusOut: true });


Question:
Given , I should be able to Run In parent directory prompt, enter Get popup
Hasn't this issue been solved before ? If it hasn't I'll try to fix it.
Actually it seems the current solution can only handle in the config setting... but not in the input box!
hello I could take a look at the issue if no one is already assigned. It would be my first one. Regards, Pascal.
Hi let me know if you're working on the issue. I think I've found a solution.
go for it !

statusBarItem.command = cancelCommandId; statusBarItem.show(); <del> const clonePromise = this.git.clone(url, parentPath, tokenSource.token); </del> <ins> const clonePromise = this.git.clone(url, this.handlePathTilde(parentPath), tokenSource.token); </ins> try { window.withProgress({ location: ProgressLocation.SourceControl, title: localize('cloning', "Cloning git repository...") }, () => clonePromise);


Question:
I've had a couple of people report debug adapter crashes recently. One of them I'm unable to reproduce which means I need to get more information from the user. Currently, when a debug adapter crashes, the error information that appears in the console is very vague: ! The actual exception that was thrown is not shown. Since I can't repro this, the only ways I can think of to debug are: try/catch around all debugger methods that handles errors and passes them back nicely (and remember to do this for all future methods) the user to run my project from source and debug the debug adapter to catch the error (whilst not the hardest thing in the world, it's a bit involved for an end user) Is it possible to get better information from the error back into the console without having a debugger attached to debug adapter?
I don't know if the text "ERR" in the console was actually supposed to be my error; but it isn't. My error was "AAAAAARGH".
this request makes sense. Not sure though if I am getting your error when your process crashes. Can you be so kind and set a breakpoint make your server crash and check if your message is coming through as a or as something else. Thanks
Do you mean the text? I also don't get that now when trying to repro, only the "terminated unexpectedly" message. If you still want me to try that breakpoint, can you explain how to add a breakpoint there. I did try breaking in my adapter and navigating the callstack (that file wasn't in there anywhere) and also checking the filenames of the files that were (they showed ).
I mean let's try to see if your error "AAAAARGH" surfaces on our side. You should be able to just run regular vscode, F1 open developer tools, wait some time and put a breakpoint by openning a . Also try to put a breakpoint and check if the error stream spits up something.
The breakpoint is not hit, which is perfectly normal since the exception occurs before the socket connection is created. You should be able to reproduce by adding require('unknown_module') to the top of any debugger extension .js file
Ok, I got breakpoints in both and . First wasn't called and the second was called but is and is . So seems like the message isn't there. For testing, all I've done is put inside my debug adapter. Though now I think about it; the error isn't occurring in code that's been executed directly by Code - it's during the response from my debugger. In my debug adapter I spawn a process and I add a handler for . When something comes over and my callback runs, that's where the crash is occurring. I don't know if this changes things (for example, I don't know if this is on another thread?).
That one (in ) didn't seem to be hit either.
Actually, I think I can repro this really easily by just putting in the constructor of the ? Also gets .
This issue has the needs-more-info tag though I think it's easily reproducible with my last comment. Let me know if that's not the case!
I have removed tha tag and plan to look into this issue this week. Thanks
Investigated and the issue here is that I am not getting any exception data from the spawned process. I simply get the code while all the other error chanels are blank. I am not sure what would be the proper solution here. Suggestions are very welcome. Also are all your debug adapters launched using node? If yes then it might be that our  launch is somehow eating up the error if it happens on startup. If this also happens for adapters which are not realying on node to be launched then is not to blame.
please try to disable the launch for node () and see whether this makes a difference. DAs should work independent from . But make sure that the node version used is roughly the same as Electron's version (i.e. 7.9.0).
Yes, using stdfork is the cause here. If I do not use it, I nicely get the error popping up in the extensions output channel. My weekend is starting if someone is feeling smart code review and let me know if you find something fishy about stderr not being wired through.
Then you might want to involve/assign
I am going on a vacation tomorrow evening, and this is like this since forever so pushing to April to investigate with Alex what is going on behind the curatans here.

import * as strings from 'vs/base/common/strings'; import * as objects from 'vs/base/common/objects'; import * as platform from 'vs/base/common/platform'; <del> import * as stdfork from 'vs/base/node/stdFork'; </del> import { Emitter, Event } from 'vs/base/common/event'; import { TPromise } from 'vs/base/common/winjs.base'; import { ExtensionsChannelId } from 'vs/platform/extensionManagement/common/extensionManagement';


Question:
I've had a couple of people report debug adapter crashes recently. One of them I'm unable to reproduce which means I need to get more information from the user. Currently, when a debug adapter crashes, the error information that appears in the console is very vague: ! The actual exception that was thrown is not shown. Since I can't repro this, the only ways I can think of to debug are: try/catch around all debugger methods that handles errors and passes them back nicely (and remember to do this for all future methods) the user to run my project from source and debug the debug adapter to catch the error (whilst not the hardest thing in the world, it's a bit involved for an end user) Is it possible to get better information from the error back into the console without having a debugger attached to debug adapter?
I don't know if the text "ERR" in the console was actually supposed to be my error; but it isn't. My error was "AAAAAARGH".
this request makes sense. Not sure though if I am getting your error when your process crashes. Can you be so kind and set a breakpoint make your server crash and check if your message is coming through as a or as something else. Thanks
Do you mean the text? I also don't get that now when trying to repro, only the "terminated unexpectedly" message. If you still want me to try that breakpoint, can you explain how to add a breakpoint there. I did try breaking in my adapter and navigating the callstack (that file wasn't in there anywhere) and also checking the filenames of the files that were (they showed ).
I mean let's try to see if your error "AAAAARGH" surfaces on our side. You should be able to just run regular vscode, F1 open developer tools, wait some time and put a breakpoint by openning a . Also try to put a breakpoint and check if the error stream spits up something.
The breakpoint is not hit, which is perfectly normal since the exception occurs before the socket connection is created. You should be able to reproduce by adding require('unknown_module') to the top of any debugger extension .js file
Ok, I got breakpoints in both and . First wasn't called and the second was called but is and is . So seems like the message isn't there. For testing, all I've done is put inside my debug adapter. Though now I think about it; the error isn't occurring in code that's been executed directly by Code - it's during the response from my debugger. In my debug adapter I spawn a process and I add a handler for . When something comes over and my callback runs, that's where the crash is occurring. I don't know if this changes things (for example, I don't know if this is on another thread?).
That one (in ) didn't seem to be hit either.
Actually, I think I can repro this really easily by just putting in the constructor of the ? Also gets .
This issue has the needs-more-info tag though I think it's easily reproducible with my last comment. Let me know if that's not the case!
I have removed tha tag and plan to look into this issue this week. Thanks
Investigated and the issue here is that I am not getting any exception data from the spawned process. I simply get the code while all the other error chanels are blank. I am not sure what would be the proper solution here. Suggestions are very welcome. Also are all your debug adapters launched using node? If yes then it might be that our  launch is somehow eating up the error if it happens on startup. If this also happens for adapters which are not realying on node to be launched then is not to blame.
please try to disable the launch for node () and see whether this makes a difference. DAs should work independent from . But make sure that the node version used is roughly the same as Electron's version (i.e. 7.9.0).
Yes, using stdfork is the cause here. If I do not use it, I nicely get the error popping up in the extensions output channel. My weekend is starting if someone is feeling smart code review and let me know if you find something fishy about stderr not being wired through.
Then you might want to involve/assign
I am going on a vacation tomorrow evening, and this is like this since forever so pushing to April to investigate with Alex what is going on behind the curatans here.

if (this.adapterExecutable.command === 'node' && this.outputService) { if (Array.isArray(this.adapterExecutable.args) && this.adapterExecutable.args.length > 0) { <del> stdfork.fork(this.adapterExecutable.args[0], this.adapterExecutable.args.slice(1), {}, (err, child) => { if (err) { e(new Error(nls.localize('unableToLaunchDebugAdapter', "Unable to launch debug adapter from '{0}'.", this.adapterExecutable.args[0]))); } this.serverProcess = child; c(null); </del> <ins> const child = cp.fork(this.adapterExecutable.args[0], this.adapterExecutable.args.slice(1), { execArgv: ['-e', 'delete process.env.ELECTRON_RUN_AS_NODE;require(process.argv[1])'].concat(process.execArgv || []), silent: true </ins> }); <ins> if (!child.pid) { e(new Error(nls.localize('unableToLaunchDebugAdapter', "Unable to launch debug adapter from '{0}'.", this.adapterExecutable.args[0]))); } this.serverProcess = child; c(null); </ins> } else { e(new Error(nls.localize('unableToLaunchDebugAdapterNoArgs', "Unable to launch debug adapter."))); }


Question: From: Steps to Reproduce: VSCode Version: 1.20.1 OS Version: macOS High Sierra 10.13.3 Steps to Reproduce: markdown file markdown to first line in preview or double click on the first line Does this issue occur when all extensions are disabled?: Yes

if (previous) { if (next) { const betweenProgress = (offset - window.scrollY - previous.element.getBoundingClientRect().top) / (next.element.getBoundingClientRect().top - previous.element.getBoundingClientRect().top); <del> return previous.line + betweenProgress * (next.line - previous.line); </del> <ins> const line = previous.line + betweenProgress * (next.line - previous.line); return (0 <= line) ? line : 0; </ins> } else { <del> return previous.line; </del> <ins> return (0 <= previous.line) ? previous.line : 0; </ins> } } return null;


Question:
I'm using vscode for editing commit messages and merging: .gitconfig After editing the commit and closing the commit editing / merge tab is it possible focus back the integrated terminal? I had the same feature in my vim
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.561 --<!-- potentialduplicatescomment --
I'm not sure there is a nice way to do this, any ideas?
I am actually also hitting this quite often... not sure how to best fix this. We do have code in place to delete the , so we are aware of the editor closing that was triggered via a invocation. But bottom line is that we would need to know that the operation was triggered from the integrated terminal to begin with...
there's this: They may not be 100% reliable though as an external terminal could have been launched by the terminal (could check ). Maybe the off chance of one of those happening is worth forcing focus? Another way you could do this is track the PID it was launched from on the CLI/main size and see if it's a child process of the terminal. Seems like a lot of work for such a small thing, we also only track the terminal process tree on Windows currently.
it is a bit of a hack but the terminal could also listen to the editor closing and checking if the file closed was part of  and then just put focus back to the terminal if: the terminal is open the terminal just had focus (?)
it's not so easy to know that the terminal launched the code CLI, it may be down the track when we track the process tree more though. When an editor is closed that was launched via --wait, can we track the and and focus the terminal of the same renderer if they match?
to clarify what I mean - integrated terminal - terminal which is integrated to the editor for example from vscode terminal: git add . git commit -a <vscode opens commit message editorI'm editing a commit -I'm pressing save and close the tab Integrated terminal should be focused back I apologize accidentally pressed the wrong button
yeah but this has to happen from the terminal layer, cannot happen from the workbench to avoid layer breakage. Are you saying that these environment variables are passed to the instance of VS Code that is starting from the integrated terminal? We would probably need to wire these in through lots of places on the main side to eventually reach the renderer.
when code is launched via the CLI it inherits the environment of the shell which contains these vars. Ok, let's go with listening to editor close and checking  as you suggest. That is definitely nicer than wiring the values through. The listening should probably be done in PRs welcome
Is it alright to watch for waitMarkerFile deletion, since workbench will delete the marker file to signal when editing is done? See . Also, see the proposed fix . Using my development build, I'm not able to force vscode to use its window for resolving merge conflicts. Instead a new window is opened. My git config is identical to what aliev posted above. Any suggestions?
try to use that should force to reuse the last active instance. I think there are some things missing from your change: only do this listening if the marker file was opened from the integrated terminal handle the opening of the marker file within the running instance, in that case the request will come in via  and the configuration object that you are using will not reflect that, I think it would need a new event or something similar that gets emitted when a marker file is opened in the running instance
I think this is not as straight forward for a pull request so I went ahead to implement this via I took your idea about watching for the marker file to get deleted, thanks for that
on to the next one :wink:

else { // Do open files <del> usedWindows.push(this.doOpenFilesInExistingWindow(bestWindowOrFolder, filesToOpen, filesToCreate, filesToDiff, filesToWait)); </del> <ins> usedWindows.push(this.doOpenFilesInExistingWindow(openConfig, bestWindowOrFolder, filesToOpen, filesToCreate, filesToDiff, filesToWait)); </ins> // Reset these because we handled them filesToOpen = [];


Question:
I'm using vscode for editing commit messages and merging: .gitconfig After editing the commit and closing the commit editing / merge tab is it possible focus back the integrated terminal? I had the same feature in my vim
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.561 --<!-- potentialduplicatescomment --
I'm not sure there is a nice way to do this, any ideas?
I am actually also hitting this quite often... not sure how to best fix this. We do have code in place to delete the , so we are aware of the editor closing that was triggered via a invocation. But bottom line is that we would need to know that the operation was triggered from the integrated terminal to begin with...
there's this: They may not be 100% reliable though as an external terminal could have been launched by the terminal (could check ). Maybe the off chance of one of those happening is worth forcing focus? Another way you could do this is track the PID it was launched from on the CLI/main size and see if it's a child process of the terminal. Seems like a lot of work for such a small thing, we also only track the terminal process tree on Windows currently.
it is a bit of a hack but the terminal could also listen to the editor closing and checking if the file closed was part of  and then just put focus back to the terminal if: the terminal is open the terminal just had focus (?)
it's not so easy to know that the terminal launched the code CLI, it may be down the track when we track the process tree more though. When an editor is closed that was launched via --wait, can we track the and and focus the terminal of the same renderer if they match?
to clarify what I mean - integrated terminal - terminal which is integrated to the editor for example from vscode terminal: git add . git commit -a <vscode opens commit message editorI'm editing a commit -I'm pressing save and close the tab Integrated terminal should be focused back I apologize accidentally pressed the wrong button
yeah but this has to happen from the terminal layer, cannot happen from the workbench to avoid layer breakage. Are you saying that these environment variables are passed to the instance of VS Code that is starting from the integrated terminal? We would probably need to wire these in through lots of places on the main side to eventually reach the renderer.
when code is launched via the CLI it inherits the environment of the shell which contains these vars. Ok, let's go with listening to editor close and checking  as you suggest. That is definitely nicer than wiring the values through. The listening should probably be done in PRs welcome
Is it alright to watch for waitMarkerFile deletion, since workbench will delete the marker file to signal when editing is done? See . Also, see the proposed fix . Using my development build, I'm not able to force vscode to use its window for resolving merge conflicts. Instead a new window is opened. My git config is identical to what aliev posted above. Any suggestions?
try to use that should force to reuse the last active instance. I think there are some things missing from your change: only do this listening if the marker file was opened from the integrated terminal handle the opening of the marker file within the running instance, in that case the request will come in via  and the configuration object that you are using will not reflect that, I think it would need a new event or something similar that gets emitted when a marker file is opened in the running instance
I think this is not as straight forward for a pull request so I went ahead to implement this via I took your idea about watching for the marker file to get deleted, thanks for that
on to the next one :wink:

const windowOnWorkspace = windowsOnWorkspace[0]; // Do open files <del> usedWindows.push(this.doOpenFilesInExistingWindow(windowOnWorkspace, filesToOpen, filesToCreate, filesToDiff, filesToWait)); </del> <ins> usedWindows.push(this.doOpenFilesInExistingWindow(openConfig, windowOnWorkspace, filesToOpen, filesToCreate, filesToDiff, filesToWait)); </ins> // Reset these because we handled them filesToOpen = [];


Question:
I'm using vscode for editing commit messages and merging: .gitconfig After editing the commit and closing the commit editing / merge tab is it possible focus back the integrated terminal? I had the same feature in my vim
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.561 --<!-- potentialduplicatescomment --
I'm not sure there is a nice way to do this, any ideas?
I am actually also hitting this quite often... not sure how to best fix this. We do have code in place to delete the , so we are aware of the editor closing that was triggered via a invocation. But bottom line is that we would need to know that the operation was triggered from the integrated terminal to begin with...
there's this: They may not be 100% reliable though as an external terminal could have been launched by the terminal (could check ). Maybe the off chance of one of those happening is worth forcing focus? Another way you could do this is track the PID it was launched from on the CLI/main size and see if it's a child process of the terminal. Seems like a lot of work for such a small thing, we also only track the terminal process tree on Windows currently.
it is a bit of a hack but the terminal could also listen to the editor closing and checking if the file closed was part of  and then just put focus back to the terminal if: the terminal is open the terminal just had focus (?)
it's not so easy to know that the terminal launched the code CLI, it may be down the track when we track the process tree more though. When an editor is closed that was launched via --wait, can we track the and and focus the terminal of the same renderer if they match?
to clarify what I mean - integrated terminal - terminal which is integrated to the editor for example from vscode terminal: git add . git commit -a <vscode opens commit message editorI'm editing a commit -I'm pressing save and close the tab Integrated terminal should be focused back I apologize accidentally pressed the wrong button
yeah but this has to happen from the terminal layer, cannot happen from the workbench to avoid layer breakage. Are you saying that these environment variables are passed to the instance of VS Code that is starting from the integrated terminal? We would probably need to wire these in through lots of places on the main side to eventually reach the renderer.
when code is launched via the CLI it inherits the environment of the shell which contains these vars. Ok, let's go with listening to editor close and checking  as you suggest. That is definitely nicer than wiring the values through. The listening should probably be done in PRs welcome
Is it alright to watch for waitMarkerFile deletion, since workbench will delete the marker file to signal when editing is done? See . Also, see the proposed fix . Using my development build, I'm not able to force vscode to use its window for resolving merge conflicts. Instead a new window is opened. My git config is identical to what aliev posted above. Any suggestions?
try to use that should force to reuse the last active instance. I think there are some things missing from your change: only do this listening if the marker file was opened from the integrated terminal handle the opening of the marker file within the running instance, in that case the request will come in via  and the configuration object that you are using will not reflect that, I think it would need a new event or something similar that gets emitted when a marker file is opened in the running instance
I think this is not as straight forward for a pull request so I went ahead to implement this via I took your idea about watching for the marker file to get deleted, thanks for that
on to the next one :wink:

const windowOnFolderPath = windowsOnFolderPath[0]; // Do open files <del> usedWindows.push(this.doOpenFilesInExistingWindow(windowOnFolderPath, filesToOpen, filesToCreate, filesToDiff, filesToWait)); </del> <ins> usedWindows.push(this.doOpenFilesInExistingWindow(openConfig, windowOnFolderPath, filesToOpen, filesToCreate, filesToDiff, filesToWait)); </ins> // Reset these because we handled them filesToOpen = [];


Question:
I'm using vscode for editing commit messages and merging: .gitconfig After editing the commit and closing the commit editing / merge tab is it possible focus back the integrated terminal? I had the same feature in my vim
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.561 --<!-- potentialduplicatescomment --
I'm not sure there is a nice way to do this, any ideas?
I am actually also hitting this quite often... not sure how to best fix this. We do have code in place to delete the , so we are aware of the editor closing that was triggered via a invocation. But bottom line is that we would need to know that the operation was triggered from the integrated terminal to begin with...
there's this: They may not be 100% reliable though as an external terminal could have been launched by the terminal (could check ). Maybe the off chance of one of those happening is worth forcing focus? Another way you could do this is track the PID it was launched from on the CLI/main size and see if it's a child process of the terminal. Seems like a lot of work for such a small thing, we also only track the terminal process tree on Windows currently.
it is a bit of a hack but the terminal could also listen to the editor closing and checking if the file closed was part of  and then just put focus back to the terminal if: the terminal is open the terminal just had focus (?)
it's not so easy to know that the terminal launched the code CLI, it may be down the track when we track the process tree more though. When an editor is closed that was launched via --wait, can we track the and and focus the terminal of the same renderer if they match?
to clarify what I mean - integrated terminal - terminal which is integrated to the editor for example from vscode terminal: git add . git commit -a <vscode opens commit message editorI'm editing a commit -I'm pressing save and close the tab Integrated terminal should be focused back I apologize accidentally pressed the wrong button
yeah but this has to happen from the terminal layer, cannot happen from the workbench to avoid layer breakage. Are you saying that these environment variables are passed to the instance of VS Code that is starting from the integrated terminal? We would probably need to wire these in through lots of places on the main side to eventually reach the renderer.
when code is launched via the CLI it inherits the environment of the shell which contains these vars. Ok, let's go with listening to editor close and checking  as you suggest. That is definitely nicer than wiring the values through. The listening should probably be done in PRs welcome
Is it alright to watch for waitMarkerFile deletion, since workbench will delete the marker file to signal when editing is done? See . Also, see the proposed fix . Using my development build, I'm not able to force vscode to use its window for resolving merge conflicts. Instead a new window is opened. My git config is identical to what aliev posted above. Any suggestions?
try to use that should force to reuse the last active instance. I think there are some things missing from your change: only do this listening if the marker file was opened from the integrated terminal handle the opening of the marker file within the running instance, in that case the request will come in via  and the configuration object that you are using will not reflect that, I think it would need a new event or something similar that gets emitted when a marker file is opened in the running instance
I think this is not as straight forward for a pull request so I went ahead to implement this via I took your idea about watching for the marker file to get deleted, thanks for that
on to the next one :wink:

return arrays.distinct(usedWindows); } <del> private doOpenFilesInExistingWindow(window: ICodeWindow, filesToOpen: IPath[], filesToCreate: IPath[], filesToDiff: IPath[], filesToWait: IPathsToWaitFor): ICodeWindow { </del> <ins> private doOpenFilesInExistingWindow(configuration: IOpenConfiguration, window: ICodeWindow, filesToOpen: IPath[], filesToCreate: IPath[], filesToDiff: IPath[], filesToWait: IPathsToWaitFor): ICodeWindow { </ins> window.focus(); // make sure window has focus window.ready().then(readyWindow => { <del> readyWindow.send('vscode:openFiles', { filesToOpen, filesToCreate, filesToDiff, filesToWait }); </del> <ins> const termProgram = configuration.userEnv ? configuration.userEnv['TERM_PROGRAM'] : void 0; readyWindow.send('vscode:openFiles', { filesToOpen, filesToCreate, filesToDiff, filesToWait, termProgram }); </ins> }); return window;


Question:
I'm using vscode for editing commit messages and merging: .gitconfig After editing the commit and closing the commit editing / merge tab is it possible focus back the integrated terminal? I had the same feature in my vim
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.561 --<!-- potentialduplicatescomment --
I'm not sure there is a nice way to do this, any ideas?
I am actually also hitting this quite often... not sure how to best fix this. We do have code in place to delete the , so we are aware of the editor closing that was triggered via a invocation. But bottom line is that we would need to know that the operation was triggered from the integrated terminal to begin with...
there's this: They may not be 100% reliable though as an external terminal could have been launched by the terminal (could check ). Maybe the off chance of one of those happening is worth forcing focus? Another way you could do this is track the PID it was launched from on the CLI/main size and see if it's a child process of the terminal. Seems like a lot of work for such a small thing, we also only track the terminal process tree on Windows currently.
it is a bit of a hack but the terminal could also listen to the editor closing and checking if the file closed was part of  and then just put focus back to the terminal if: the terminal is open the terminal just had focus (?)
it's not so easy to know that the terminal launched the code CLI, it may be down the track when we track the process tree more though. When an editor is closed that was launched via --wait, can we track the and and focus the terminal of the same renderer if they match?
to clarify what I mean - integrated terminal - terminal which is integrated to the editor for example from vscode terminal: git add . git commit -a <vscode opens commit message editorI'm editing a commit -I'm pressing save and close the tab Integrated terminal should be focused back I apologize accidentally pressed the wrong button
yeah but this has to happen from the terminal layer, cannot happen from the workbench to avoid layer breakage. Are you saying that these environment variables are passed to the instance of VS Code that is starting from the integrated terminal? We would probably need to wire these in through lots of places on the main side to eventually reach the renderer.
when code is launched via the CLI it inherits the environment of the shell which contains these vars. Ok, let's go with listening to editor close and checking  as you suggest. That is definitely nicer than wiring the values through. The listening should probably be done in PRs welcome
Is it alright to watch for waitMarkerFile deletion, since workbench will delete the marker file to signal when editing is done? See . Also, see the proposed fix . Using my development build, I'm not able to force vscode to use its window for resolving merge conflicts. Instead a new window is opened. My git config is identical to what aliev posted above. Any suggestions?
try to use that should force to reuse the last active instance. I think there are some things missing from your change: only do this listening if the marker file was opened from the integrated terminal handle the opening of the marker file within the running instance, in that case the request will come in via  and the configuration object that you are using will not reflect that, I think it would need a new event or something similar that gets emitted when a marker file is opened in the running instance
I think this is not as straight forward for a pull request so I went ahead to implement this via I took your idea about watching for the marker file to get deleted, thanks for that
on to the next one :wink:

filesToCreate?: IPath[]; filesToDiff?: IPath[]; filesToWait?: IPathsToWaitFor; <ins> termProgram?: string; </ins> } export interface IAddFoldersRequest {


Question:
I'm using vscode for editing commit messages and merging: .gitconfig After editing the commit and closing the commit editing / merge tab is it possible focus back the integrated terminal? I had the same feature in my vim
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.561 --<!-- potentialduplicatescomment --
I'm not sure there is a nice way to do this, any ideas?
I am actually also hitting this quite often... not sure how to best fix this. We do have code in place to delete the , so we are aware of the editor closing that was triggered via a invocation. But bottom line is that we would need to know that the operation was triggered from the integrated terminal to begin with...
there's this: They may not be 100% reliable though as an external terminal could have been launched by the terminal (could check ). Maybe the off chance of one of those happening is worth forcing focus? Another way you could do this is track the PID it was launched from on the CLI/main size and see if it's a child process of the terminal. Seems like a lot of work for such a small thing, we also only track the terminal process tree on Windows currently.
it is a bit of a hack but the terminal could also listen to the editor closing and checking if the file closed was part of  and then just put focus back to the terminal if: the terminal is open the terminal just had focus (?)
it's not so easy to know that the terminal launched the code CLI, it may be down the track when we track the process tree more though. When an editor is closed that was launched via --wait, can we track the and and focus the terminal of the same renderer if they match?
to clarify what I mean - integrated terminal - terminal which is integrated to the editor for example from vscode terminal: git add . git commit -a <vscode opens commit message editorI'm editing a commit -I'm pressing save and close the tab Integrated terminal should be focused back I apologize accidentally pressed the wrong button
yeah but this has to happen from the terminal layer, cannot happen from the workbench to avoid layer breakage. Are you saying that these environment variables are passed to the instance of VS Code that is starting from the integrated terminal? We would probably need to wire these in through lots of places on the main side to eventually reach the renderer.
when code is launched via the CLI it inherits the environment of the shell which contains these vars. Ok, let's go with listening to editor close and checking  as you suggest. That is definitely nicer than wiring the values through. The listening should probably be done in PRs welcome
Is it alright to watch for waitMarkerFile deletion, since workbench will delete the marker file to signal when editing is done? See . Also, see the proposed fix . Using my development build, I'm not able to force vscode to use its window for resolving merge conflicts. Instead a new window is opened. My git config is identical to what aliev posted above. Any suggestions?
try to use that should force to reuse the last active instance. I think there are some things missing from your change: only do this listening if the marker file was opened from the integrated terminal handle the opening of the marker file within the running instance, in that case the request will come in via  and the configuration object that you are using will not reflect that, I think it would need a new event or something similar that gets emitted when a marker file is opened in the running instance
I think this is not as straight forward for a pull request so I went ahead to implement this via I took your idea about watching for the marker file to get deleted, thanks for that
on to the next one :wink:

import { TERMINAL_BACKGROUND_COLOR, TERMINAL_BORDER_COLOR } from 'vs/workbench/parts/terminal/electron-browser/terminalColorRegistry'; import { DataTransfers } from 'vs/base/browser/dnd'; import { ILifecycleService, LifecyclePhase } from 'vs/platform/lifecycle/common/lifecycle'; <ins> import { ipcRenderer as ipc } from 'electron'; import { IOpenFileRequest } from 'vs/platform/windows/common/windows'; import { whenDeleted } from 'vs/base/node/pfs'; </ins> export class TerminalPanel extends Panel {


Question:
I'm using vscode for editing commit messages and merging: .gitconfig After editing the commit and closing the commit editing / merge tab is it possible focus back the integrated terminal? I had the same feature in my vim
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.561 --<!-- potentialduplicatescomment --
I'm not sure there is a nice way to do this, any ideas?
I am actually also hitting this quite often... not sure how to best fix this. We do have code in place to delete the , so we are aware of the editor closing that was triggered via a invocation. But bottom line is that we would need to know that the operation was triggered from the integrated terminal to begin with...
there's this: They may not be 100% reliable though as an external terminal could have been launched by the terminal (could check ). Maybe the off chance of one of those happening is worth forcing focus? Another way you could do this is track the PID it was launched from on the CLI/main size and see if it's a child process of the terminal. Seems like a lot of work for such a small thing, we also only track the terminal process tree on Windows currently.
it is a bit of a hack but the terminal could also listen to the editor closing and checking if the file closed was part of  and then just put focus back to the terminal if: the terminal is open the terminal just had focus (?)
it's not so easy to know that the terminal launched the code CLI, it may be down the track when we track the process tree more though. When an editor is closed that was launched via --wait, can we track the and and focus the terminal of the same renderer if they match?
to clarify what I mean - integrated terminal - terminal which is integrated to the editor for example from vscode terminal: git add . git commit -a <vscode opens commit message editorI'm editing a commit -I'm pressing save and close the tab Integrated terminal should be focused back I apologize accidentally pressed the wrong button
yeah but this has to happen from the terminal layer, cannot happen from the workbench to avoid layer breakage. Are you saying that these environment variables are passed to the instance of VS Code that is starting from the integrated terminal? We would probably need to wire these in through lots of places on the main side to eventually reach the renderer.
when code is launched via the CLI it inherits the environment of the shell which contains these vars. Ok, let's go with listening to editor close and checking  as you suggest. That is definitely nicer than wiring the values through. The listening should probably be done in PRs welcome
Is it alright to watch for waitMarkerFile deletion, since workbench will delete the marker file to signal when editing is done? See . Also, see the proposed fix . Using my development build, I'm not able to force vscode to use its window for resolving merge conflicts. Instead a new window is opened. My git config is identical to what aliev posted above. Any suggestions?
try to use that should force to reuse the last active instance. I think there are some things missing from your change: only do this listening if the marker file was opened from the integrated terminal handle the opening of the marker file within the running instance, in that case the request will come in via  and the configuration object that you are using will not reflect that, I think it would need a new event or something similar that gets emitted when a marker file is opened in the running instance
I think this is not as straight forward for a pull request so I went ahead to implement this via I took your idea about watching for the marker file to get deleted, thanks for that
on to the next one :wink:

this._updateFont(); this._updateTheme(); <ins> ipc.on('vscode:openFiles', (_event: any, request: IOpenFileRequest) => { // if the request to open files is coming in from the integrated terminal (identified though // the termProgram variable) and we are instructed to wait for editors close, wait for the // marker file to get deleted and then focus back to the integrated terminal. if (request.termProgram === 'vscode' && request.filesToWait) { whenDeleted(request.filesToWait.waitMarkerFilePath).then(() => this.focus()); } }); </ins> // Force another layout (first is setContainers) since config has changed this.layout(new Dimension(this._terminalContainer.offsetWidth, this._terminalContainer.offsetHeight)); return TPromise.as(void 0);


Question:
In light themes the status bar text changes from white to black, but progress spinners do not so they're hard to see:
This icon is probably not themable yet. E.g. for the status bar feedback smiley we use trick to allow to change the color of it (). Depending on the outcome of we might move this into the notification area though.
fyi, the fix is to use a font for the icon (in this case our octicons). I found the sync icon fitting because we already use it for SCM sync: ! Alternatively we could use this animation: !

if (this.partService.isCreated() && !errors.isPromiseCanceledError(error)) { const actions: INotificationActions = { primary: [] }; if (errors.isErrorWithActions(error)) { <del> actions.primary = error.actions; </del> <ins> actions.primary = (error as errors.IErrorWithActions).actions; </ins> } const handle = this.notificationService.notify({


Question:
In light themes the status bar text changes from white to black, but progress spinners do not so they're hard to see:
This icon is probably not themable yet. E.g. for the status bar feedback smiley we use trick to allow to change the color of it (). Depending on the outcome of we might move this into the notification area though.
fyi, the fix is to use a font for the icon (in this case our octicons). I found the sync icon fitting because we already use it for SCM sync: ! Alternatively we could use this animation: !

for (let i = 0, len = events.length; i < len; i++) { const resource = events[i].resource; const isJson = paths.extname(resource.fsPath) === '.json'; <del> const isDeletedSettingsFolder = (events[i].type === FileChangeType.DELETED && paths.isEqual(paths.basename(resource.fsPath), this.configFolderRelativePath)); </del> <ins> const isDeletedSettingsFolder = (events[i].type === FileChangeType.DELETED && paths.basename(resource.fsPath) === this.configFolderRelativePath); </ins> if (!isJson && !isDeletedSettingsFolder) { continue; // only JSON files or the actual settings folder }


Question:
In light themes the status bar text changes from white to black, but progress spinners do not so they're hard to see:
This icon is probably not themable yet. E.g. for the status bar feedback smiley we use trick to allow to change the color of it (). Depending on the outcome of we might move this into the notification area though.
fyi, the fix is to use a font for the icon (in this case our octicons). I found the sync icon fitting because we already use it for SCM sync: ! Alternatively we could use this animation: !

<del> <?xml version='1.0' standalone='no' ?> <svg xmlns='http://www.w3.org/2000/svg' version='1.1' width='10px' height='10px'> <style> circle { animation: ball 0.6s linear infinite; } circle:nth-child(2) { animation-delay: 0.075s; } circle:nth-child(3) { animation-delay: 0.15s; } circle:nth-child(4) { animation-delay: 0.225s; } circle:nth-child(5) { animation-delay: 0.3s; } circle:nth-child(6) { animation-delay: 0.375s; } circle:nth-child(7) { animation-delay: 0.45s; } circle:nth-child(8) { animation-delay: 0.525s; } @keyframes ball { from { opacity: 1; } to { opacity: 0.3; } } </style> <g style="fill:white;"> <circle cx='5' cy='1' r='1' style='opacity:0.3;' /> <circle cx='7.8284' cy='2.1716' r='1' style='opacity:0.3;' /> <circle cx='9' cy='5' r='1' style='opacity:0.3;' /> <circle cx='7.8284' cy='7.8284' r='1' style='opacity:0.3;' /> <circle cx='5' cy='9' r='1' style='opacity:0.3;' /> <circle cx='2.1716' cy='7.8284' r='1' style='opacity:0.3;' /> <circle cx='1' cy='5' r='1' style='opacity:0.3;' /> <circle cx='2.1716' cy='2.1716' r='1' style='opacity:0.3;' /> </g> </svg> </del>


Question:
In light themes the status bar text changes from white to black, but progress spinners do not so they're hard to see:
This icon is probably not themable yet. E.g. for the status bar feedback smiley we use trick to allow to change the color of it (). Depending on the outcome of we might move this into the notification area though.
fyi, the fix is to use a font for the icon (in this case our octicons). I found the sync icon fitting because we already use it for SCM sync: ! Alternatively we could use this animation: !

*--------------------------------------------------------------------------------------------*/ .monaco-workbench > .part.statusbar > .statusbar-item.progress { <del> background-image: url(progress.svg); background-repeat: no-repeat; background-position: left; padding-left: 14px; display: inline; </del> <ins> padding-left: 5px; } .monaco-workbench > .part.statusbar > .statusbar-item.progress .spinner-container { padding-right: 5px; </ins> } .monaco-workbench .progress-badge > .badge-content {


Question:
In light themes the status bar text changes from white to black, but progress spinners do not so they're hard to see:
This icon is probably not themable yet. E.g. for the status bar feedback smiley we use trick to allow to change the color of it (). Depending on the outcome of we might move this into the notification area though.
fyi, the fix is to use a font for the icon (in this case our octicons). I found the sync icon fitting because we already use it for SCM sync: ! Alternatively we could use this animation: !

render(element: HTMLElement): IDisposable { this._element = element; <del> this._label = new OcticonLabel(this._element); </del> this._element.classList.add('progress'); <ins> const container = document.createElement('span'); this._element.appendChild(container); const spinnerContainer = document.createElement('span'); spinnerContainer.classList.add('spinner-container'); container.appendChild(spinnerContainer); const spinner = new OcticonLabel(spinnerContainer); spinner.text = '$(sync~spin)'; const labelContainer = document.createElement('span'); container.appendChild(labelContainer); this._label = new OcticonLabel(labelContainer); </ins> this.hide(); return null; }


Question: Issue Type: <bFeature Request</bVSCode uses different conventions for the problem counters in the problems view and in the status bar. The problems view displays: 1 2 ... 999 1K 2K ... 10K+ and the tooltip shows the actual number. The status bar displays: for errors/warnings: 1 2 ... 99+ and the tooltip doesn't show the actual number. for infos: 1 2 ... (always the actual number), the tooltip doesn't show the actual number. <img width="118" alt="problems-view" src="https://user-"<img width="108" alt="status-bar" src="https://user-"VS Code version: Code 1.21.0 (, 2018-03-07T10:54:22.798Z) OS version: Darwin x64 17.4.0

const info = document.createElement('div'); const building = document.createElement('div'); <ins> const errorTitle = n => nls.localize('totalErrors', "{0} Errors", n); const warningTitle = n => nls.localize('totalWarnings', "{0} Warnings", n); const infoTitle = n => nls.localize('totalInfos', "{0} Infos", n); </ins> Dom.addClass(element, 'task-statusbar-item'); Dom.addClass(label, 'task-statusbar-item-label'); element.appendChild(label); <del> element.title = nls.localize('problems', "Problems"); </del> Dom.addClass(errorIcon, 'task-statusbar-item-label-error'); Dom.addClass(errorIcon, 'mask-icon');


Question: Issue Type: <bFeature Request</bVSCode uses different conventions for the problem counters in the problems view and in the status bar. The problems view displays: 1 2 ... 999 1K 2K ... 10K+ and the tooltip shows the actual number. The status bar displays: for errors/warnings: 1 2 ... 99+ and the tooltip doesn't show the actual number. for infos: 1 2 ... (always the actual number), the tooltip doesn't show the actual number. <img width="118" alt="problems-view" src="https://user-"<img width="108" alt="status-bar" src="https://user-"VS Code version: Code 1.21.0 (, 2018-03-07T10:54:22.798Z) OS version: Darwin x64 17.4.0

Dom.addClass(error, 'task-statusbar-item-label-counter'); error.innerHTML = '0'; <ins> error.title = errorIcon.title = errorTitle(0); </ins> label.appendChild(error); Dom.addClass(warningIcon, 'task-statusbar-item-label-warning');


Question: Issue Type: <bFeature Request</bVSCode uses different conventions for the problem counters in the problems view and in the status bar. The problems view displays: 1 2 ... 999 1K 2K ... 10K+ and the tooltip shows the actual number. The status bar displays: for errors/warnings: 1 2 ... 99+ and the tooltip doesn't show the actual number. for infos: 1 2 ... (always the actual number), the tooltip doesn't show the actual number. <img width="118" alt="problems-view" src="https://user-"<img width="108" alt="status-bar" src="https://user-"VS Code version: Code 1.21.0 (, 2018-03-07T10:54:22.798Z) OS version: Darwin x64 17.4.0

Dom.addClass(warning, 'task-statusbar-item-label-counter'); warning.innerHTML = '0'; <ins> warning.title = warningIcon.title = warningTitle(0); </ins> label.appendChild(warning); Dom.addClass(infoIcon, 'task-statusbar-item-label-info');


Question: Issue Type: <bFeature Request</bVSCode uses different conventions for the problem counters in the problems view and in the status bar. The problems view displays: 1 2 ... 999 1K 2K ... 10K+ and the tooltip shows the actual number. The status bar displays: for errors/warnings: 1 2 ... 99+ and the tooltip doesn't show the actual number. for infos: 1 2 ... (always the actual number), the tooltip doesn't show the actual number. <img width="118" alt="problems-view" src="https://user-"<img width="108" alt="status-bar" src="https://user-"VS Code version: Code 1.21.0 (, 2018-03-07T10:54:22.798Z) OS version: Darwin x64 17.4.0

} })); <del> let updateStatus = (element: HTMLDivElement, icon: HTMLDivElement, stats: number): boolean => { if (stats > 0) { element.innerHTML = stats.toString(); $(element).show(); $(icon).show(); return true; </del> <ins> const manyProblems = nls.localize('manyProblems', "10K+"); const packNumber = n => n > 9999 ? manyProblems : n > 999 ? n.toString().charAt(0) + 'K' : n.toString(); let updateLabel = (stats: MarkerStatistics) => { error.innerHTML = packNumber(stats.errors); error.title = errorIcon.title = errorTitle(stats.errors); warning.innerHTML = packNumber(stats.warnings); warning.title = warningIcon.title = warningTitle(stats.warnings); if (stats.infos > 0) { info.innerHTML = packNumber(stats.infos); info.title = infoIcon.title = infoTitle(stats.infos); $(info).show(); $(infoIcon).show(); </ins> } else { <del> $(element).hide(); $(icon).hide(); return false; </del> <ins> $(info).hide(); $(infoIcon).hide(); </ins> } }; <del> let manyMarkers = nls.localize('manyMarkers', "99+"); let updateLabel = (stats: MarkerStatistics) => { error.innerHTML = stats.errors < 100 ? stats.errors.toString() : manyMarkers; warning.innerHTML = stats.warnings < 100 ? stats.warnings.toString() : manyMarkers; updateStatus(info, infoIcon, stats.infos); }; </del> this.markerService.onMarkerChanged((changedResources) => { updateLabel(this.markerService.getStatistics()); });


top, left, canUseZeroSizeTextarea ? 0 : 1, this._lineHeight ); <ins> // In case the textarea contains a word, we're going to try to align the textarea's cursor // with our cursor by scrolling the textarea as much as possible this.textArea.domNode.scrollLeft = 1000000; </ins> return; }


Question:
VSCode Version: 1.21.0 OS Version: Windows 10 Redstone 4 Steps to Reproduce: create a configuration type: { "type": "node", "request": "launch", "name": "Stuff", "program": "${workspaceFolder}Stuff" }, Save correct behavior in drop down where you can select that item. the exact same item (change only the program path, leave name the same) as a second configuration. { "type": "node", "request": "launch", "name": "Stuff", "program": "${workspaceFolder}Stuff2" }, your new item missing in drop down because you used same name. same name, by changing "Stuff" to "Stuff2" { "type": "node", "request": "launch", "name": "Stuff2", "program": "${workspaceFolder}Stuff2" }, your new config shows up but you can not select it. (Hover over does not highlight item, clicking does not select item) VSCode correct behavior. Does this issue occur when all extensions are disabled?: Yes
working on this. fairly certain it's related to terminal disposal and issue drop-down options get updated before the instance count is changed. non- atomic from select box view. It would be very helpful for your review once I have something finalized , I think the order of execution is very critical here.
thanks for looking into this. I can review the PR once it is ready. We can verify if that is the same issue by opening F1 developer tools and checking the debug console for potential errors.
I was able to partially reproduce your issue. While I did not have a problem with two debug configurations with the same name, I did see the hover issue. It it appears that you can still select the item with the keyboard so it's actually probably a misplaced disable class within the CSS. It is also still possibly related to another index problem with a twist on the results. StayTuned. !
One thing I left out that I should have mentioned is I also have configurations spanning mutiple workspaces. This issue was in a single workspace, however I have multiple configs which it merges together.
cc: I can reproduce this in several ways. It appears to be an odd "sticky" class label within the list. I have a fix , I would consider the work around. I will commit tomorrow with comments to at least avoid the problem for now. do you use insiders to check after I merge?
I do not currently, but I can, I'll check it after the merge and let you know.
Merged into master. Should be a next insiders. I am not closing this issue as I still think this is a workaround.

if (optionDisabled) { dom.addClass((<HTMLElement>data.root), 'option-disabled'); } else { <del> // TODO: verify if there is a list issue with old classes on rows // This class removal should not be necessary </del> <ins> // Make sure we do class removal from prior template rendering </ins> dom.removeClass((<HTMLElement>data.root), 'option-disabled'); } }


Question:
Refs: I like that the relatedInformation message has a nice different verbatim font and that makes it differ well enough, I suggest to not use a different background as imho the effect does not look that nice and we do not do it anywhere else to my knowledge. Also in the F8 we do not use a special background !
Yeah, it's the default rendering we have for markdown. Not sure I have change that without making people sad...
Also, the bullets do not appear in the Problems pane or when F8. Why have them here?

hoverMessage.appendMarkdown('n'); for (const { message, resource, startLineNumber, startColumn } of relatedInformation) { hoverMessage.appendMarkdown( <del> `* [${basename(resource.path)}(${startLineNumber}, ${startColumn})](${resource.toString(false)}#${startLineNumber},${startColumn}): `${message}` n` </del> <ins> `* [${basename(resource.path)}(${startLineNumber}, ${startColumn})](${resource.toString(false)}#${startLineNumber},${startColumn}): ` </ins> ); <ins> hoverMessage.appendText(`${message}`); hoverMessage.appendMarkdown('n'); </ins> } hoverMessage.appendMarkdown('n'); }


Question:
When creating a breakpoint in an active debug session and this breakpoint cannot be verified, the resulting icon is almost invisible: ! The problem is that the icon's stroke is too thin. In previous versions the icon had a thicker stroke: ! I suggest that we restore the previous icon.
Agree that it is a bit too light. I do not just want to take the previous icon since the color and style are different. Thus it would be great if could tackle this Also fyi
Not quite as strong as in the 'before' above, but stronger. Marking verified. !

<del> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16"><defs><style>.icon-canvas-transparent,.icon-vs-out{fill:#f6f6f6;}.icon-canvas-transparent{opacity:0;}.icon-disabled-grey{fill:#848484;}</style></defs><title>breakpoint-function-unverified</title><g id="canvas"><path class="icon-canvas-transparent" d="M16,0V16H0V0Z"/></g><g id="outline" style="display: none;"><path class="icon-vs-out" d="M13.7,13H2.3L8,2.741Z"/></g><g id="iconBg"><path class="icon-disabled-grey" d="M8,4.8,4,12h8ZM8,6.859,10.3,11H5.7Z"/></g></svg> </del>  No newline at end of file <ins> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16"><defs><style>.icon-canvas-transparent,.icon-vs-out{fill:#f6f6f6;}.icon-canvas-transparent{opacity:0;}.icon-disabled-grey{fill:#848484;}</style></defs><title>breakpoint-function-unverified</title><g id="canvas"><path class="icon-canvas-transparent" d="M16,0V16H0V0Z"/></g><g id="outline" style="display: none;"><path class="icon-vs-out" d="M13.95,13H2.05L8,2.291Z"/></g><g id="iconBg"><path class="icon-disabled-grey" d="M8,4.35,3.75,12h8.5ZM8,6.924l2.125,3.826H5.875Z"/></g></svg> </ins>  No newline at end of file


Question:
When creating a breakpoint in an active debug session and this breakpoint cannot be verified, the resulting icon is almost invisible: ! The problem is that the icon's stroke is too thin. In previous versions the icon had a thicker stroke: ! I suggest that we restore the previous icon.
Agree that it is a bit too light. I do not just want to take the previous icon since the color and style are different. Thus it would be great if could tackle this Also fyi
Not quite as strong as in the 'before' above, but stronger. Marking verified. !

<del> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16"><defs><style>.icon-canvas-transparent,.icon-vs-out{fill:#f6f6f6;}.icon-canvas-transparent{opacity:0;}.icon-disabled-grey{fill:#848484;}</style></defs><title>breakpoint-log-unverified</title><g id="canvas"><path class="icon-canvas-transparent" d="M16,0V16H0V0Z"/></g><g id="outline" style="display: none;"><path class="icon-vs-out" d="M13.414,8,8,13.414,2.586,8,8,2.586Z"/></g><g id="iconBg"><path class="icon-disabled-grey" d="M8,4,4,8l4,4,4-4ZM5.414,8,8,5.414,10.586,8,8,10.586Z"/></g></svg> </del>  No newline at end of file <ins> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16"><defs><style>.icon-canvas-transparent,.icon-vs-out{fill:#f6f6f6;}.icon-canvas-transparent{opacity:0;}.icon-disabled-grey{fill:#848484;}</style></defs><title>breakpoint-log-unverified</title><g id="canvas"><path class="icon-canvas-transparent" d="M16,0V16H0V0Z"/></g><g id="outline" style="display: none;"><path class="icon-vs-out" d="M13.664,8,8,13.664,2.336,8,8,2.336Z"/></g><g id="iconBg"><path class="icon-disabled-grey" d="M8,3.75,3.75,8,8,12.25,12.25,8ZM5.518,8,8,5.518,10.482,8,8,10.482Z"/></g></svg> </ins>  No newline at end of file