Code change:
clear(): void; } <ins> export interface GlobalEnvironmentVariableCollection extends EnvironmentVariableCollection { /** * Gets scope-specific environment variable collection for the extension. This enables alterations to * terminal environment variables solely within the designated scope, and is applied in addition to (and * after) the global collection. * * Each object obtained through this method is isolated and does not impact objects for other scopes, * including the global collection. * * @param scope The scope to which the environment variable collection applies to. * * If a scope parameter is omitted, collection applicable to all relevant scopes for that parameter is * returned. For instance, if the 'workspaceFolder' parameter is not specified, the collection that applies * across all workspace folders will be returned. */ getScoped(scope: EnvironmentVariableScope): EnvironmentVariableCollection; } export type EnvironmentVariableScope = { /** * Any specific workspace folder to get collection for. */ workspaceFolder?: WorkspaceFolder; }; </ins> /** * A location in the editor at which progress information can be shown. It depends on the * location how progress is visually represented.

Related discussion:
text: For example: Context:
As we anticipate we might need shell scoping as well in the future, use something similar to instead. Updated proposal: One issue with this is that carries optional properties. Hence an alternative could be:
The required would need to be removed when we a second one anyway, we can just treat and the same as
Sorry what do you mean by the "second one"? Mostly I was trying to follow : But I guess we don't have to strictly follow it?
by a second one I mean a second scope, we don't want the user to explicitly enumerate all the scopes to set it which would do.
Updated proposal:
Closing in favor of as these issues were only open to finalize proposed API.
Moving this out of June as it's a feature request.
I was expecting this so it's easier to understand for an API user:
That's what I had initially had , you're the one who recommended that perhaps we should put it inside itself:
API sync also seemed to be in agreement with that, but maybe we should check again.
my mistake, I forgot some of the conversations as this has gone through a few iterations
Based on discussion in API sync, we should probably deprecate existing API and merge it with the scoped one (similar to )
Assigning myself too so it's easier for me to track
When viewing contributions, is it possible to open the preview of the markdown directly instead of the file? ! as opposed to ! I can open preview using: !
since this is an advanced feature I think the raw markdown is more flexible as the user can navigate and copy section of it better. So I don't think this is a necessary change personally
Feedback before finalization: Add an interface implements Add to the Clarify how scoped interacts with the non-scoped collection Don't deprecate
Should we also call out how it's applied in addition to (and after) the global collection? Looks good otherwise
Sure, I have modified the docstrings to append it I plan to have the implementation ready but only merge and adopt it in Python extension next week to avoid multiple iterations.