jiebi/CodeConvo huggingface dataset:
Code change:
import { ICodeEditor } from 'vs/editor/browser/editorBrowser'; import { EditorAction, EditorCommand, EditorContributionInstantiation, MultiEditorAction, registerEditorAction, registerEditorCommand, registerEditorContribution, registerMultiEditorAction, ServicesAccessor } from 'vs/editor/browser/editorExtensions'; import { EditorOption } from 'vs/editor/common/config/editorOptions'; <ins> import { overviewRulerRangeHighlight } from 'vs/editor/common/core/editorColorRegistry'; import { IRange } from 'vs/editor/common/core/range'; </ins> import { IEditorContribution } from 'vs/editor/common/editorCommon'; import { EditorContextKeys } from 'vs/editor/common/editorContextKeys'; <ins> import { OverviewRulerLane } from 'vs/editor/common/model'; </ins> import { CONTEXT_FIND_INPUT_FOCUSED, CONTEXT_FIND_WIDGET_VISIBLE, CONTEXT_REPLACE_INPUT_FOCUSED, FindModelBoundToEditorModel, FIND_IDS, ToggleCaseSensitiveKeybinding, TogglePreserveCaseKeybinding, ToggleRegexKeybinding, ToggleSearchScopeKeybinding, ToggleWholeWordKeybinding } from 'vs/editor/contrib/find/browser/findModel'; import { FindOptionsWidget } from 'vs/editor/contrib/find/browser/findOptionsWidget'; import { FindReplaceState, FindReplaceStateChangedEvent, INewFindReplaceState } from 'vs/editor/contrib/find/browser/findState';

Related discussion:
text: Testing Meaning that it would automatically highlight and reveal in the background when you type a valid number of a match.
Code change:
public deregisterTokenType(id: string): void { delete this.tokenTypeById[id]; delete this.tokenStylingSchema.properties[id]; <del> this.typeHierarchy = {}; </del> <ins> this.typeHierarchy = Object.create(null); </ins> } public deregisterTokenModifier(id: string): void {

Related discussion:
text: Issue Type: <bBug</bSemantic token colorization fails when a token type ID matching any object.prototype property name is provided. Some examples are: , and . is the most problematic name since it is likely to be used as a token type ID. Any string should be able to be used as a token type ID without causing the colorization to fail. Because tries to call on what was thought to be a but was actually a , which throws a TypeError and causes the colorization to fail. The easiest way is probably to use a instead of an object for . Another solution might be to instantiate using instead of an object literal in order to avoid the object.prototype. VS Code version: Code 1.47.2 (, 2020-07-15T18:22:15.161Z) OS version: Linux x64 4.19.0-9-amd64 <!-- generated by issue reporter --
Code change:
'default': 'alwaysExpand' }, [OutlineConfigKeys.problemsEnabled]: { <del> 'markdownDescription': localize('outline.showProblem', "Show errors and warnings on Outline elements. Overwritten by `#problems.visibility#` when `{0}` is off.", `problems.visibility`), </del> <ins> 'markdownDescription': localize('outline.showProblem', "Show errors and warnings on Outline elements. Overwritten by `#problems.visibility#` when it is off."), </ins> 'type': 'boolean', 'default': true }, [OutlineConfigKeys.problemsColors]: { <del> 'markdownDescription': localize('outline.problem.colors', "Use colors for errors and warnings on Outline elements. Overwritten by `#problems.visibility#` when `{0}` is off.", `problems.visibility`), </del> <ins> 'markdownDescription': localize('outline.problem.colors', "Use colors for errors and warnings on Outline elements. Overwritten by `#problems.visibility#` when it is off."), </ins> 'type': 'boolean', 'default': true }, [OutlineConfigKeys.problemsBadges]: { <del> 'markdownDescription': localize('outline.problems.badges', "Use badges for errors and warnings on Outline elements. Overwritten by `#problems.visibility#` when `{0}` is off.", `problems.visibility`), </del> <ins> 'markdownDescription': localize('outline.problems.badges', "Use badges for errors and warnings on Outline elements. Overwritten by `#problems.visibility#` when it is off."), </ins> 'type': 'boolean', 'default': true },

Related discussion:
text: Testing Why is the setting name linked once and once it just shows the ID? Both should be linked, or maybe you can rephrase it to just use the setting name once like <img width="548" alt="image" src=""
That's a good point yeah
Code change:
); })(); <ins> lineAlignments = optimizeSequenceDiffs(sequence1, sequence2, lineAlignments); </ins> const alignments: RangeMapping[] = []; const scanForWhitespaceChanges = (equalLinesCount: number) => {

Related discussion:
text: Diffing the files: original: modified: <img width="1127" alt="image" src="https://user-"It would be better to line up things differently and give preference to having lines with smaller indent be boundary lines. fyi
Very nice idea!! Very valuable example. I can implement this in the experimental diffing algorithm, and soon we can discuss to deprecate the smart diffing algorithm ().
Implemented in the experimental diff algorithm (not smart). Let's try to deprecate the smart diff algorithm in favor of the experimental in the next milestones.
Closing, as this is implemented in the experimental diff algorithm, which is now the default. To verify, try it out in the playground:
Code change:
import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; import { ILogService } from 'vs/platform/log/common/log'; import { promiseWithResolvers } from 'vs/base/common/async'; <ins> import { shouldUseEnvironmentVariableCollection } from 'vs/platform/terminal/common/terminalEnvironment'; </ins> class CustomVariableResolver extends AbstractVariableResolverService { constructor(

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Version: 1.85.0-insider OS: Linux (codespaces) Steps to Reproduce: in the terminal prompt is contributed via env collection by Python extension. Normal terminal: ! Hovering says that collection is applied. Hidden terminal: ! Although it says that no environment collection is contributed upon hovering, collection is still applied as can be seen in the terminal prompt.
it seems like this is actually a bug where the initially hidden terminal doesn't show the applied environments but should? Making a terminal hidden was just meant to be about visibility, not environment?
I'm fine if we change hidden terminals to also apply environment collection, as long as we get support for Python extension decided not to send activate commands to hidden terminals: , as hidden terminals are considered private terminals belonging to a specific extension. One could probably argue similarly for not applying environment collection to such terminals.
Based on offline discussion we're continue to go with NOT applying environment collection to hidden terminals, due to it affecting remote scenarios.
We investigated that env collection from shell integration in unix is still being applied on hidden terminals, i.e is still being applied when it should not. Any further updates?
Code to disable for terminals: Where vars are set:
I cannot reproduce this on Windows or macOS. Steps: Code - OSS a terminal and verify the environment does not include terminal-sample from vscode-extension-samples via symlink a terminal and verify the environment does and select the new terminal and verify the environment does not include Maybe you had the variable set in the parent environment (main/server?) which is why it showed up?
Code change:
import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; import { ILogService } from 'vs/platform/log/common/log'; import { promiseWithResolvers } from 'vs/base/common/async'; <ins> import { shouldUseEnvironmentVariableCollection } from 'vs/platform/terminal/common/terminalEnvironment'; </ins> class CustomVariableResolver extends AbstractVariableResolverService { constructor(

Related discussion:
text: Please try it on Linux (codespaces), stated in the original report, this issue doesn't exist on Windows. And I don't have a macOS to verify.
Thanks, missed the remote bit
Seems like this behavior has now changed with: So we should either reopen this one or , to accomplish
you can accomplish by using
I see, suppose if is , but no is passed explicitly, I assume system environment variables and shell initialization scripts are still applied? What does window's environment mean here and will it be applied if is , but no is passed.
We don't have any environment to provide, all we want to do is skip applying env collection while the rest of the environment stays as-is, can you guide us on how to exactly use to achieve that? Also, we would expect shell integration to be active.
basing the environment on should do the trick
Gotcha, will try that. I assume shell initialization and integration scripts are still run?
looking at the code, I think shell integration does activate even when strictEnv is set
What are some verification steps for this issue? For example, how do I get Python deactivate to show up?
steps at , remote only
Actually we reverted the change made in this issue with , so even hidden terminals have environment collection applied by default now.
:+1: So the steps are: a terminal and verify the environment does not include terminal-sample from vscode-extension-samples via symlink a terminal and verify the environment does and select the new terminal and verify the environment does include
How do I do step 3? Am I opening the terminal-sample workspace after cloning and creating a symlink to it?
you can build the extension and do it in the insiders extension development host
Code change:
const extension = await this.toScannedExtension(webExtension, false); if (extension.isValid || !scanOptions?.skipInvalidExtensions) { result.set(extension.identifier.id.toLowerCase(), extension); <ins> } else { this.logService.info(`Skipping invalid installed extension ${webExtension.identifier.id}`); </ins> } } return [...result.values()];

Related discussion:
text: All of a sudden, I no longer have GHPRI installed. When I go into I see Settings Sync removed it 11 hours ago, but I'm 100% sure I never uninstalled it. I know I have Settings Sync enabled in both and are those scenarios doing unexpected things to my settings sync? !
I am sure that 4 days ago I re- the extension. Today, I'm on another machine, and GHPRI is again gone.
Lets sync on this
Closing as I couldn't repro.
I was able to reproduce this issue. will sometimes remove and then readd the GitHub Repositories, Issues & PR, and remotehub extensions, except it doesn't readd the keypair to the config, so when I return to my local installation the extensions will sometimes disappear. Not sure why it doesn't always reinstall though. Sometimes won't readd the missing extensions in time, so it gets removed. When the extensions are without the keypair, the local machine can occasionally readd the missing config and keep the extension installed; other times it won't and the extension is removed. Local machine logs from yesterday: Extension config history: Remote removes extensions: Remote readds extensions, but not marked as installed: After I reinstall the extensions locally: logs from a repro today: Extension sync history: Removed extensions: Readd extensions:
Thanks for logs and info. Reopening for investigation.
I am able to reproduce this with following steps: 1: Install GHPRI pre-release extension and sync .dev: Trigger Sync. Note that this is a builtin extension here. 2: Trigger Sync - Make sure GHPR extension is installed. 1: Uninstall GHPRI extension 2: Trigger Sync - Make sure GHPR extension is uninstalled. .dev: Trigger Sync. Make sure GHPRI extension exists in builtin extensions. 1: Trigger Sync. Nothing changes. 2: Trigger Sync. Nothing changes. This step and above step are important because, even though nothing has changed, these machines update their last sync state to have GHPRI extension has builtin extension. 1: Install GHPRI pre-release extension and sync 2: Trigger Sync GHPRI extension is not installed. Come back to Desktop 1: GHPRI extension is removed.
Improved extensions merging to make sure the builtin extensions are handled properly.
Code change:
const extension = await this.toScannedExtension(webExtension, false); if (extension.isValid || !scanOptions?.skipInvalidExtensions) { result.set(extension.identifier.id.toLowerCase(), extension); <ins> } else { this.logService.info(`Skipping invalid installed extension ${webExtension.identifier.id}`); </ins> } } return [...result.values()];

Related discussion:
text: Each machine remembers what builtin extensions it syncs and make sure it won't remove them while syncing. Also some logs to get more information if the issue still occurs.
If I uninstall GHPRI from desktop and then Sync Now in , the extension appears to be 'uninstalled' on , is that expected? ! After reloading the extension is still installed though.
I don't have a second desktop to verify with at the moment.
Yeah in your case it is expected because, GHPRI extension seems to be user installed and settings sync is removing that.
Code change:
if (!(node instanceof ResolvableTreeItem) || !node.hasResolve) { if (resource && !node.tooltip) { return undefined; <del> } else if (!node.tooltip) { </del> <ins> } else if (node.tooltip === undefined) { </ins> return label; } else if (!isString(node.tooltip)) { return { markdown: node.tooltip, markdownNotSupportedFallback: resource ? undefined : renderMarkdownAsPlaintext(node.tooltip) }; // Passing undefined as the fallback for a resource falls back to the old native hover <del> } else { </del> <ins> } else if (node.tooltip !== '') { </ins> return node.tooltip; <ins> } else { return undefined; </ins> } }

Related discussion:
text: <!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --I work on an extension that has a custom tree view. Some of the items don't have meaningful extra information to show in a tooltip but setting the field in the to or results in the label being used for the tooltip which looks odd as it provides no additional information. We would like it if there was some way to disable tooltips for a tree item. It might be hard to used for that now as that would be a breaking change but perhaps there is some other approach that would be possible. I would note that if the tooltip is required for accessibility in some way then I'm happy that it stays but I think that angle is covered by the aria-label attribute and the tooltip is something else entirely. I have searched and I can't see reference to this from an extension API point of view in the current issues. I am not well versed in the VS Code code base but I believe the issue comes from these lines:
Here is an example screenshot of the issue: ! The supported features are programmatically detected and we don't have a reliable way of providing any additional useful information for the tooltip so being able to avoid it entirely would be desirable.
I think that allowing extensions to have no tooltip is a good feature request. Form an API perspective, do you think setting to empty string is an ok way to accomplish this? I don't think we should use since that would be a big disruption to the current behavior (where the is used).
Yeah, that makes sense to me.
To verify, modify an extension that provides a tree view so that the of it's tree items is an empty string. Verify that no hover is shown on those tree items. You can use the sample for this:
Code change:
type: 'boolean', default: false, description: nls.localize('search.usePCRE2', "Whether to use the PCRE2 regex engine in text search. This enables using some advanced regex features like lookbehind and backreferences. However, not all PCRE2 features are supported - only features that are also supported by JavaScript.") <ins> }, 'search.actionsPosition': { type: 'string', enum: ['auto', 'right'], default: 'auto', description: nls.localize('search.actionsPosition', "Controls whether to show actions at the end of match or always aligned to the right in wide panels.") </ins> } } });

Related discussion:
text: <!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.29-insider OS Version: Windows 10 Version 1809 (OS Build .1000) Steps to Reproduce: Find in files and search for something that will return results over different result lines Badge and Action button (Dismiss) are on the left (aligned to the end of result text) I'm expecting that Dismiss action will have fixed horizontal position (on the right side) that will allow me to easily dismiss several results entries. With current position at the end of result text I have to constantly move mouse to hit Dismiss button. In stable version both count badge (for file) and Dismiss action were aligned at the right side of the viewlet which was convenient. At this moment it is hard to filter out result entries because texts have different length and button shifts for each line. I've found which says that button should always stay on the right side, however this isn't case in v1.28.2 independently from viewlet width (both badge and actions are on the right side). <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <details<summaryScreenshot</summary<div! </div</details
I guess this only applies to the search panel?
Yes, I observe issue in Search panel. UPD. Checked - same behavior when Search: Location is set to sidebar.
You should see the actions on the right when search is narrow, and on the left when it's somewhat wide. The reason is that when the actions are on the right and the text is aligned to the left, it can be hard to associate the two, so it seems more user-friendly to put the actions closer to the actual result. Maybe the threshold could be tweaked, but it doesn't feel good to click an action on the opposite side of the monitor from the actual text. Does this match what you see?
Yes, that match what I see, but makes it harder to use Dismiss action with mouse. For badge with results count - it is good position, since it is visible without hover. On the other hands actions are only visible on hover, when background can clearly indicate what line will be dismissed.
Code change:
type: 'boolean', default: false, description: nls.localize('search.usePCRE2', "Whether to use the PCRE2 regex engine in text search. This enables using some advanced regex features like lookbehind and backreferences. However, not all PCRE2 features are supported - only features that are also supported by JavaScript.") <ins> }, 'search.actionsPosition': { type: 'string', enum: ['auto', 'right'], default: 'auto', description: nls.localize('search.actionsPosition', "Controls whether to show actions at the end of match or always aligned to the right in wide panels.") </ins> } } });

Related discussion:
text: Previously (September and numerous builds before) I was able to put mouse over X and just click (even without looking) several times to remove unnecessary lines. Now it takes more time/attention to do it with mouse, and if next line after dismissed has longer text - it is easy to open file instead of dismissing it. Open editors view (Close editor button), Source control (action buttons for files), Extensions (Manage button) - have static position of actions that are not changed with sidebar width. My cases are 23" monitor with 1920x1080 and Surface Pro 3. Never had problems when action were on the right side. Users with 4k 30+" will have to snipe for X too.
Yes it was broken for a few months, but this was the behavior from before it was broken I see your point but I will leave this open to think about it
thanks!
Putting the dismiss button to the right would also make it less likley that someone presses it by accident which I just did. The middle of a search result might be just above/below the end of another so that clicking just a bit above/below where you intended could lead you to remove the other search result.
Issue 1) The dismiss buttons are too close to the actual text of the search result making it very easy to accidentally dismiss something. Issue 2) The dismiss buttons are invisible until hover/focus. So if you had your focus on another panel or another window and then click on a search result to focus it, it's too easy to click on an invisible button and accidentally dismiss a search result because of issue 1.
Trying to decide whether we should just always right align... but it seems weird to me to have the X really far away from the row content in some cases. Anyway, if someone wants to add a setting to configure this, I would take that PR.
Code change:
*--------------------------------------------------------------------------------------------*/ import 'vs/css!./media/welcomeDialog'; <del> import { IInstantiationService, createDecorator } from 'vs/platform/instantiation/common/instantiation'; import { ThemeIcon } from 'vs/base/common/themables'; </del> <ins> import { createDecorator } from 'vs/platform/instantiation/common/instantiation'; </ins> import { InstantiationType, registerSingleton } from 'vs/platform/instantiation/common/extensions'; <del> import { ILayoutService } from 'vs/platform/layout/browser/layoutService'; import { DisposableStore } from 'vs/base/common/lifecycle'; import { Dialog } from 'vs/base/browser/ui/dialog/dialog'; import { defaultButtonStyles, defaultCheckboxStyles, defaultDialogStyles, defaultInputBoxStyles } from 'vs/platform/theme/browser/defaultStyles'; import { $ } from 'vs/base/browser/dom'; import { renderLabelWithIcons } from 'vs/base/browser/ui/iconLabel/iconLabels'; import { ILinkDescriptor, Link } from 'vs/platform/opener/browser/link'; </del> <ins> import { ILinkDescriptor } from 'vs/platform/opener/browser/link'; import { IDialogService } from 'vs/platform/dialogs/common/dialogs'; import { MarkdownString } from 'vs/base/common/htmlContent'; </ins> interface IWelcomeDialogItem { readonly title: string;

Related discussion:
text: Related: ! A better user experience for blocking/deferring subsequent modal dialogs needs to be implemented.
Code change:
configurationRegistry.registerConfiguration(keyboardConfiguration); <del> registerSingleton(IKeybindingService, WorkbenchKeybindingService); </del>  No newline at end of file <ins> registerSingleton(IKeybindingService, WorkbenchKeybindingService); </ins>

Related discussion:
text: contribute command that uses enablement assign a keybinding, via :bug: enablement isn't honoured
When users configure keybindings we allow them to change preconditions as well, e.g rename requires an editable document so I don't plan to have a different strategy for contributed commands
I don't see the nice "Command 'Hello World' is not enabled in the current context." info toast when I try the keybinding though. I only see that message when I try to run it from the command palette. The command correctly doesn't run when not enabled though.
Yeah, that's the design. Keybindings don't show messages