jiebi/CodeConvo huggingface dataset:
Code change:
As mentioned in , the goal is to improve the first impression of semantic highlighting as well allow themes to opt-in to semantic highlighting. give themes a way to opt-in to semantic highlighting enable semantic coloring by default only the built-in themes. All other themes can be enabled by the theme author or in the user settings. show a notification when semantic coloring shows up the first time. The notification will point to the docs with background and information on how to configure the feature. fix the bugs found related to wrong token classification and color lookup. no longer show semantic color in imports
I like this feature. I think an individual config is better than a global one because it will allow us to use non-maintained themes that have semantic highlighting disabled and themes that have it enabled, without having to set the global config every time we change from a theme that uses it to one that doesn't
It's a good default setting
What are the reasons? It would be nice to know what most theme creators think, not just a few. Maybe some of us would like to use it A configuration could be to enable or disable that feature:
Changes pushed.
To verify: create TypeScript file . If semantic color is enabled, , and all get the function color Open a built-in in theme, semantic color should be enabled verify that the very first time the semantic colors are show, a notification dialog is shown Install a theme from the marketplace (e.g. ), semantic color should be disabled. try and semantic highlighting should be enabled verify
~Now that semantic highlighting is opt-in on a per theme basis, is there any way for a user to override that? I use Monokai Pro, which hasn't been updated in quite some time, and the developer seems fairly inactive now. The semantic highlighting was working great on 1.43, and I'd like to get it back now that it's been disabled in 1.43.1.~ ~I tried adding~ ~to my user config, but that didn't work.~ Edit: The above actually did work, except that semantic highlighting doesn't work on imports. I see now that this is the intended behavior. But why is semantic highlighting no longer available for import statements?
Make sure to also remove
Sorry, I was able to get semantic highlighting working by setting the config in my previous reply. But I'm wondering if it's possible to re-enable semantic highlighting on imports. On 1.43, variable names in import statements in Javascript would be highlighted based on their type. But on 1.43.1 with semantic highlighting enabled, import lines are no longer highlighted, as noted in your original message.

Related discussion:
text: this._tokens.flush(); this._emitModelTokensChangedEvent({ tokenizationSupportChanged: true, <ins> semanticTokensApplied: false, </ins> ranges: [{ fromLineNumber: 1, toLineNumber: this._buffer.getLineCount()
Code change:
As mentioned in , the goal is to improve the first impression of semantic highlighting as well allow themes to opt-in to semantic highlighting. give themes a way to opt-in to semantic highlighting enable semantic coloring by default only the built-in themes. All other themes can be enabled by the theme author or in the user settings. show a notification when semantic coloring shows up the first time. The notification will point to the docs with background and information on how to configure the feature. fix the bugs found related to wrong token classification and color lookup. no longer show semantic color in imports
I like this feature. I think an individual config is better than a global one because it will allow us to use non-maintained themes that have semantic highlighting disabled and themes that have it enabled, without having to set the global config every time we change from a theme that uses it to one that doesn't
It's a good default setting
What are the reasons? It would be nice to know what most theme creators think, not just a few. Maybe some of us would like to use it A configuration could be to enable or disable that feature:
Changes pushed.
To verify: create TypeScript file . If semantic color is enabled, , and all get the function color Open a built-in in theme, semantic color should be enabled verify that the very first time the semantic colors are show, a notification dialog is shown Install a theme from the marketplace (e.g. ), semantic color should be disabled. try and semantic highlighting should be enabled verify
~Now that semantic highlighting is opt-in on a per theme basis, is there any way for a user to override that? I use Monokai Pro, which hasn't been updated in quite some time, and the developer seems fairly inactive now. The semantic highlighting was working great on 1.43, and I'd like to get it back now that it's been disabled in 1.43.1.~ ~I tried adding~ ~to my user config, but that didn't work.~ Edit: The above actually did work, except that semantic highlighting doesn't work on imports. I see now that this is the intended behavior. But why is semantic highlighting no longer available for import statements?
Make sure to also remove
Sorry, I was able to get semantic highlighting working by setting the config in my previous reply. But I'm wondering if it's possible to re-enable semantic highlighting on imports. On 1.43, variable names in import statements in Javascript would be highlighted based on their type. But on 1.43.1 with semantic highlighting enabled, import lines are no longer highlighted, as noted in your original message.

Related discussion:
text: this._emitModelTokensChangedEvent({ tokenizationSupportChanged: false, <ins> semanticTokensApplied: false, </ins> ranges: [{ fromLineNumber: 1, toLineNumber: this.getLineCount() }] }); }
Code change:
As mentioned in , the goal is to improve the first impression of semantic highlighting as well allow themes to opt-in to semantic highlighting. give themes a way to opt-in to semantic highlighting enable semantic coloring by default only the built-in themes. All other themes can be enabled by the theme author or in the user settings. show a notification when semantic coloring shows up the first time. The notification will point to the docs with background and information on how to configure the feature. fix the bugs found related to wrong token classification and color lookup. no longer show semantic color in imports
I like this feature. I think an individual config is better than a global one because it will allow us to use non-maintained themes that have semantic highlighting disabled and themes that have it enabled, without having to set the global config every time we change from a theme that uses it to one that doesn't
It's a good default setting
What are the reasons? It would be nice to know what most theme creators think, not just a few. Maybe some of us would like to use it A configuration could be to enable or disable that feature:
Changes pushed.
To verify: create TypeScript file . If semantic color is enabled, , and all get the function color Open a built-in in theme, semantic color should be enabled verify that the very first time the semantic colors are show, a notification dialog is shown Install a theme from the marketplace (e.g. ), semantic color should be disabled. try and semantic highlighting should be enabled verify
~Now that semantic highlighting is opt-in on a per theme basis, is there any way for a user to override that? I use Monokai Pro, which hasn't been updated in quite some time, and the developer seems fairly inactive now. The semantic highlighting was working great on 1.43, and I'd like to get it back now that it's been disabled in 1.43.1.~ ~I tried adding~ ~to my user config, but that didn't work.~ Edit: The above actually did work, except that semantic highlighting doesn't work on imports. I see now that this is the intended behavior. But why is semantic highlighting no longer available for import statements?
Make sure to also remove
Sorry, I was able to get semantic highlighting working by setting the config in my previous reply. But I'm wondering if it's possible to re-enable semantic highlighting on imports. On 1.43, variable names in import statements in Javascript would be highlighted based on their type. But on 1.43.1 with semantic highlighting enabled, import lines are no longer highlighted, as noted in your original message.

Related discussion:
text: */ export interface IModelTokensChangedEvent { readonly tokenizationSupportChanged: boolean; <ins> readonly semanticTokensApplied: boolean; </ins> readonly ranges: { /** * The start of the range (inclusive)
Code change:
As mentioned in , the goal is to improve the first impression of semantic highlighting as well allow themes to opt-in to semantic highlighting. give themes a way to opt-in to semantic highlighting enable semantic coloring by default only the built-in themes. All other themes can be enabled by the theme author or in the user settings. show a notification when semantic coloring shows up the first time. The notification will point to the docs with background and information on how to configure the feature. fix the bugs found related to wrong token classification and color lookup. no longer show semantic color in imports
I like this feature. I think an individual config is better than a global one because it will allow us to use non-maintained themes that have semantic highlighting disabled and themes that have it enabled, without having to set the global config every time we change from a theme that uses it to one that doesn't
It's a good default setting
What are the reasons? It would be nice to know what most theme creators think, not just a few. Maybe some of us would like to use it A configuration could be to enable or disable that feature:
Changes pushed.
To verify: create TypeScript file . If semantic color is enabled, , and all get the function color Open a built-in in theme, semantic color should be enabled verify that the very first time the semantic colors are show, a notification dialog is shown Install a theme from the marketplace (e.g. ), semantic color should be disabled. try and semantic highlighting should be enabled verify
~Now that semantic highlighting is opt-in on a per theme basis, is there any way for a user to override that? I use Monokai Pro, which hasn't been updated in quite some time, and the developer seems fairly inactive now. The semantic highlighting was working great on 1.43, and I'd like to get it back now that it's been disabled in 1.43.1.~ ~I tried adding~ ~to my user config, but that didn't work.~ Edit: The above actually did work, except that semantic highlighting doesn't work on imports. I see now that this is the intended behavior. But why is semantic highlighting no longer available for import statements?
Make sure to also remove
Sorry, I was able to get semantic highlighting working by setting the config in my previous reply. But I'm wondering if it's possible to re-enable semantic highlighting on imports. On 1.43, variable names in import statements in Javascript would be highlighted based on their type. But on 1.43.1 with semantic highlighting enabled, import lines are no longer highlighted, as noted in your original message.

Related discussion:
text: import './largeFileOptimizations'; import './inspectEditorTokens/inspectEditorTokens'; import './saveParticipants'; <ins> import './semanticTokensHelp'; </ins> import './toggleColumnSelection'; import './toggleMinimap'; import './toggleMultiCursorModifier';
Code change:
Testing Why is not there a contribution point for timeline provider? Following are the advantages I am not sure how I have to activate my extension if I only contribute timeline provider. Having a timeline contribution point can allow me to activate my extension when user starts using the timeline my extension contributesAlso helps in displaying the feature contributions in extension editor view
and I talked about supporting this originally but felt that it was something that could be later.
Hm, not sure... Somehow timeline feels like master-detail, e.g you open an editor and the timeline shows its contents. With that usage-pattern it feels wrong to have an activation event. Then there is the 'Open timeline' command which is different... You could that command as activation event and all is good
On what event shall an extension contributing a timeline should be activated?
For instance these and
should we support an activation? Rather than a really specific point just for the timeline?
Yeah, that would make sense
To verify ensure that your extension that contributes a timeline can activate properly when the timeline is revealed via the activation

Related discussion:
text: import { IHoverService } from 'vs/workbench/services/hover/browser/hover'; import { IHoverDelegate, IHoverDelegateOptions } from 'vs/base/browser/ui/iconLabel/iconHoverDelegate'; import { IUriIdentityService } from 'vs/platform/uriIdentity/common/uriIdentity'; <ins> import { IExtensionService } from 'vs/workbench/services/extensions/common/extensions'; </ins> const ItemHeight = 22;
Code change:
Testing Why is not there a contribution point for timeline provider? Following are the advantages I am not sure how I have to activate my extension if I only contribute timeline provider. Having a timeline contribution point can allow me to activate my extension when user starts using the timeline my extension contributesAlso helps in displaying the feature contributions in extension editor view
and I talked about supporting this originally but felt that it was something that could be later.
Hm, not sure... Somehow timeline feels like master-detail, e.g you open an editor and the timeline shows its contents. With that usage-pattern it feels wrong to have an activation event. Then there is the 'Open timeline' command which is different... You could that command as activation event and all is good
On what event shall an extension contributing a timeline should be activated?
For instance these and
should we support an activation? Rather than a really specific point just for the timeline?
Yeah, that would make sense
To verify ensure that your extension that contributes a timeline can activate properly when the timeline is revealed via the activation

Related discussion:
text: @IThemeService themeService: IThemeService, @ITelemetryService telemetryService: ITelemetryService, @ILabelService private readonly labelService: ILabelService, <del> @IUriIdentityService private readonly uriIdentityService: IUriIdentityService </del> <ins> @IUriIdentityService private readonly uriIdentityService: IUriIdentityService, @IExtensionService private readonly extensionService: IExtensionService, </ins> ) { super({ ...options, titleMenuId: MenuId.TimelineTitle }, keybindingService, contextMenuService, configurationService, contextKeyService, viewDescriptorService, instantiationService, openerService, themeService, telemetryService);
Code change:
Testing Why is not there a contribution point for timeline provider? Following are the advantages I am not sure how I have to activate my extension if I only contribute timeline provider. Having a timeline contribution point can allow me to activate my extension when user starts using the timeline my extension contributesAlso helps in displaying the feature contributions in extension editor view
and I talked about supporting this originally but felt that it was something that could be later.
Hm, not sure... Somehow timeline feels like master-detail, e.g you open an editor and the timeline shows its contents. With that usage-pattern it feels wrong to have an activation event. Then there is the 'Open timeline' command which is different... You could that command as activation event and all is good
On what event shall an extension contributing a timeline should be activated?
For instance these and
should we support an activation? Rather than a really specific point just for the timeline?
Yeah, that would make sense
To verify ensure that your extension that contributes a timeline can activate properly when the timeline is revealed via the activation

Related discussion:
text: override setVisible(visible: boolean): void { if (visible) { <ins> this.extensionService.activateByEvent('onView:timeline'); </ins> this.visibilityDisposables = new DisposableStore(); this.editorService.onDidActiveEditorChange(this.onActiveEditorChanged, this, this.visibilityDisposables);
Code change:
Issue Type: <bBug</bI moved all views in panel to sidebar and VSCode crashed the first time I pressed ctrl + j to show panel. I can consistently repro this issue. VS Code version: Code - Insiders 1.44.0-insider (, 2020-04-03T23:31:33.481Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
To Verify: all panels to the sidebar (panel will hide) Ctrl+J that the panel opens to an empty view e.g. (empty Terminal View) and that you do not crash. We will iterate on a better UX next milestone.
I made this change as the safest option for now. If you have a better solution that warrants another fix, please take over. Otherwise, will roll with this.
Yah looks the safest fix for now. Seems panel is not ready to handle no active panels. Is there a follow up issue for this created?
but the panel does handle no active panels if you run the command instead of (<kbdCtrl</kbd+<kbdJ</kbd) !
Yeah there are some issues with it and it is not working always. Hence we did a safe fix for now. We are working on this with proper UX for next milestone.

Related discussion:
text: const viewContainer = this.getViewContainer(panelDescriptor.id); if (viewContainer?.hideIfEmpty) { const viewDescriptors = this.viewDescriptorService.getViewDescriptors(viewContainer); <del> if (viewDescriptors.activeViewDescriptors.length === 0) { </del> <ins> if (viewDescriptors.activeViewDescriptors.length === 0 && this.compositeBar.getPinnedComposites().length > 1) { </ins> this.hideComposite(panelDescriptor.id); // Update the composite bar by hiding } }
Code change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- 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.44.0 OS Version: PopOS! 19.10 Steps to Reproduce: Not necessary, it's just a typo._ <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No Yes. The description string for is , should be . I know this is a very minor cosmetic issue, but I thought I bring it up anyway.

Related discussion:
text: "config.enableSmartCommit": "Commit all changes when there are no staged changes.", "config.smartCommitChanges": "Control which changes are automatically staged by Smart Commit.", "config.smartCommitChanges.all": "Automatically stage all changes.", <del> "config.smartCommitChanges.tracked": "Automatically staged tracked changes only.", </del> <ins> "config.smartCommitChanges.tracked": "Automatically stage tracked changes only.", </ins> "config.suggestSmartCommit": "Suggests to enable smart commit (commit all changes when there are no staged changes).", "config.enableCommitSigning": "Enables commit signing with GPG.", "config.discardAllScope": "Controls what changes are discarded by the `Discard all changes` command. `all` discards all changes. `tracked` discards only tracked files. `prompt` shows a prompt dialog every time the action is run.",
Code change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- 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.44.1 OS Version: Linux 5.6.4-arch1-1 SMP PREEMPT x86_64 GNU/Linux Steps to Reproduce: a symbolic link to the VSCode starting script with a space in the name. For example: "My VSCode" from the terminal Error is printed to the terminal: All in the starting script () should be enclosed in double quotes to avoid this error. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
I can take this!
great!

Related discussion:
text: fi fi <del> if [ ! -L $0 ]; then </del> <ins> if [ ! -L "$0" ]; then </ins> # if path is not a symlink, find relatively <del> VSCODE_PATH="$(dirname $0)/.." </del> <ins> VSCODE_PATH="$(dirname "$0")/.." </ins> else if command -v readlink >/dev/null; then # if readlink exists, follow the symlink and find relatively <del> VSCODE_PATH="$(dirname $(readlink -f $0))/.." </del> <ins> VSCODE_PATH="$(dirname $(readlink -f "$0"))/.." </ins> else # else use the standard install location VSCODE_PATH="/usr/share/@@NAME@@"
Code change:
ERR LinkedMap got modified during iteration.: Error: LinkedMap got modified during iteration. at LinkedMap.forEach (file:///Applications/Visual Studio Code - ) at g.cleanUp (file:///Applications/Visual Studio Code - ) at g.saveState (file:///Applications/Visual Studio Code - ) at file:///Applications/Visual Studio Code - Code is here:

Related discussion:
text: private cleanUp(): void { const cache = this.doLoad(); <del> // Remove groups from states that no longer exist cache.forEach((mapGroupToMemento, resource) => { </del> <ins> // Remove groups from states that no longer exist. Since we modify the // cache and its is a LRU cache make a copy to ensure iteration succeeds const entries = [...cache.entries()]; for (const [resource, mapGroupToMemento] of entries) { </ins> Object.keys(mapGroupToMemento).forEach(group => { const groupId: GroupIdentifier = Number(group); if (!this.editorGroupService.getGroup(groupId)) { delete mapGroupToMemento[groupId]; if (isEmptyObject(mapGroupToMemento)) { cache.delete(resource); } } }); <del> }); </del> <ins> } </ins> } }
Code change:
see gif open GH notebook with a few cell that reference a variable run peek references and select entries notice how notebook cells are being highlighted, like "Milestone Work" get selected !
I can repro in Insiders but not master, I'll check again tomorrow
This happens because of this listener: Tho, not yet sure why the selection keeps changing... Maybe some inner list event (from the references list) bubbles up to the outer list
That listener is fine, it's the nested lists
Hey do you have any thoughts on handling this? We have a list inside another list. The inner list handles the touch event properly. The outer list then handles the event and picks up the wrong index because it finds the data attribute inside the inner list in We can Make sure the event is fired on the outer list with the correct element, by fixing to check whether it's in the right list Not fire the event on the outer list at all, when we see that it originates in a different list Add some property to the list event that says it originated in a different list so the consumer can decide In this particular case, I think any of these are fine
Thinking more, I don't think that the event should ever be handled by two lists at all. Meaning we either mark the browserEvent as handled, like with preventDefault/isDefaultPrevented, or we make the list check every event to be sure that it originated in this list.
This sounds good to me. This also sounds good to me.
related when I do peek references, I see markdown cells being selected? ! Notice I'm looking for under-discussion but "Configure" is being highlighted as one of the references
From Good catch, I didn't notice that
Thanks for the quick handling!

Related discussion:
text: return; } <ins> if (e.browserEvent.defaultPrevented) { return; } </ins> const focus = e.index; if (typeof focus === 'undefined') {