jiebi/CodeConvo huggingface dataset:
Code change:
If this key is set, all telemetry information generated in a debug session of the corresponding debug type will be tagged with that key (so that the data is routed to the correct bucket). what would be a good name for that key? (it should match the name used in other places where this key is used).
this is probably something you want to use...
The functionality for reporting telemetry only supports application insights pipeline, so I suggest calling it something explicit as .
we are not using acronyms in our protocol at all, so not a big fan of , I would rather go with . I would put it as a top level attribute under in the . If this is not provided I would ignore the telemetry event so we never mix the adapter telemtery with our vscode telemetry. What do you think?
yes, put aiKey at the top of . What's about our own debug adapters? Do we get our own keys for them so that their telemetry events go to vscode telemetry?
What we do we with the current adapters telemetry? do we depend on any of them in our current active reporting? If not, let's put them in the standard first party extensions pipeline. Otherwise, we can use the same vscode key, if so I would want make sure that adds standard properties such as machineId and sessionId so the processing scripts can function normally.
For Microsoft owned debug adapters, wouldn't we want their telemetry in the same stream as VS Code so that one could look at all activity for the same session? Or are there other good ways to tie that together?
previously we were reporting telemetry events of all debug adapters to vscode. With the new mechanism we don't do this any more, so we have to make sure that the node-debug adapter (which is shipping with vscode) still gets reported in the same way as before. So I will set the aiKey.

Related discussion:
text: enableBreakpointsFor?: { languageIds: string[] }; configurationAttributes?: any; initialConfigurations?: any[]; <ins> aiKey?: string; </ins> win?: IRawEnvAdapter; winx86?: IRawEnvAdapter; windows?: IRawEnvAdapter;
Code change:
If this key is set, all telemetry information generated in a debug session of the corresponding debug type will be tagged with that key (so that the data is routed to the correct bucket). what would be a good name for that key? (it should match the name used in other places where this key is used).
this is probably something you want to use...
The functionality for reporting telemetry only supports application insights pipeline, so I suggest calling it something explicit as .
we are not using acronyms in our protocol at all, so not a big fan of , I would rather go with . I would put it as a top level attribute under in the . If this is not provided I would ignore the telemetry event so we never mix the adapter telemtery with our vscode telemetry. What do you think?
yes, put aiKey at the top of . What's about our own debug adapters? Do we get our own keys for them so that their telemetry events go to vscode telemetry?
What we do we with the current adapters telemetry? do we depend on any of them in our current active reporting? If not, let's put them in the standard first party extensions pipeline. Otherwise, we can use the same vscode key, if so I would want make sure that adds standard properties such as machineId and sessionId so the processing scripts can function normally.
For Microsoft owned debug adapters, wouldn't we want their telemetry in the same stream as VS Code so that one could look at all activity for the same session? Or are there other good ways to tie that together?
previously we were reporting telemetry events of all debug adapters to vscode. With the new mechanism we don't do this any more, so we have to make sure that the node-debug adapter (which is shipping with vscode) still gets reported in the same way as before. So I will set the aiKey.

Related discussion:
text: import { TPromise } from 'vs/base/common/winjs.base'; import editor = require('vs/editor/common/editorCommon'); import aria = require('vs/base/browser/ui/aria/aria'); <ins> import { AIAdapter } from 'vs/base/node/aiAdapter'; </ins> import editorbrowser = require('vs/editor/browser/editorBrowser'); import { IKeybindingService, IKeybindingContextKey } from 'vs/platform/keybinding/common/keybindingService'; import {IMarkerService} from 'vs/platform/markers/common/markers';
Code change:
If this key is set, all telemetry information generated in a debug session of the corresponding debug type will be tagged with that key (so that the data is routed to the correct bucket). what would be a good name for that key? (it should match the name used in other places where this key is used).
this is probably something you want to use...
The functionality for reporting telemetry only supports application insights pipeline, so I suggest calling it something explicit as .
we are not using acronyms in our protocol at all, so not a big fan of , I would rather go with . I would put it as a top level attribute under in the . If this is not provided I would ignore the telemetry event so we never mix the adapter telemtery with our vscode telemetry. What do you think?
yes, put aiKey at the top of . What's about our own debug adapters? Do we get our own keys for them so that their telemetry events go to vscode telemetry?
What we do we with the current adapters telemetry? do we depend on any of them in our current active reporting? If not, let's put them in the standard first party extensions pipeline. Otherwise, we can use the same vscode key, if so I would want make sure that adds standard properties such as machineId and sessionId so the processing scripts can function normally.
For Microsoft owned debug adapters, wouldn't we want their telemetry in the same stream as VS Code so that one could look at all activity for the same session? Or are there other good ways to tie that together?
previously we were reporting telemetry events of all debug adapters to vscode. With the new mechanism we don't do this any more, so we have to make sure that the node-debug adapter (which is shipping with vscode) still gets reported in the same way as before. So I will set the aiKey.

Related discussion:
text: private viewModel: viewmodel.ViewModel; private configurationManager: ConfigurationManager; private debugStringEditorInputs: DebugStringEditorInput[]; <ins> private telemetryAdapter: AIAdapter; </ins> private lastTaskEvent: TaskEvent; private toDispose: lifecycle.IDisposable[]; private inDebugMode: IKeybindingContextKey<boolean>;
Code change:
If this key is set, all telemetry information generated in a debug session of the corresponding debug type will be tagged with that key (so that the data is routed to the correct bucket). what would be a good name for that key? (it should match the name used in other places where this key is used).
this is probably something you want to use...
The functionality for reporting telemetry only supports application insights pipeline, so I suggest calling it something explicit as .
we are not using acronyms in our protocol at all, so not a big fan of , I would rather go with . I would put it as a top level attribute under in the . If this is not provided I would ignore the telemetry event so we never mix the adapter telemtery with our vscode telemetry. What do you think?
yes, put aiKey at the top of . What's about our own debug adapters? Do we get our own keys for them so that their telemetry events go to vscode telemetry?
What we do we with the current adapters telemetry? do we depend on any of them in our current active reporting? If not, let's put them in the standard first party extensions pipeline. Otherwise, we can use the same vscode key, if so I would want make sure that adds standard properties such as machineId and sessionId so the processing scripts can function normally.
For Microsoft owned debug adapters, wouldn't we want their telemetry in the same stream as VS Code so that one could look at all activity for the same session? Or are there other good ways to tie that together?
previously we were reporting telemetry events of all debug adapters to vscode. With the new mechanism we don't do this any more, so we have to make sure that the node-debug adapter (which is shipping with vscode) still gets reported in the same way as before. So I will set the aiKey.

Related discussion:
text: this.toDispose.push(this.session.addListener2(debug.SessionEvents.OUTPUT, (event: DebugProtocol.OutputEvent) => { if (event.body && event.body.category === 'telemetry') { <del> this.telemetryService.publicLog(event.body.output, event.body.data); </del> <ins> const key = this.configurationManager.getAdapter().aiKey; // only log telemetry events from debug adapter if the adapter provided the telemetry key if (key) { if (!this.telemetryAdapter) { this.telemetryAdapter = new AIAdapter(key, this.session.getType()); } this.telemetryAdapter.log(event.body.output, event.body.data); } </ins> } else if (event.body && typeof event.body.output === 'string' && event.body.output.length > 0) { this.onOutput(event); }
Code change:
If this key is set, all telemetry information generated in a debug session of the corresponding debug type will be tagged with that key (so that the data is routed to the correct bucket). what would be a good name for that key? (it should match the name used in other places where this key is used).
this is probably something you want to use...
The functionality for reporting telemetry only supports application insights pipeline, so I suggest calling it something explicit as .
we are not using acronyms in our protocol at all, so not a big fan of , I would rather go with . I would put it as a top level attribute under in the . If this is not provided I would ignore the telemetry event so we never mix the adapter telemtery with our vscode telemetry. What do you think?
yes, put aiKey at the top of . What's about our own debug adapters? Do we get our own keys for them so that their telemetry events go to vscode telemetry?
What we do we with the current adapters telemetry? do we depend on any of them in our current active reporting? If not, let's put them in the standard first party extensions pipeline. Otherwise, we can use the same vscode key, if so I would want make sure that adds standard properties such as machineId and sessionId so the processing scripts can function normally.
For Microsoft owned debug adapters, wouldn't we want their telemetry in the same stream as VS Code so that one could look at all activity for the same session? Or are there other good ways to tie that together?
previously we were reporting telemetry events of all debug adapters to vscode. With the new mechanism we don't do this any more, so we have to make sure that the node-debug adapter (which is shipping with vscode) still gets reported in the same way as before. So I will set the aiKey.

Related discussion:
text: }); this.model.updateBreakpoints(data); <ins> if (this.telemetryAdapter) { this.telemetryAdapter.dispose(); this.telemetryAdapter = null; } </ins> this.inDebugMode.reset(); }
Code change:
If this key is set, all telemetry information generated in a debug session of the corresponding debug type will be tagged with that key (so that the data is routed to the correct bucket). what would be a good name for that key? (it should match the name used in other places where this key is used).
this is probably something you want to use...
The functionality for reporting telemetry only supports application insights pipeline, so I suggest calling it something explicit as .
we are not using acronyms in our protocol at all, so not a big fan of , I would rather go with . I would put it as a top level attribute under in the . If this is not provided I would ignore the telemetry event so we never mix the adapter telemtery with our vscode telemetry. What do you think?
yes, put aiKey at the top of . What's about our own debug adapters? Do we get our own keys for them so that their telemetry events go to vscode telemetry?
What we do we with the current adapters telemetry? do we depend on any of them in our current active reporting? If not, let's put them in the standard first party extensions pipeline. Otherwise, we can use the same vscode key, if so I would want make sure that adds standard properties such as machineId and sessionId so the processing scripts can function normally.
For Microsoft owned debug adapters, wouldn't we want their telemetry in the same stream as VS Code so that one could look at all activity for the same session? Or are there other good ways to tie that together?
previously we were reporting telemetry events of all debug adapters to vscode. With the new mechanism we don't do this any more, so we have to make sure that the node-debug adapter (which is shipping with vscode) still gets reported in the same way as before. So I will set the aiKey.

Related discussion:
text: private configurationAttributes: any; public initialConfigurations: any[]; public enableBreakpointsFor: { languageIds: string[] }; <ins> public aiKey: string; </ins> constructor(rawAdapter: debug.IRawAdapter, systemVariables: SystemVariables, extensionFolderPath: string) { if (rawAdapter.windows) {
Code change:
If this key is set, all telemetry information generated in a debug session of the corresponding debug type will be tagged with that key (so that the data is routed to the correct bucket). what would be a good name for that key? (it should match the name used in other places where this key is used).
this is probably something you want to use...
The functionality for reporting telemetry only supports application insights pipeline, so I suggest calling it something explicit as .
we are not using acronyms in our protocol at all, so not a big fan of , I would rather go with . I would put it as a top level attribute under in the . If this is not provided I would ignore the telemetry event so we never mix the adapter telemtery with our vscode telemetry. What do you think?
yes, put aiKey at the top of . What's about our own debug adapters? Do we get our own keys for them so that their telemetry events go to vscode telemetry?
What we do we with the current adapters telemetry? do we depend on any of them in our current active reporting? If not, let's put them in the standard first party extensions pipeline. Otherwise, we can use the same vscode key, if so I would want make sure that adds standard properties such as machineId and sessionId so the processing scripts can function normally.
For Microsoft owned debug adapters, wouldn't we want their telemetry in the same stream as VS Code so that one could look at all activity for the same session? Or are there other good ways to tie that together?
previously we were reporting telemetry events of all debug adapters to vscode. With the new mechanism we don't do this any more, so we have to make sure that the node-debug adapter (which is shipping with vscode) still gets reported in the same way as before. So I will set the aiKey.

Related discussion:
text: this.initialConfigurations = rawAdapter.initialConfigurations; this._label = rawAdapter.label; this.enableBreakpointsFor = rawAdapter.enableBreakpointsFor; <ins> this.aiKey = rawAdapter.aiKey; </ins> } public get label() {
Code change:
opens the current directory, also opens the current directory - not the parent
Repros on master. Also: opens opens etc.
i see the bug and the fix is in - i guess a short term work around is opens the parent directory
yes the fix should be in the next release, adding a slash is a good work around in the meantime.
I hope something good happens here. cause the way things are going. pretty much saying microsoft has lost all control of windows

Related discussion:
text: // Trim whitespaces path = strings.trim(strings.trim(path, ' '), 't'); <del> // Remove trailing dots path = strings.rtrim(path, '.'); </del> return path; }
Code change:
when a link, src or url... contains an underscore character ( _ ) , you can't distinguish it from a misplaced space character because of the default underline below the links.
Appears to be impractical to solve using in Chromium until it fully adopts the full CSS 3 spec on . What I'll do is use a instead. Tested locally, and it looks good to me: <img width="454" alt="screen shot 2016-03-30 at 6 04 54 pm" src=""
Fixed via

Related discussion:
text: .monaco-editor .detected-link, .monaco-editor .detected-link-active { text-decoration: underline; <ins> text-underline-position: under; </ins> } .monaco-editor .detected-link-active {
Code change:
Integrated terminal master issue: Open question: Currently pressing <kbdesc</kbdwill hide the terminal, this can be a problem for some terminal programs, for example . Perhaps this should be configurable?
Thinking about desktop terminals, such as iTerm, I can only close them via a global shortcut, an button or running in the shell. <kbdEscape</kbdshould not bubble outside to the workbench.
Marked as candidate as it's a very simple change that's been reported a bunch of times.
Cherry picked to release/1.2

Related discussion:
text: return function () { var desktop = gulp.src('resources/linux/code.desktop', { base: '.' }) .pipe(replace('@@NAME_LONG@@', product.nameLong)) <ins> .pipe(replace('@@NAME_SHORT@@', product.nameShort)) </ins> .pipe(replace('@@NAME@@', product.applicationName)) .pipe(rename('usr/share/applications/' + product.applicationName + '.desktop'));
Code change:
Integrated terminal master issue: Open question: Currently pressing <kbdesc</kbdwill hide the terminal, this can be a problem for some terminal programs, for example . Perhaps this should be configurable?
Thinking about desktop terminals, such as iTerm, I can only close them via a global shortcut, an button or running in the shell. <kbdEscape</kbdshould not bubble outside to the workbench.
Marked as candidate as it's a very simple change that's been reported a bunch of times.
Cherry picked to release/1.2

Related discussion:
text: return function () { var desktop = gulp.src('resources/linux/code.desktop', { base: '.' }) .pipe(replace('@@NAME_LONG@@', product.nameLong)) <ins> .pipe(replace('@@NAME_SHORT@@', product.nameShort)) </ins> .pipe(replace('@@NAME@@', product.applicationName)) .pipe(rename('BUILD/usr/share/applications/' + product.applicationName + '.desktop'));
Code change:
Integrated terminal master issue: Open question: Currently pressing <kbdesc</kbdwill hide the terminal, this can be a problem for some terminal programs, for example . Perhaps this should be configurable?
Thinking about desktop terminals, such as iTerm, I can only close them via a global shortcut, an button or running in the shell. <kbdEscape</kbdshould not bubble outside to the workbench.
Marked as candidate as it's a very simple change that's been reported a bunch of times.
Cherry picked to release/1.2

Related discussion:
text: Name=@@NAME_LONG@@ Comment=Code Editing. Redefined. GenericName=Text Editor <del> Exec=/usr/bin/@@NAME@@ %U </del> <ins> Exec=/usr/share/@@NAME@@/@@NAME@@ %U </ins> Icon=@@NAME@@ Type=Application StartupNotify=true <del> StartupWMClass=@@NAME@@ </del> <ins> StartupWMClass=@@NAME_SHORT@@ </ins> Categories=Utility;TextEditor;Development;IDE; MimeType=text/plain; Actions=new-window;
Code change:
Integrated terminal master issue: Open question: Currently pressing <kbdesc</kbdwill hide the terminal, this can be a problem for some terminal programs, for example . Perhaps this should be configurable?
Thinking about desktop terminals, such as iTerm, I can only close them via a global shortcut, an button or running in the shell. <kbdEscape</kbdshould not bubble outside to the workbench.
Marked as candidate as it's a very simple change that's been reported a bunch of times.
Cherry picked to release/1.2

Related discussion:
text: Name[ru]=Новое окно Name[zh_CN]=新建窗口 Name[zh_TW]=開新視窗 <del> Exec=/usr/bin/@@NAME@@ --new-window %U </del> <ins> Exec=/usr/share/@@NAME@@/@@NAME@@ --new-window %U </ins> Icon=@@NAME@@
Code change:
Integrated terminal master issue: Open question: Currently pressing <kbdesc</kbdwill hide the terminal, this can be a problem for some terminal programs, for example . Perhaps this should be configurable?
Thinking about desktop terminals, such as iTerm, I can only close them via a global shortcut, an button or running in the shell. <kbdEscape</kbdshould not bubble outside to the workbench.
Marked as candidate as it's a very simple change that's been reported a bunch of times.
Cherry picked to release/1.2

Related discussion:
text: this.focusTerminal(); } })); <ins> this.toDispose.push(DOM.addDisposableListener(this.parentDomElement, 'keyup', (event: KeyboardEvent) => { // Keep terminal open on escape if (event.keyCode === 27) { event.stopPropagation(); } })); </ins> this.toDispose.push(this.themeService.onDidThemeChange((themeId) => { <del> this.setTerminalTheme(themeId); </del> <ins> this.setTerminalTheme(); })); this.toDispose.push(this.configurationService.onDidUpdateConfiguration((e) => { this.setTerminalFont(); </ins> })); this.terminal.open(this.terminalDomElement); this.parentDomElement.appendChild(terminalScrollbar.getDomNode()); <del> let config = this.configurationService.getConfiguration<ITerminalConfiguration>(); this.terminalDomElement.style.fontFamily = config.terminal.integrated.fontFamily; this.setTerminalTheme(this.themeService.getTheme()); </del> <ins> this.setTerminalFont(); this.setTerminalTheme(); </ins> resolve(void 0); }); } <del> private setTerminalTheme(themeId: string) { </del> <ins> private setTerminalTheme() { </ins> if (!this.terminal) { return; } <del> let baseThemeId = getBaseThemeId(themeId); </del> <ins> let baseThemeId = getBaseThemeId(this.themeService.getTheme()); </ins> this.terminal.colors = DEFAULT_ANSI_COLORS[baseThemeId]; this.terminal.refresh(0, this.terminal.rows); } <ins> private setTerminalFont() { let config = this.configurationService.getConfiguration<ITerminalConfiguration>(); this.terminalDomElement.style.fontFamily = config.terminal.integrated.fontFamily; } </ins> public focus(): void { this.focusTerminal(true); }
Code change:
I am using VSCode on Ubuntu 14.04 x64 VSCode About: Version 0.10.10 Commit Date 2016-03-07T10:30:20.458Z Shell 0.35.6 Renderer 45.0.2454.85 Node 4.1.1 Steps to Reproduce: a git repo folder a change the "GIT" tab typing a git message I am thinking of a counter starting with 50 (The number of character that'll be used as the short message appearing in git commits), it helps write meaning full messages, without have a word cut and completed in the description part, the behavior is taken as is from GitKraken
My suggestion would be to, instead of always showing a counter, when the first line's length has surpassed 50 characters. I'd gladly take this as a contribution PR! Wanna give it a try?
It seems easy to implement this, can I give it a try?
Absolutely, looking forward to it.
It unfortunately seems as if is no longer working on this.
Please bring it back!

Related discussion:
text: private static COMMIT_KEYBINDING = Platform.isMacintosh ? 'Cmd+Enter' : 'Ctrl+Enter'; private static NEED_MESSAGE = nls.localize('needMessage', "Please provide a commit message. You can always press **{0}** to commit changes. If there are any staged changes, only those will be committed; otherwise, all changes will.", ChangesView.COMMIT_KEYBINDING); private static NOTHING_TO_COMMIT = nls.localize('nothingToCommit', "Once there are some changes to commit, type in the commit message and either press **{0}** to commit changes. If there are any staged changes, only those will be committed; otherwise, all changes will.", ChangesView.COMMIT_KEYBINDING); <ins> private static LONG_COMMIT = nls.localize('longCommit', "Great commit summaries are 50 characters or less. Place extra information in next lines."); </ins> private instantiationService: IInstantiationService; private editorService: IWorkbenchEditorService;