text:
Proposal: Move testing args a launch config and add separate configs per run/discovery/debug

The following outlines a proposal for how to handle testing args.
Submitted issues related to this problem:

https://github.com/microsoft/vscode-python/issues/21255
https://github.com/microsoft/vscode-python/issues/11736
https://github.com/microsoft/vscode-python/issues/21176
https://github.com/microsoft/vscode-python/issues/15148
https://github.com/microsoft/vscode-python/issues/18778
https://github.com/microsoft/vscode-python/issues/17171
design of UI as someone selects args: https://github.com/microsoft/vscode-python/issues/17094
https://github.com/microsoft/vscode-python/issues/12997
https://github.com/microsoft/vscode-python/issues/11932
As part of this overhaul we will stop parsing args:

https://github.com/microsoft/vscode-python/issues/20425
https://github.com/microsoft/vscode-python/issues/21798

Current design:
Currently, to pass any command line args for test run/discovery via the extension there is a single setting per test type (one for unittest, one for pytest). The two settings are python.testing.pytestArgs: [] and python.testing.unittestArgs: [] which take a string array of command line args. The args are then processed by the extension to remove some not applicable to the current action (removing run args during discovery and discovery args during run) but this is buggy and hard to maintain. Additionally to debug a debug config can be created in the launch.json.
Issues with current design:

With only a single place to put args for each test type, a user cannot distinguish between which command line args they want to include during test run, discovery, coverage, or debug.
Since pytest does not allow some args to be included during with the arg --collect-only (used to distinguish run from discovery by the extension) these args are parsed out by the extension before sending the request. This means custom args are removed from test args and generally it creates a buggy experience that is hard to maintain with the breadth of args users would like to pass into their tests.
There is no straightforward solution to providing environment variables while running and discovering tests.

Proposed new design:
Create new custom launch configs that can be setup for test run and discovery. Also, increase compatibility with debug launch configs to make sure these work in tandem. The launch config would be set up something like this:
    {
      "name": "Python: pytest run",
      "type": "python-pytest",
      "request": "launch",
      "args": ["", ""],
      "env": {
        "PYTHONPATH": "${workspaceFolder}"
      }
    },
    {
      "name": "Python: pytest discover",
      "type": "python-pytest",
      "request": "launch",
      "args": ["", ""],
      "env": {
        "VAR": "true"
      }
    }

The two particular fields "args" and "env" would provide functionality useful to users. The rest would be default values.
The new launch config types that would be added would be:

Python: pytest run
Python: pytest discover
Python: unittest run
Python: unittest discover
The names of each one are up for discussion, please provide feedback below!

Next a way to set up these launch configs would be introduced to the extension. The initial steps would be:

add configuration -> python -> python config menu
Two possible options for how to display the testing config options would be:
A:  to have another submenu called something like "testing" which, when opened, lists the 4 config options above
B: have the 4 config options sit in the current python submenu.
(I think option A is better for clarification even though it requires one more menu clickthrough).
additionally the button "configure tests" found on the test explorer would be changed so it routed the user to a menu of the launch config options for testing (similar to option A).

Concerns with proposed design:

The use of launch configs may be harder for new / beginner users.
The discoverability of launch configs is harder.
The transition from a setting to using a config could be complicated/confusing for current users.

Possible ways to address above concerns

help beginner users
a. Increase documentation and provide specific examples of launch configs.
b. provide default values for all fields in the launch config (this is already planned so the launch config should be runnable upon creation without edits meaning no args or env vars need to be provided)
discoverability
a. There is already a larger discussion happening on how we can improve this, switching to configs for testing provides even more reason to tackle this problem
b. switching the button "configure tests" to the new config flow is very discoverable since that is already the workflow
transition
a. We can have a deprecation notification regarding the setting and show it to all those still using the setting for test args
b. It should be simple to take someone's test args in their settings and turn that into a launch config so we could offer a button that handles this for the user to switch them over (drawback is we would be setting discovery and run to the same args but the user could see this then go change it)

Notes on Debugging:
Less investigation has been done into test debugging as we already offer a similar launch config. Further analysis should be done to see what is missing in this flow and how to improve it to align with test configs once a design is decided on.
Action Items:
We are looking for feedback on this proposal so please comment below any thoughts. Thanks!

The "name" of a launch config is for the name that the user picks, it shouldn't be used to change the behavior of the launch config. Also what does "discovery" involve? We shouldn't use launch configs for anything that isn't basically running/debugging a program.

Another suggestion, I don't know how much complexity is behind the "python-pytest" debug adapter, but if the point is just to invoke the python DA with some args, another option would be to add a config snippet to help users figure out how to write their pytest launch configs. An example of this is the snippets that we have for js-debug to help users write launch configs that start an npm script.

Yes, I forgot to update the "name" of the launch config to represent that as a user input and instead focus on using "type" to change the behavior.
discovery involves running pytest discovery. It is equivalent to running "python -m pytest --collect-only" from the command line. So it is running python code if that is the concern.
I will look into the js-debug snippet! Thanks

adding https://github.com/microsoft/vscode-python/issues/18778 to the related issues as this discusses limitations with current setup.

discovery involves running pytest discovery

Yes- and what is pytest discover? 😄

and instead focus on using "type" to change the behavior.

I would say this also isn't what I expect- "type" should indicate which debug adapter is being used, and this should just be "pytest" or even "python" or something like that, and then there should be some other argument that changes the behavior.

In that issue, it sounds like it's discussing limitations with launch configs, not settings? I don't understand what Karthik means when he says

We currently only read this from the launch.json. We could expand the scope of where we read it from, but that has some things that we have not decided yet.

in https://github.com/microsoft/vscode-python/issues/18778? I tagged it since resolving this args issue would then remove the setting entirely so it would simplify this process since the launch config would be the only place to reference. I mis-attributed it to "limitations" it is more like this issue would provide clarity to the issue brought up in #18778.

Yes- and what is pytest discovery? 😄
During discovery pytest goes through and discovers all files that fit the file format for test files and finds tests within those files (both test classes and just functions). It also should read markers to determine which tests to return. So it isn't executing any of the users test code.

I would say this also isn't what I expect- "type" should indicate which debug adapter is being used, and this should just be "pytest" or even "python" or something like that, and then there should be some other argument that changes the behavior.

gotcha yeah that makes sense

During discovery pytest goes through and discovers all files that fit the file format for test files and finds tests within those files (both test classes and just functions)

This doesn't sound like a good match for a debug config then, if I'm not going to be setting breakpoints and debugging my code. It sounds more like a task perhaps? Or just something that the extension does, configured by some settings.

@brettcannon, @karthiknadig, @luabud : thoughts on @roblourens comment?

The thing is that to configure the debugger to debug pytest tests, one needs to create a launch.json file. Given that, I think it makes sense to migrate how users can configure how to run pytest tests in launch.json too.
But the whole issue is that users would like to pass different configurations for pytest discovery, which needs to be done prior run/debug. If the config for running and debugging pytest tests are in launch.json, isn't it a bit weird to have the configuration for discovery elsewhere?

The other thing to call out is .env files -- using launch.json allow users to have different pytest configs with different environment variables per run, which is harder to do with settings

I guess my question is is launch.json is just for debugging why isn't it named debug.json? 😉 I personally view launch.json as the place to configuring launching your code which is traditionally for the debugger. As well, I views tasks.json as a way to run something in the terminal that we don't have extension support for and to parse the output (which this isn't doing; it's directly tying into things).
The other thing is that while you might not use the debugger every time, you may want to use the debugger when running the tests, and so it isn't a disconnect, I think, to use launch.json this way. And since discovery and running are tied together, I think putting one somewhere else just because you typically don't debug with it seems like we're putting purity over practicality. I.e., what Luciana said. 😁
Do we know how other testing extensions handle configuration for debugging compared to running? And we can bring this up in the Pacific stand-up if necessary.

I still don't really understand what discovery is or what the user flow is for this scenario. I haven't used a testing framework that has discovery as a separate step. What is the output of discovery?
So if I want to debug my tests, I'm going to run a "discovery" launch config, wait for that to finish, then run the "run tests" launch config?

different configurations for pytest discovery, which needs to be done prior run/debug

Sounds like a prelaunch task?

How does js-debug know what tests to list in the test explorer?

There's no connection between js-debug and the test explorer. Our self-host test provider that we use for the vscode repo https://marketplace.visualstudio.com/items?itemName=ms-vscode.vscode-selfhost-test-provider creates a filewatcher for our test files, and parses them when they are added or changed. It's automatic there, I don't know about other test provider extensions. I wouldn't expect to run a launch config to populate the test explorer, that feels backwards.
I didn't realize that this is about the test explorer. So is the expected user flow like this?

Run the "discovery" launch config
Tests show up in the test explorer
Debug a test

And does 3 happen via the Test Explorer UI or the proposed Python: pytest run launch config?

parses them when they are added or changed.

pytest and unittest handle the test discovery, so we need to have those tools tell us what they find.

Run the "discovery" launch config

We run the discovery launch config; there's no manual step here beyond any custom configuration from the user.
This issue is just about configuration; the user doesn't perform any extra action for testing because of this and this is only for special cases where users need to specify extra details.

We run the discovery launch config

Launch configs are usually for users, they don't get run automatically in the background by an extension. When you do that, the debug toolbar will show up and the statusbar will turn orange and that will be spooky if it happens by itself.

another idea @luabud suggested would be something like this:
    "inputs": [
        {
            "id": "fileArguments",
            "description": "The arguments to send to the debugger",
            "type": "promptString",
            "default": "",
        }
    ],

    "configurations": [
        {
            "name": "Python: Current File",
            "type": "python",
            "console": "integratedTerminal",
            "request": "launch",
            "program": "${file}",
            "args": "${input:fileArguments}",
            "justMyCode": true
        }
    ]

Had to type this out twice after it got lost in the github.com ether yesterday, here goes. Still thinking this through but here's some thoughts-
I hadn't realized that you can already define some config in launch.json for debugging tests in the test explorer. I see that in https://code.visualstudio.com/docs/python/testing#_debug-tests you can tag a launch config with "purpose": ["debug-test"] and it gets used for debugging from the test explorer. But it gets to me a bit that the docs suggest adding a config that isn't a "real" debug config since it can't be run by the debug UI on its own, and isn't hidden from the UI. Do you pull all the properties from the launch config in this case? I get why it would be annoying to duplicate all of that if this was going to be configured somewhere else. But isn't it also true that half of those properties are not going to do anything in the test explorer? name, request, program, and console seem like basically boilerplate that you need just to fit the pattern of a launch config, and I would also find that confusing as a user. This and having to hide the launch config from the UI shows that you are using a launch config for something other than its intended purpose. It's also confusing that you can have multiple launch configs tagged with purpose but there's no way to know which one is being used, which makes launch.json seem like it's the wrong shape for this config anyway.
You are also reading and writing the launch.json file on disk directly, right? I think extensions shouldn't be doing this with launch.json, or settings.json, or other files that are managed by vscode. I think that was a disconnect in our conversation, regarding what types of configuration extensions should store in launch.json- they shouldn't store anything in launch.json. You should interact with the features via extension API. Working with the files directly could lead to complications like not handling launch configs in workspace files or launch configs from settings properly (you can actually define launch configs in settings.json via the launch setting key) and vscode could change how it stores launch configs.
Using the purpose flag for test configuration would be a nice power-user feature if I could have one config that could run as a normal launch config, but also contribute debug config to the test explorer, but this seems impossible. If I add "module": "pytest" and run it in the test explorer I get errors about it being invalid, is that right?
Overall I really think that settings.json is the right place for extension configuration. I think it's confusing to have extensions storing things in launch.json that are not actually launch configs. Eleanor found an example of how the Java test extension stores test configs in settings, and that looks like a good pattern to follow, to me. I'm fine keeping what you already have with the purpose flag, since it already exists, but I think it would work better for the primary configuration source to be in settings.

Before reading Rob's comment and the docs, I actually arrived on something similar to the existing "purpose" -- and I'm curious why that isn't sufficient for this use case.
I think such a launch config could be a "real" config that runs/debugs all tests, and not hidden from users. You could short circuit the direct usage of that configuration in your DebugConfigurationProvider to start a test run so that test results are reported to the UI in the standard way. Perhaps you would only want a subset of options to be supported in that config, or use a different debug type with different options. Ideally configuration provided in that type would be enough for discovery and execution of tests, rather than having two different launch configs.
Also, you could support multiple test-purposed launch configs by adding them as different TestRunProfiles.

If you expect this launch config to also configure test running/debugging when you do it via the test explorer UI, then the extension is still reading configuration from launch.json, and I don't really like that.

Ideally configuration provided in that type would be enough for discovery and execution of tests, rather than having two different launch configs.

I don't know whether having discovery args in that launch config makes sense, because discovery happens before running tests, and you can only have one active discovery config.

will envFile still be an option in these launch configs so that we dont need to hardcode env vars?

Very likely. I would assume we will effectively duplicate most of what's available in launch.json (hence why we are thinking of putting things there to begin with).

not sure if this belongs in this issue or a separate issue

Don't worry about it; it's fine sitting here while we discuss where to place the settings.

how would this support having overrides to envFiles?

There isn't a proposal for that right now as that hasn't been an explicit ask before (to my knowledge).

I appreciate all of y'all looking into how we can make this more configurable.
I wouldn't find it odd to have testing configs inside the settings.json.
If I had to choose between simplicity and less configuration vs some complexity and more control, I would be in favor of the more complex and flexible configuration.
Specifically I think the best exposing multiple test configurations would be a huge lift for developers where the workspace is either a mono-repo, or simply a repo that includes multiple different python components that have their own standalone libraries (ie project that has a folder for their cron jobs, and a different folder for steaming)
Currently, because their is only one configuration object available anytime I want to run tests I have to do two things for the existing configs available:

Change the value for the outsets arguments to a different "path" which is one of the top level folder names
in the bottom right choose a different python interpreter

It would be nice for theses options to be nested in a list, allowing me to have multiple options
And for part of the configuration to give the python interpreter.
Given that the interpreter selection is actually determines more than testing(such as linking and auto completion, etc) the testing configuration might not be the appropriate place to define the interpreter, and maybe that's a different setting entirely.
Right now selection of the python interpreter isn't something that's saved into settings.json, in fact I don't even know where that value gets saved and persisted and have no idea how to set the path other than via the bottom bar or the select python interpreter command.
Multiple python interpreters for different parts of the same project may have its own headache I imagine and maybe just isn't feasible, but I did want to call out how currently the selected python interpreter does interact with the test run/discovery despite not having anywhere where you can actually type the path for the executable.

trying to write down a clear list of requirements for this new design and what we want its capabilities to be. I think if we can get to a final list of what we want the user to be able to do, it then might be easier to define how the user does so and how it looks.
Requirements for MVP (minimal viable product) of new test arg config:
Requirements for the Capabilities of the JSON testing config:

users must be able to define args, envFile and env for their test configuration

envFile not required for mvp

users must be able to define if this config is test type pytest or unittest
users must be able to define if this configuration is of type run or discovery
users must be able to uniquely name their configuration which can be used to reference it in other places
users must be able to define multiple run configurations

Requirements for Debugging

users should be able to use the run and debug tab to run their tests
users should be able to reference their tests configs from their debug configs defined in launch.json
users should not have to repeat their args or environment configs in multiple places in VS Code to achieve discovery, run, and debug
users should be able to debug multiple run configurations

Other Requirements:

users should be able to select which run config they want to use for a given run

this process should be easily accessible, but this is not a requirement for the MVP

users should be able to define a default run config

Python folks, what am I missing here or want is not a requirement in your option (both for MVP or for final design in general).

Now in terms of UX and functionality, here is a potential design option. It is full of a lot of questions / different ideas on configurations. Precidence should be used to determine the best design but in grey areas I was not so sure how to use our current design (like python debug config) to fit a new need.
settings.json design
{
      "name": "run config: unique name", // user defined name, must be unique
      "args": ["-v"],
      "env": {
				"PYTHONPATH": "${workspaceFolder}",
        "DJANGO_TESTING": "true",
				"DJANGO_SETUP_SCRIPT_PATH": "/path/to/file",
      },
			"envFile": "path/to/file",

      // idea 1.1: use type & purpose
			"type": ["python-unittest", "python-pytest"],
			"purpose": ["discovery", "run"],

			// idea 1.2: use type & testKind
			"type": ["discovery", "run"],
			"testKind": ["unittest", "pytest"],

			"request": "launch", // is this needed for test configs?
},

"python.testing.pytestEnabled": false,
"python.testing.unittestEnabled": false,
// Question 1.3
// should there be one value for default config?
"python.testing.defaultConfig": ["run config: unique name"],

// or should there be one per test library
"python.testing.pytestDefaultConfig": ["run config: unique name"],
"python.testing.unittestdefaultConfig": ["run config: unique name"],

// or one setting & multiple values there and we select
// the one with the correct purpose/test kind in config
"python.testing.defaultConfig": ["run config: pytest", "run config: unittest"],

// or should default config be defined in the config like so
{
      "name": "user config option 2",
      "args": ["-v"],
			"defaultConfig": true,
      .....
},

launch.json design
{
  "name": "Python: Debug Tests",
  "type": "python",
  "request": "launch",
  "program": "${file}",
  "console": "integratedTerminal",
  "justMyCode": false

	// Question 2.1: where to select which kind of run (options debug or run)?
	// Question 2:2: should the user be able to set just a run config from here so it shows up in the menu
	// Question 2.3: where to set which config to run?
	"purpose": ["debug-test"],
	"purpose": ["run config: unique name"], // see name is from above

	// Question 2.4: Should the user be able to define variables they can also define in
	// the settings.json? Can we restrict this option?
	"env": "",
	"args": "",
	"envFile": "",
}
{
  "name": "Python: Run Pytest Tests",
  "type": "python",
  "request": "launch",
  "program": "${file}",
  "console": "integratedTerminal",
  "justMyCode": false

	// idea 2.5: use purpose & type values
	// question 2.6: should there be a purpose to just run test?
	// question 2.7: should purpose `debug-in-terminal` still exist?
	"purpose": ["debug-test"],
	"type": ["run config: unique name"]
}

Possible UI design:
( this would not be required for the MVP but could be the goal of what we want the final experience to be like)
run and debug panel allows for the same behavior with defined run & debug configurations shown in the dropdown

This is just an idea, but I think it would be a great addition if Test Explorer had a dropdown that allows the user to select which config they want to use. (this is just a quick mockup, I think the look is a bit smushed so we would have to give it more thought if we went for something like this).

Some feedback reading through:

If your configs map to TestRunProfiles, you don't need to have settings for the default configs, as these are handled/persisted by the editor. That also solves some things like "where to set which config to run?"
Can pytestEnabled/unittestEnabled be covered by the presence of the associated run config? / are there cases where I could have one but not the other?
I would try to minimize how much the user needs to cross-reference between settings.json/launch.json, especially since I don't think you can do much with intellisense as an extension there
Is it the most common case that a user will use the same configuration to both run and debug? If so, are there design decisions that can be made to simplify that path?
"Test Explorer had a dropdown that allows the user to select which config they want to use" -- we don't have a <select> menu like debug uses, but using TestRunProfiles will let the user pick their config

"python.testing.pytestEnabled": false,

Are these settings an alternative to labelling the configs as pytest/unittest or are they doing something else? I would assume you mark a config as being for pytest, then use that config, and don't need another setting like that.
Are there workspaces that use both pytest and unittest?

2.1: If it's in a launch.json, it should be debugging by default
2.2: I don't understand what you mean
2.3/2.4: I know you said

users should not have to repeat their args or environment configs in multiple places in VS Code

but I agree with Connor and if I was doing this I would probably leave out this part of referencing settings.json configs for simplicity. I wonder how complex the configurations typically are? But if this is really important, I think the pattern is fine.  "purpose" doesn't quite mean the right thing to me. I would suggest "extends", implying that it will use that settings.json config as a base, but you can override properties from the settings.json config by setting them in the launch config as well.
2.6: There is a builtin command "Run without debugging", it starts your launch config with the "noDebug" property added dynamically, I would suggest building on that.

Are these settings an alternative to labelling the configs as pytest/unittest or are they doing something else?

Something else; they already exist as settings for the extension to control which testing framework you are using and thus which one you want us to integrate with.

Some feedback reading through:

If your configs map to TestRunProfiles, you don't need to have settings for the default configs, as these are handled/persisted by the editor. That also solves some things like "where to set which config to run?"

Yes this looks perfect!

Can pytestEnabled/unittestEnabled be covered by the presence of the associated run config? / are there cases where I could have one but not the other?

I think this is possible that the configs could have an associated pytest/unittest with each and it runs the given one. So if you select "run profile A", somewhere in the config for "run profile A" you defined it runs with "pytest" so then anytime you attempt "run profile A" it selects "pytest". @brettcannon or @luabud is this too hard for users to do or to discover? I am unsure of how often people want to switch between "unittest" and "pytest" and therefore how important this consideration is.

I would try to minimize how much the user needs to cross-reference between settings.json/launch.json, especially since I don't think you can do much with intellisense as an extension there

Yeah I think this is a very good point. If a user presses the "debug" button on the test explorer with a given set of args / env vars what is the difference then them create a config in their launch.json with the same args/env vars and running it there? Wondering if we just allow the option to use launch.json to continue as it is and we focus on just expanding the test explorer.

Is it the most common case that a user will use the same configuration to both run and debug? If so, are there design decisions that can be made to simplify that path?

Yes I think so. I think it would be good since you could set a different default per run / debug if we maybe just offer every run config as an option on the debug config list. Like if the person creates a config "profile 1" they will see that in both the "run" and "debug" dropdowns? Or do we think people will find this cluttered / not enough control? I guess we could also always add an arg that is like "show for: debug, run" and the default is both but could be changed.

"Test Explorer had a dropdown that allows the user to select which config they want to use" -- we don't have a  menu like debug uses, but using TestRunProfiles will let the user pick their config

The dropdown looks great! Sorry I missed this earlier!!!
For others here is how it could look with the dropdown:

The dropdown looks great! Sorry I missed this earlier!!! (also idk why it isn't letting me "reply" like above to your comment, the formatting was getting messed up)
For others here is how it could look with the dropdown:

replies to @roblourens comments:

2.1: If it's in a launch.json, it should be debugging by default 2.2: I don't understand what you mean 2.3/2.4: I know you said

Debug by default makes sense, that solves 2.3 as well. 2.4 was just about duplicating settings so I just more wanted to repeat that question there

but I agree with Connor and if I was doing this I would probably leave out this part of referencing settings.json configs for simplicity. I wonder how complex the configurations typically are? But if this is really important, I think the pattern is fine.

I think its common to have a few environment variables and args but maybe @luabud can speak more to this question.

"purpose" doesn't quite mean the right thing to me. I would suggest "extends", implying that it will use that settings.json config as a base, but you can override properties from the settings.json config by setting them in the launch config as well.

yes this sounds fine to use "extends" if we do want them to build off each other.

2.6: There is a builtin command "Run without debugging", it starts your launch config with the "noDebug" property added dynamically, I would suggest building on that.

this is great ya, no need then for 2.6

I think this is possible that the configs could have an associated pytest/unittest with each and it runs the given one. So if you select "run profile A", somewhere in the config for "run profile A" you defined it runs with "pytest" so then anytime you attempt "run profile A" it selects "pytest". @brettcannon or @luabud is this too hard for users to do or to discover?

I would expect users to never swap between them once they have chosen their test runner.
For Rob and Connor's edification: pytest can run pytest and unittest testing code (i.e., be a test runner for anyone), but unittest can only run unittest testing code, hence why users even have to specify anything (and this sparks an idea I'm going to go talk to Eleanor about 😁).

Following this round of comments, here is my new proposal on the design.
settings.json design
{
      "name": "run config: unique name", // user defined name
      "args": ["-v"],
      "env": {
	"PYTHONPATH": "${workspaceFolder}",
        "DJANGO_TESTING": "true",
	"DJANGO_SETUP_SCRIPT_PATH": "/path/to/file",
      },
       "envFile": "path/to/file",
       "testRunProfileKind": ["discovery", "run", "debug"] // all run kind will also display under debug, but not vice versa
},
"python.testing.framework": ["unittest","pytest"] // this is NOT required, the default will be used if not included

therefore the simplest config if you do all the most basic setup steps with pytest for example would be:
{
      "name": "pytest discovery config",
      "args": [], // this might even be optional too- open to suggestions on if this is a required part of the json.
       "testRunProfileKind": ["discovery"]
},

default values

default value for testing library (unittest or pytest) will be pytest if it is installed in the environment and unittest if not with this value being configurable via a single setting "python.testing.framework".
the default config will now be defined by the dropdown menu on the Test Explorer tab for run and debug like so:

launch.json design
Launch.json configuration for debugging testing will stay exactly as it is now with the current functionality and design. Users will NOT be able to reference their settings.json test configurations from their config.json file. They will need to duplicate / rewrite any configurations they want to use as a debug config there. This will cause duplication of work but I believe will be the simplest for the MVP and I predict users will tend to stick to a single way of use that will make sense to them. @brettcannon, @luabud, @karthiknadig let me know your thoughts on this as I most unsure about this decision and not sure it impact down the road.
Possible UI design:
Will use TestRunProfiles and their related UX. I will update this issue shortly with the flow of how users will set up testing once we switch. Additionally @connor4312 would it be possible to get a dropdown the same as on the "run" and "debug" icons on the reload icon to allow us to configure different profiles of kind "discovery" that could appear here? With the same option to set a default?

If we can't unify in a single file then I am afraid duplication is just unavoidable. We can operate under the assumption that if you're debugging a test it's a single test and thus going to be a bit specific rather than generic to your whole test suite.
One question about "python.testing.framework" is whether that should be global or should we make a per-config setting (thinking of the monorepo case)?

hi @eleanorjboyd! I love this proposal, it would fix an issue my org has with our test suite (we use pytest-xdist to parallelize test runs, but this breaks when we try debugging tests in VS Code). Is there a timeline for when this will be supported?

Is there a timeline for when this will be supported?

Eleanor is busy w/ non-test stuff this month, but the plan is to pick it back up in April.

+1 for this. The collection thing has been really frustrating. Not just that it doesn't work with some args, but also that if you have coverage enabled like so, it overwrites the coverage report. Not critical but it is annoying if you have it setup to discover on save.
The debugging portion of this is a deal breaker. It's working again now, but my issue #22820 is an example of how the current solution is brittle.
"python.testing.pytestArgs": [
        "--cov",
        "--cov-report=html",
        "-vvv",

authors: BrettMoan alenzo-arch brettcannon cameronbrill connor4312 eleanorjboyd luabud roblourens


text:
Jupyter notebook shows only 1 line in output cell

This is Jupyter Lab:

This is VS Code, all the latest versions with Python 3.7:

The second line and any lines below are not shown.
I have set quite a large font for the editor and I used the command "Reset global font size" just before making the screenshot.
Please fix this or describe a workaround because it the Jupyter notebook editor unusable for me like this.

Issues labeled with "Info needed" are closed if we do not receive more information from the issue author in 2 weeks. If you are the issue author and you still are running into this problem, please reactivate with additional information.

source: gharchive/issue

authors: frankgerhardt greazer

repo: microsoft/vscode-python

license: MIT

license_type: permissive

license_source: github-api


text:
Make switching a kernel dirty a notebook

For #10795
10795 was originally about the notebook kernel switch not working. I couldn't repro this, but what I could repro was the kernel switch not being saved. Thought that might be the cause of the original bug.

Codecov Report

Merging #10882 into master will decrease coverage by 0.02%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master   #10882      +/-   ##
==========================================
- Coverage   60.67%   60.65%   -0.03%
==========================================
  Files         580      580
  Lines       31528    31530       +2
  Branches     4479     4480       +1
==========================================
- Hits        19131    19125       -6
- Misses      11427    11433       +6
- Partials      970      972       +2

Impacted Files
Coverage Δ

.../datascience/interactive-common/interactiveBase.ts
5.53% <0.00%> (-0.02%)
:arrow_down:

src/datascience-ui/react-common/arePathsSame.ts
75.00% <0.00%> (-12.50%)
:arrow_down:

src/client/common/utils/platform.ts
64.70% <0.00%> (-11.77%)
:arrow_down:

src/client/linters/pydocstyle.ts
86.66% <0.00%> (-2.23%)
:arrow_down:

src/client/datascience/debugLocationTracker.ts
76.56% <0.00%> (-1.57%)
:arrow_down:

src/client/common/process/proc.ts
14.49% <0.00%> (-0.73%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7a58ce8...f3601af. Read the comment docs.

source: gharchive/pull-request

authors: codecov-io rchiodo


text:
Fix Python extension loading... issue for users who have disabled telemetry

Closes https://github.com/microsoft/vscode-python/issues/14977
Enable discovery experiments for all users including those who have opted out of telemetry.

We squash commits when merging so all 4 commits are merged into Fix Python extension loading... issue commit, so it is commited.


text:
Inconsistent timestamp between sending/local echo and receiving

Type: Bug Report
Describe the bug

OS and Version: Windows 10
VS Code Version: 1.92.2
Serial Monitor Extension Version: 0.12.0
Target embedded device: STM32G4
Other extensions you installed (and if the issue persists after disabling them): issue persists
A clear and concise description of what the bug is.

There is an inconsistent timestamp between data received and the 'local echo print':
11:52:59:340 ->   30.000
11:52:59:356 ->   30.000
11:52:59:356 ->   30.000
11:52:59:373 ->   30.000
11:52:59:448 ---- Sent utf8 encoded message: "sfr 40;" ----
11:52:59:388 ->   30.000
11:52:59:388 ->   40.000
11:52:59:407 ->   40.000
11:52:59:420 ->   40.000
11:52:59:420 ->   40.000
11:52:59:436 ->   40.000

The target MCU sends data every 10ms. We send the command 'sfr 40;' which changes the data from '30.000' to '40.000'
Here you can see the 'Sent utf8 encoded message: "sfr 40;" message is printed with a timestamp of 448ms. But it is printed in between the timestamps 373ms and 388ms. It can also be observed that the observed change from 30 to 40 has a different timestamp then the local echo message. (Which is impossible unless our device has a way to look in to the future).
To Reproduce
Steps to reproduce the behavior:

Click on 'Toggle TimeStamp'
Enable 'Sent Message Echoing'
See error

Expected behavior
I would expect the timestamp of the local echo message to be the same as the timestamp of when it was actually sent.
Code sample and logs
none available
Screenshots
not required, see above text output
Additional context
none available

@daantimmer Thanks for the issue! Definitely an interesting issue. Is this consistently repeatable on your board?
If so, I may be able to reproduce with a board that I have an investigate. If it's not consistent, due to the nature of the bug, it may be difficult to reproduce and investigate.
Any information would be great, thanks!

I'll try next Monday!

Also, what is your board? I might be able to whip up something that is shareable.

authors: daantimmer gcampbell-msft

repo: microsoft/vscode-serial-monitor


text:
Add public repository option in "Publish to GitHub"

Problem
As noted in #102268, the lack of an option to create a public repository is by design rather than a bug. In that issue, @joaomoreno gave the following reason for omitting the option:

We didn't want to overcomplicate this UI, especially since it's fairly straightforward to make the repository public after you create it in GitHub.

I would argue that:

Having two quickpick options instead of one would not significantly complicate the UI.
The process of making a private repository public is not straightforward, especially when the alternative is to just create it as public in the first place. For reference, here are the required steps:

Select "Publish to GitHub private repository" from quickpick and open the repo when finished.

Open repository settings on GitHub.

Scroll all the way to the bottom of the page (to the "Danger Zone") and click "Change visibility."

In the modal, select the "Make public" radio option.

Type the full repo name and click "I understand, change repository visibility."

For me and many others whose primary work is done in public repos, these steps would be completely eliminated if there were an option to create the repo as public in the first place.
Proposal
I don't believe it would be very difficult to implement this feature. Here's a simple solution:
diff --git a/extensions/github/src/publish.ts b/extensions/github/src/publish.ts
index 589bd0d3d3..9105a4bc8e 100644
--- a/extensions/github/src/publish.ts
+++ b/extensions/github/src/publish.ts
@@ -46,7 +46,7 @@ export async function publishRepository(gitAPI: GitAPI, repository?: Repository)
 		folder = pick.folder.uri;
 	}

-	let quickpick = vscode.window.createQuickPick<vscode.QuickPickItem & { repo?: string, auth?: 'https' | 'ssh' }>();
+	let quickpick = vscode.window.createQuickPick<vscode.QuickPickItem & { repo?: string, auth?: 'https' | 'ssh', isPrivate?: boolean }>();
 	quickpick.ignoreFocusOut = true;

 	quickpick.placeholder = 'Repository Name';
@@ -60,6 +60,7 @@ export async function publishRepository(gitAPI: GitAPI, repository?: Repository)
 	quickpick.busy = false;

 	let repo: string | undefined;
+	let isPrivate: boolean;

 	const onDidChangeValue = async () => {
 		const sanitizedRepo = sanitizeRepositoryName(quickpick.value);
@@ -67,7 +68,10 @@ export async function publishRepository(gitAPI: GitAPI, repository?: Repository)
 		if (!sanitizedRepo) {
 			quickpick.items = [];
 		} else {
-			quickpick.items = [{ label: `$(repo) Publish to GitHub private repository`, description: `$(github) ${owner}/${sanitizedRepo}`, alwaysShow: true, repo: sanitizedRepo }];
+			quickpick.items = [
+				{ label: `$(repo) Publish to GitHub private repository`, description: `$(github) ${owner}/${sanitizedRepo}`, alwaysShow: true, repo: sanitizedRepo, isPrivate: true },
+				{ label: `$(repo) Publish to GitHub public repository`, description: `$(github) ${owner}/${sanitizedRepo}`, alwaysShow: true, repo: sanitizedRepo, isPrivate: false },
+			];
 		}
 	};

@@ -79,6 +83,7 @@ export async function publishRepository(gitAPI: GitAPI, repository?: Repository)
 		listener.dispose();

 		repo = pick?.repo;
+		isPrivate = pick?.isPrivate ?? true;

 		if (repo) {
 			try {
@@ -145,11 +150,11 @@ export async function publishRepository(gitAPI: GitAPI, repository?: Repository)
 	}

 	const githubRepository = await vscode.window.withProgress({ location: vscode.ProgressLocation.Notification, cancellable: false, title: 'Publish to GitHub' }, async progress => {
-		progress.report({ message: 'Publishing to GitHub private repository', increment: 25 });
+		progress.report({ message: `Publishing to GitHub ${isPrivate ? 'private' : 'public'} repository`, increment: 25 });

 		const res = await octokit.repos.createForAuthenticatedUser({
 			name: repo!,
-			private: true
+			private: isPrivate
 		});

 		const createdGithubRepository = res.data;

OK sure, feel free to submit a PR.

OK sure, feel free to submit a PR.

Will do, thanks!

authors: jlave-dev joaomoreno

repo: microsoft/vscode


text:
Typescript debugger "broken" on 1.47.x and 1.48.0-insider, working up to 1.46.1 (Ubuntu)

As the title says, looks like Typescript debugger is "broken" on 1.47.x and 1.48.0-insider, was working up to 1.46.1

VSCode Version: 1.48.0-insider, 1.47.3-1595520028, 1.47.2-1594837870, 1.47.1-1594686231
OS Version: Ubuntu 19.10

Steps to Reproduce:

I have the following debug configuration, I'm not using the tsc task inside the debug config because I keep tsc watch running on the background:

{
  "type": "node",
  "request": "launch",
  "name": "API",
  "program": "${workspaceFolder}/../api/src/index.ts",
  "cwd": "${workspaceFolder}/../api",
  "outFiles": ["${workspaceFolder}/../api/build/**/*.js"],
  "sourceMaps": true,
  "protocol": "inspector",
  "env": {
    "MONGODB_URI": "x",
    "EMAILS_QUEUE": "x",
    "AWS_ACCESS_KEY_ID": "x",
    "AWS_SECRET_ACCESS_KEY": "x",
    "AWS_REGION": "x"
  }
}

It works fine on VSCode up to 1.46.1-159242889, on 1.47.x and 1.48.0-insider the debugger crashes telling me:

/home/user/workspace/api/src/index.ts:1
import express = require('express')
^^^^^^

SyntaxError: Cannot use import statement outside a module

Like it is reading the actual Typescript file and trying to execute it with node directly
As simple as that, I've been using this config for quite some time now and it always worked before 1.47.x

Does this issue occur when all extensions are disabled?: Yes

I can confirm this issue is present in VS Code 1.47.3 and Ubuntu 18.04.4

  "program": "${workspaceFolder}/../api/src/index.ts",

You can fix this by pointing your program at the compiled file, rather than the source file.
/duplicate https://github.com/microsoft/vscode/issues/102873

authors: andreafdaf connor4312 el


text:
Allow to rename a workspace file inside VSCode#

Version: 1.47.3
Commit: 91899dcef7b8110878ea59626991a18c8a6a1b3e
Date: 2020-07-23T15:51:39.791Z
Electron: 7.3.2
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Linux x64 5.6.0-kali2-amd64
Steps to Reproduce:

File > Save Workspace as..
1.1 Apparently this is the only way to name/rename a workspace despite multiple feature requests and bug reports closed because it was deemed unnecessary
(With VSCode open) na tovigate folder containing workspace (this was done using the GUI but suspect using CLI would return the same result)
Rename the folder (changed one character in this case)
VScode immediately changes  to 'No Folder Open'
4.1. All open files closed
Workaround issue via File > Open Workspace
5.1. Workspace opens but files remain closed

This behaviour shows VSCode is monitoring the workspace filename in realtime, is able to update the VSCode file explorer dynamically but chooses to just dump the workspace rather than just change the updated name.

Does this issue occur when all extensions are disabled?: Yes/No
If this is to be a requirement of bug reporting it would help to include instructions on how to do this.
Documentation doesn't specify a method
Docs do talk about disabling all Extensions (on the fly) via Disable All Installed Extensions command in the More Actions (...) drop-down menu in the Command Palette. This is not the same as launching with extensions disabled.
Disabling all extensions as above and re-launching VSCode returns the same result

Yes we monitor the workspace file via a file watcher and that currently does not support renames. I think this issue asks for a way to rename workspace files without loosing the list of opened folders inside the current session. Changing to feature request thereby.


text:
Window Issue, border bleeding onto second monitor

Issue Type: Bug
I have a 2nd monitor extended when VS Code is maximized the border bleeds on to the second monitor by 1px. This only occurs with this application.
Expected Results
Window border should not bleed onto second monitor and only be visible in the retained screen.
VS Code version: Code 1.48.2 (a0479759d6e9ea56afa657e454193f72aef85bd0, 2020-08-25T10:13:11.295Z)
OS version: Windows_NT x64 10.0.19041

/duplicate of #85310

My bad.

authors: gjsjohnmurray morgzz


text:
XHR errors when running _workbench.downloadresource command

Hello,
Our extension is using the VS Code command _workbench.downloadresource to download binaries. We can see from our telemetry that some of our users are getting errors with this command: XHR failed and XHR timeout: undefinedms.
From our investigation, these XHR issues are likely due to network issues or to timeouts. However, the existing errors don't provide much details to help us understand more.
Looking at VS Code's codebase, we can see that more details should be included in the XHR failed error, but as of today we don't get any (for none of our users).
Are you aware of reasons for XHR issues with this command? Would you have any recommendations on how to get more details about these errors?

VSCode Version: 1.50.0
OS Version: Windows_NT x64 10.0.19042

Steps to Reproduce: seen in telemetry for a part of our users, not reproducing when using the command directly.

Does this issue occur when all extensions are disabled?: Cannot be tested because we don't have access to the failing users' machines.

I am just using underlying request service to returning the error I receive from request.
https://github.com/microsoft/vscode/blob/df29df80c583c1e9a1c674428cc317e1275296d6/src/vs/platform/download/common/downloadService.ts#L22-L36
Assigning to @deepak1556 to help how to get more info here.

@daniv-msft can you get the network log by asking users to launch code with --log-net-log=<some-absolute-path>/netlog.json and perform the failing request action.

@deepak1556 Thanks for your reply. I cannot ask directly most users to do this (as we mostly see this indirectly through telemetry), but we have one user who contacted us about this issue recently! I just asked the user to provide these logs, and will let you know once I have them.

The user never replied, unfortunately. Since November, we moved to another third-party downloading API to help with this.
Thanks to everyone who had a look into this! I'm closing this issue.

The user never replied, unfortunately. Since November, we moved to another third-party downloading API to help with this.
Thanks to everyone who had a look into this! I'm closing this issue.


text:
IDE doesn't send DAP 'setDataBreakpoints' request

VSCode Version: 1.51.1
OS Version: OSX, Windows

Steps to Reproduce:

Run the official vscode-mock-debug sample
Try to set a data breakpoint to any global variable (Right Click + "Break When Value Changes")

As a result no breakpoints are created, and the last messages in the log (with "trace":true in launch.conf) are:
From client: dataBreakpointInfo({"name":"global_f","variablesReference":1001})
To client: {"seq":0,"type":"response","request_seq":17,"command":"dataBreakpointInfo","success":true,"body":{"dataId":"global_f","description":"global_f","accessTypes":["read"],"canPersist":true}}

So dataBreakpointInfo is sent and succeed, but the IDE doesn't send setDataBreakpoints  after. This worked well in earlier versions.

Does this issue occur when all extensions are disabled?: Yes

/duplicate #110077

This has been fixed in Insiders.

authors: awto weinand


text:
Code - OSS crashed consistently at start time – renderer process crashed! – until after I removed cached data workbench.desktop.main-17c1ea9255cc303c9339b9c2ce2b4a02.code

Issue Type: Bug

reproducible with --disable-extensions
VS Code version: Code - OSS 1.46.1 (cd9ea6488829f560dc949a8b2fb789f3cdc05f5d, 2020-12-16T02:04:21.157Z)
OS: FreeBSD x64 13.0-CURRENT r368589

I can not guess what caused the problem (sorry) but the application became unusable, probably after I used it on the afternoon of evening of Wednesday 2020-12-16.
In the absence of an answer to code-oss (Code - OSS) on FreeBSD-CURRENT: renderer process crashing, the application can no longer open my workspace I methodically removed files from my .config directory, then restored them, until an offending file was identified:
~/.config/Code - OSS/CachedData/cd9ea6488829f560dc949a8b2fb789f3cdc05f5d/workbench.desktop.main-17c1ea9255cc303c9339b9c2ce2b4a02.code
After removing the file

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz (4 x 2893)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: unavailable_offrasterization: disabled_softwareskia_renderer: disabled_off_okvideo_decode: unavailable_offviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_off_okwebgl: enabledwebgl2: enabled

Load (avg)
2, 2, 2

Memory (System)
15.89GB (0.37GB free)

Process Argv
--no-sandbox --unity-launch --no-sandbox

Screen Reader
no

VM
0%

DESKTOP_SESSION
/usr/local/share/xsessions/plasma

XDG_CURRENT_DESKTOP
KDE

XDG_SESSION_DESKTOP
KDE

XDG_SESSION_TYPE
x11

Extensions (12)

Extension
Author (truncated)
Version

ini-for-vscode
Dav
0.0.4

reg
ion
1.0.2

wordcounter
Lud
0.0.1

vscode-language-pack-en-GB
MS-
1.46.3

vscode-ros
ms-
0.6.3

python
ms-
2020.6.91350

cpptools
ms-
1.0.1

languagetool
ray
1.0.1

rewrap
stk
1.13.0

zip-file-system
Tom
2.0.0

reflow-paragraph
Tro
1.3.0

vscode-aspell
zap
0.1.4

From https://stackoverflow.com/a/65367754/38108 after working around the bug:

Extension host terminated unexpectedly.

– with screenshots. Please, is this coincidental? Or might it be relevant?

… cached data …

… an offending file …

#3884

Code - OSS 1.46.1

Re: https://www.freshports.org/editors/vscode/ no more recent version has been ported to FreeBSD,
I sped through subsequent release notes – June 2020 https://code.visualstudio.com/updates/v1_47 to date – found nothing like the crash in this case.

… I can not guess what caused the problem (sorry) …

Through https://github.com/microsoft/vscode/search?q="renderer+process+crashed"+is%3Aissue&type=Issues two issues caught my eye:

https://github.com/microsoft/vscode/issues/97132 ▶ https://github.com/microsoft/vscode/pull/103122 tagged 1.48.0
https://github.com/microsoft/vscode/issues/105984 with reference to a fix in 1.49

– might this issue 113069 be a duplicate of either of those?

Can you follow https://github.com/microsoft/vscode/wiki/Native-Crash-Issues#creating-and-symbolicating-local-crash-reports and attach the crash dumps if you can still repro the crash. Thanks!


text:
Mouse pointer does not move to submenu and submenu disappears.

When I try to use any submenus, either from the top menubar (e.g. File -> Open Recents) or right-click context (e.g. Right Click -> Open Changes), as soon as I move the mouse to the submenu, the pointer jumps to the top of the parent menu and, if I move too far to the right, the submenu just disappears. Hovering over the main menu trigger allows me to use keyboard arrows to operate the submenu, but I can't use the mouse at all. I've tested on version 1.51 and 1.52 with the same problem.

VSCode Version: 1.52, 1.51
OS Version: CentOS 7.6

Steps to Reproduce:

Open File Menu
Highlight "Open Recent"
Move mouse to highlight recent project

Does this issue occur when all extensions are disabled?: Yes

Correction: OS is CentOS 7.7

This does not appear to be a duplicate of any of the above.

Additionally, I connect to the Linux workstation using an RDP client, if that makes any difference in reproducing.

@mrburrito can you confirm your setting for window.titleBarStyle?

@mrburrito can you confirm your setting for window.titleBarStyle?

@sbatten I just tested on a separate remote desktop using AWS Workspaces and I see the same issue. In this case, it's on Amazon Linux 2, but based on that it seems this is an error with VSCode getting the mouse location from a remote desktop session.
On the AWS Workspace, window.titleBarStyle is native. I believe it is the same on my other workstation. Assuming native is the default, I didn't do anything to change it.

@sbatten I just tested on a separate remote desktop using AWS Workspaces and I see the same issue. In this case, it's on Amazon Linux 2, but based on that it seems this is an error with VSCode getting the mouse location from a remote desktop session.
On the AWS Workspace, window.titleBarStyle is native. I believe it is the same on my other workstation. Assuming native is the default, I didn't do anything to change it.

thanks @mrburrito for confirming. this indicates that there may be an issue upstream with how these menus are handled.

thanks @mrburrito for confirming. this indicates that there may be an issue upstream with how these menus are handled.

I tried switching that to custom on the AWS Workspace and the submenus worked properly! Not sure if that changes anything beyond LAF (obviously is does something!) but hopefully that helps isolate the problem.

I tried switching that to custom on the AWS Workspace and the submenus worked properly! Not sure if that changes anything beyond LAF (obviously is does something!) but hopefully that helps isolate the problem.

I don't have access to my original workstation today, but I'm trying to get verification on the current setting and see if changing to custom fixes the menu behavior on the CentOS box as well.

I don't have access to my original workstation today, but I'm trying to get verification on the current setting and see if changing to custom fixes the menu behavior on the CentOS box as well.

I expect it will resolve the issue for both since in the custom case, we handle all of the menu rendering. hope its a good workaround for now.

I expect it will resolve the issue for both since in the custom case, we handle all of the menu rendering. hope its a good workaround for now.

A lot better than not having submenus at all! I'll update once I have confirmation.

A lot better than not having submenus at all! I'll update once I have confirmation.

@sbatten confirmed that custom works on the CentOS workstations as well. It seems to be a problem with native menus and a remote desktop.

@sbatten confirmed that custom works on the CentOS workstations as well. It seems to be a problem with native menus and a remote desktop.

I had a similar issue on Fedora with KDE desktop. Worked after changing to custom

to jump in on this - had same issue with AwesomeWM -- Atom also has this same behaviour, maybe it's an Electron issue?

I also encountered the same problem, I'm using XRDP from windows 10 to connect to Ubuntu 20.04. My current temporary solution is hold [Shift] or [Alt] before moving to the sub-menu.

Hi, I updated to the current stable version of vscode and I can select submenu now with Ubunut 20.04.
In the elecron issue an other user reported it is fixed also in cromium: https://github.com/neutrinolabs/xrdp/issues/1763#issuecomment-932860135

Closing per https://github.com/microsoft/vscode/issues/113630#issuecomment-1098883291

authors: Blanko2 ChrisZIT PranavBakre danielhorng deepak1556 mrburrito sbatten


text:
Terminal Not opening

Issue Type: Bug
Terminal just stopped opening. I have tried to fix but nothing is working
VS Code version: Code 1.53.2 (622cb03f7e070a9670c94bae1a45d78d7181fbd4, 2021-02-11T11:48:04.245Z)
OS version: Windows_NT x64 10.0.19041

It looks like your report is missing some important information, See this wiki page for more info on how to report actionable terminal issues.
/label "needs more info" integrated-terminal

Same issue
Steps:
Menu->Terminal->New Terminal.
Nothing happens.
Version: 1.56.0-insider (system setup)
Commit: 8aff878db2542eea2dfb571c8bb485118bbb3113
Date: 2021-04-19T05:15:35.845Z
Electron: 12.0.4
Chrome: 89.0.4389.114
Node.js: 14.16.0
V8: 8.9.255.24-electron.0
OS: Windows_NT x64 10.0.19041


text:
python debugger fails to launch

Does this issue occur when all extensions are disabled?: NA

VS Code Version:  1.57.0-insider
Commit: 5319757634f77a050b49c10162939bfe60970c29
Date: 2021-05-24T05:12:45.458Z (1 day ago)
Electron: 12.0.7
OS Version: Darwin arm64 20.3.0

Steps to Reproduce:
Python debugger fails to launch with the following error message:

/duplicate #124041

authors: SridharJagannathan weinand


text:
Right mouse menu find dependencies (...) missing

Issue Type: Bug
1: Start VS Code (either Windows 10, or Ubuntu 20.04)
2: VS Code opens up at last location (was editing React App)
3: Open up any javascript/typescript file (.js, .jsx, .ts, .tsx)
4: Right click on an object -- for instance name of a defined function
menu only shows:
Change All Occurences
Format Document
Format Document With
Source Action
Cut
Copy
Paste
Command Palette
Don't get any language intellicode either, intellisense only offers snippets as options.
Had upgraded to 1.58.2 recently. Issue started happening today. Tried disabling all extensions, no difference. Tried complete uninstall, and re-install to version 1.57.1. Issue still persists.
VS Code version: Code 1.57.1 (507ce72a4466fbb27b715c3722558bb15afa9f48, 2021-06-17T13:28:07.755Z)
OS version: Windows_NT x64 10.0.19042
Restricted Mode: No
Remote OS version: Linux x64 5.4.72-microsoft-standard-WSL2

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz (12 x 2208)

GPU Status
2d_canvas: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onrasterization: enabledskia_renderer: enabled_onvideo_decode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
31.88GB (15.73GB free)

Process Argv
--folder-uri=vscode-remote://wsl+Ubuntu-20.04/usr/src/dojo/api --remote=wsl+Ubuntu-20.04 --crash-reporter-id 5c622570-0879-4027-b07e-abcbe09199c7

Screen Reader
no

VM
0%

Item
Value

Remote
WSL: Ubuntu-20.04

OS
Linux x64 5.4.72-microsoft-standard-WSL2

CPUs
Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz (12 x 2208)

Memory (System)
24.96GB (18.57GB free)

VM
0%

Extensions (15)

Extension
Author (truncated)
Version

expressjs
ama
2.0.0

bracket-pair-colorizer
Coe
1.0.61

es7-react-js-snippets
dsz
3.1.1

auto-rename-tag
for
0.1.7

remote-containers
ms-
0.187.0

remote-wsl
ms-
0.56.5

vscode-print
pdc
0.9.8

highlight-matching-tag
vin
0.10.1

JavaScriptSnippets
xab
1.8.0

npm-intellisense
chr
1.3.1

path-intellisense
chr
2.3.0

vscode-eslint
dba
2.1.23

githistory
don
0.6.17

prettier-vscode
esb
8.0.1

vscode-typescript-next
ms-
4.4.20210715

A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
pythonvspyt602:30300191
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyt639:30300192
pythontb:30283811
vspre833:30321513
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
vscus158:30321503
pythonvsuse255:30335481
vscod805:30301674
pythonvspyt200cf:30331938
vscextlang:30333561
binariesv615:30325510
bridge0708:30335490

Does this reproduce in the latest VS Code insiders build with all extensions disabled?

Installed VS Code insiders all worked fine. Returned to VS Code 1.57.1; and initially it still wasn't working. But, this time when I explored the @builtin extensions, I noticed that the TypeScript Language Basics extension was disabled. I was able to enable it and now everything is back to normal. Got a few deadlines, not going to risk 1.58.2 at this point.

authors: mjbvz rohanatlarge


text:
microsoft / vscode-references-view not be localized

https://github.com/microsoft/vscode-references-view/
VSCode-REF-VIEW now has been a builtin extension in vscode.
but now, REF-VEW hasn't be localized, let's to make it support i18n。
FYI:
https://github.com/microsoft/vscode-loc/issues/427
https://github.com/microsoft/vscode-loc/issues/427

This is a duplicate. Unfortunately, I don't recall the exact issue number nor its title :flushed: Anyways, searching for issues with the same labels will likely help you :point_right:
https://github.com/microsoft/vscode/issues?utf8=✓&q=is%3Aopen+label%3A"references-viewlet"

authors: heartacker jrieken


text:
Cannot undo delete cell in Notebooks MacOS

Environment data

VS Code version: 1.60.1
Jupyter Extension version (available under the Extensions sidebar): v2021.8.2041215044
Python Extension version (available under the Extensions sidebar): v2021.9.1230869389
OS (Windows | Mac | Linux distro) and version: Mac OS 11.4
Python and/or Anaconda version: python 3.8.12
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): pyenv
Jupyter server running: Local

Expected behaviour

Delete a notebook cell
Press "Z" to "undo delete cell"

Actual behaviour

Nothing happens when pressing "Z"
Cannot find any "Undo delete cell" command anywhere.

To add to this:
Can replicate,

And additional info on the issue I found for reproducibility:
VS:
Version: 1.60.1 (Universal)
Commit: 83bd43bc519d15e50c4272c6cf5c1479df196a4d
Jupyter Extension: v2021.8.2041215044
Jupyter Keymap: v1.0.0
OS: MacOS 11.5.2
Python 3.9.6
Type of virtual environment used: Conda
Jupyter: Local
Its super finicky. Undo delete cell does not appear in any command, and the shortcut does not appear in jupyter mappings. It looks like regular undo (Cmd-Z / Ctrl-Z) will work to undelete a cell if no other changes are made any cells prior to trying the undo, and as soon as anything is added or changed in cells, it will fail to undelete.
Start, brand new notebook, add two cells

Delete using [...] menu

Undo using topbar

Will recover the cell operations:

Delete again, then type in cell,

It appears it fails alongside the merge-cell functionality disappearing.

Very strange. Don't know if I am doing something wrong, but hope this helps.

I've upgraded VS code to 1.60.2 (as opposed to 1.60.1 when issue was created) and it works.
"Cmd-Z" and "Z" are having the same behavior: they recover my deleted cell.
Closing issue

authors: brunolajoie pa-mike


text:
shoing there is language error while coding

Issue Type: Feature Request
when i start coding alwat there is showing language not supported ..please help
VS Code version: Code 1.62.3 (ccbaa2d27e38e5afa3e5c21c1c7bef4657064247, 2021-11-17T08:11:14.551Z)
OS version: Windows_NT x64 10.0.18362
Restricted Mode: No

What language?
/needsMoreInfo
/gifPlease

authors: gjsjohnmurray satyambholi


text:
"VS Code setting - Search:Max Results" doesn't work

When "VS Code setting - Search:Max Results" is set to null (empty),  The max number of search results is not unlimited but 999.
VS Code version:

Seems to work for me. This search for 'a' in the VS Code source eventually produced an option to close the app:

Here are my search results:

We pass in undefined for the limitResultCount parameter of findMatches:
https://github.com/microsoft/vscode/blob/c8e2fd7baeaa8cd9dc43d3051db66a7428309c97/src/vs/workbench/services/search/common/searchService.ts#L449
But it gets defaulted to 999:
https://github.com/microsoft/vscode/blob/973684056e67153952f495fce93bf50d0ec0b892/src/vs/editor/common/model/textModel.ts#L1169
CC @alexdima

Sorry @rzhao271 dunno if you were working on this already

authors: ShoulderHe gjsjohnmurray roblourens rzhao271


text:
Editor Find/Replace should have better history handling

It is not obvious that you can use the arrow keys on the Editor's Find/Replace "Find" field to populate it with previous things you searched for from there (the placeholder hint only shows when there is no text in the box already, which on my Mac is almost never). And it isn't always consistent between tabs which text is in that history (if the system-wide "find" term on the Mac gets added more than once to that field, it is only done so in the first tab, it seems). And there is never much history there, as it gets cleared frequently on its own (during restarts of the app, and maybe other times too). Which is extremely annoying when you want to go back to a complicated regular expression search you had before.
So, I'd recommend the following improvements:

Write the "find" history to disk, and update it whenever the field changes and a new search is performed .
Use that history whenever opening a new window or tab, or switching between tabs
When the user focuses the "find" field, show a scrollable menu underneath it of all the previous find terms, up to some maximum. User Settings determine what the maximum is, and whether or not the user actually wants this menu to appear every time.
Once the user starts typing anything in that field with a keyboard, turn the menu into an auto-complete menu (i.e. filter it based on what text is in the field).
Add a clock icon button to manually trigger the full list menu.
If the "find" terms selected from the menu also had one or more "replace" texts used with it, present those as choices when the user focuses the "replace" field.
Also have a clock icon button to manually trigger the full list menu or "replace" terms used.

Once the user starts typing anything in that field with a keyboard, turn the menu into an auto-complete menu (i.e. filter it based on what text is in the field).

Auto-complete on search fields a bad idea for anyone searching for similar terms.

If the "find" terms selected from the menu also had one or more "replace" texts used with it, present those as choices when the user focuses the "replace" field.

This sounds difficult to implement and a footgun to use
The only change I would make here is to allow users to have a dropdown of the search history instead of requiring them to spam the up key.

Even just having the dropdown menu, and having it retain its contents between sessions and be consistent in all tabs and windows would be a marvelous improvement.
I do want a menu for replace terms too though, as that can be complex Regular Expression replacement text. Even if it is just a simple list of all the replacements previously entered there.
Oh, and don't do what BBEdit did, by alphabetizing the list. That was horrible. It should be sorted by recency, with most recent at the top.

Looks like duplicate of #23099 with long description.
The only thing that may be not mentioned there and should be added as a comment if wasn't already - filter on type.

Looks like duplicate of #23099 with long description.
The only thing that may be not mentioned there and should be added as a comment if wasn't already - filter on type.

Also, the idea that the "find" history should not disappear all the time (like whenever I need to restart the app or the computer) is a pretty important aspect of this ticket. And that the Mac's shared "find" terms should affect all tabs and windows equally, in terms of how it adds to the history.
Really, the in-document "find" feature in VS Code is ripe for several improvements, and has been for some time, as these issues keep coming up and getting reported repeatedly.

AFAIK search history is preserved for workspace and it's definitely not lost just on app restart.
But if you have 5 different projects/workspaces they would have separate histories tied to them.
If history is lost on app restart - you should create separate ticket focused on that problem.

I think you might be confusing search history and find history, as they seem to be different. I am talking about the history of the find field for in-document finding (command-f or control-f), not the separate tab for multi-file searches.
But also, I don't want 5 different histories for 5 different workspaces. It should be global within VS Code, IMO.

Also, having so many different histories is too complicated and hard to navigate. Mac has a global "find" term that is shared between apps, and that is very simple and convenient. VS Code goes the other way, with separate terms (aside from Mac's global "find" term) and histories between different projects, tabs, find vs search feature, etc. The convenience and simplicity of being able to share find terms and histories cannot be overstated.

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

Hey @IllusionMH, I created a separate ticket for the lost history as #170591; it's been marked as a feature req, but if I understood you correctly, this is not expected behaviour and should be addressed as a bug. Could you weigh in on that one please?

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

:slightly_frowning_face: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

authors: IllusionMH VSCodeTriageBot brad-provident knyzorg rjendoubi


text:
Align Panel is no-op

Testing #141357
None of the "Align Panel" entries seem to do anything:

Oh nevermind, I was not testing this when sidebar and side panel were visible, now it works better 👍


text:
File nesting doesn't update correctly

have the config below
have index.ts, index.js, and index.js.map
.js and .js.map are children ✅
from the context menu delete the index.js file
:bug: the index.js.map file is gone

https://user-images.githubusercontent.com/1794099/165513829-2e4f4488-15e9-4fbc-a91b-9f2228297168.mov
"explorer.fileNesting.patterns": {
		"*.ts": "$(capture).js, $(capture).js.map, $(capture).d.ts",
		"*.js": "$(capture).js.map, $(capture).min.js, $(capture).d.ts",
		"*.jsx": "$(capture).js",
		"*.tsx": "$(capture).ts",
		"tsconfig.json": "tsconfig.*.json",
		"package.json": "package-lock.json, .npmrc, yarn.lock, .yarnrc"
	},

Maybe a duplicate of #147987

@jrieken thanks, do you have explorer.fileNesting.expand set to false?

Confirmative

authors: JacksonKearl gjsjohnmurray jrieken


text:
terminal links bleed together and remain underlined after focus out

https://user-images.githubusercontent.com/29464607/191609450-966f224e-a7b9-40ba-bd2f-b7afe8598f51.mov

It's probably hard to reproduce this

will take a gif whenever I see it happen in case there's a pattern we start to see
https://user-images.githubusercontent.com/29464607/192849108-2531ccc5-81a7-44cb-9eb6-23825f8843c9.mov

what i'm curious about is why it isn't ending the link on the first space char

We can't action this unfortunately until we get a good repro.

authors: Tyriar meganrogge


text:
command 'organizeImports' not found

Type: Bug
When I try to save a ts file that has imports I get an error notification command 'organizeImports' not found
"editor.codeActionsOnSave": {
    "source.organizeImports": true,
    "source.fixAll": true
  },

VS Code version: Code - Insiders 1.73.0-insider (7ea2788a43a4c35d8da63a419725ba2485de395b, 2022-10-19T05:28:16.879Z)
OS version: Windows_NT x64 10.0.19044
Modes:
Sandboxed: Yes

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz (16 x 2904)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: disabled_off

Load (avg)
undefined

Memory (System)
15.75GB (3.39GB free)

Process Argv
--log-net-log=netlog.json --ignore-certificate-error --crash-reporter-id 5f9e326c-2a01-458b-95a4-f411641d6f56

Screen Reader
no

VM
0%

Extensions (32)

Extension
Author (truncated)
Version

iconify
ant
0.4.2

icons-carbon
ant
0.2.6

atlascode
atl
2.10.12

markdown-shiki
bie
0.1.1

path-intellisense
chr
2.8.1

vscode-eslint
dba
2.2.6

dendron
den
0.115.1

dendron-paste-image
den
1.1.1

gitlens-insiders
eam
2022.10.1805

EditorConfig
Edi
0.16.4

vscode-great-icons
emm
2.1.86

prettier-vscode
esb
9.9.0

vscode-firefox-debug
fir
2.9.8

gitlab-workflow
Git
3.54.0

vscode-graphql-syntax
Gra
1.0.4

plantuml
jeb
2.17.4

vscode-peacock
joh
4.2.2

ts-error-translator
mat
0.5.1

dotenv
mik
1.0.1

prettify-json
moh
0.0.3

vscode-scss
mrm
0.10.0

angular-console
nrw
17.23.3

vscode-twoslash-queries
Ort
1.1.0

inline-sql-syntax
quf
2.16.0

vscode-yaml
red
1.10.1

sass-indented
syl
1.8.22

tabnine-vscode
Tab
3.6.15

vscodeintellicode
Vis
1.2.28

vscode-conventional-commits
viv
1.24.3

volar
Vue
1.0.8

vscode-typescript-vue-plugin
Vue
1.0.8

change-case
wma
1.0.0

(2 theme extensions excluded)

A/B Experiments
vsliv695:30137379
vsins829:30139715
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30422396
pythontb:30258533
pythonptprofiler:30281269
vshan820:30294714
pythondataviewer:30285072
vscod805cf:30301675
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593:30376534
pythonvs932:30404738
cppdebug:30492333
vscaat:30438846
vsclangdf:30492506
c4g48928:30535728
dsvsc012cf:30540253
pylantcb52:30590116
pyind367:30587847
vscccc:30564267
pyindex848cf:30577859
nodejswelcome1:30587009

2022-10-19 11:29:44.165 [error] Error: command 'organizeImports' not found
    at S._tryExecuteCommand (vscode-file://vscode-app/<code-insiders>/resources/app/out/vs/workbench/workbench.desktop.main.js:1720:3532)
    at S.executeCommand (vscode-file://vscode-app/<code-insiders>/resources/app/out/vs/workbench/workbench.desktop.main.js:1720:3414) organizeImports undefined

Duplicate of #163994

authors: sschneider-ihre-pvs yume-chan


text:
can't fix code command in vscode with shell command

Type: Bug
I get this error when running code in the terminal in wsl2
# root at rave in ~/pybayts on git:main ● [17:15:14]
→ code .
zsh: Input/output error: code

these instructions don't work anymore for the vscode recent release: https://stackoverflow.com/questions/29955500/code-is-not-working-in-on-the-command-line-for-visual-studio-code-on-os-x-ma
VS Code version: Code 1.72.2 (d045a5eda657f4d7b676dedbfa7aab8207f8a075, 2022-10-12T22:15:18.074Z)
OS version: Windows_NT x64 10.0.19044
Modes:
Sandboxed: No

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-8600K CPU @ 3.60GHz (6 x 3600)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: disabled_off

Load (avg)
undefined

Memory (System)
31.95GB (17.85GB free)

Process Argv
--crash-reporter-id 4aea6e3f-897f-4414-92b4-e57da243ed4c

Screen Reader
no

VM
0%

Extensions (13)

Extension
Author (truncated)
Version

vscode-docker
ms-
1.22.2

python
ms-
2022.16.1

jupyter
ms-
2022.9.1202862440

jupyter-keymap
ms-
1.0.0

jupyter-renderers
ms-
1.0.10

vscode-jupyter-cell-tags
ms-
0.1.6

vscode-jupyter-slideshow
ms-
0.1.5

remote-containers
ms-
0.255.4

remote-ssh
ms-
0.90.1

remote-ssh-edit
ms-
0.84.0

remote-wsl
ms-
0.72.0

vscode-remote-extensionpack
ms-
0.21.0

autodocstring
njp
0.6.1

A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263cf:30335440
pythondataviewer:30285071
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593:30376534
pythonvs932:30410667
cppdebug:30492333
vscaat:30438848
vsclangdc:30486549
c4g48928:30535728
dsvsc012cf:30540253
azure-dev_surveyone:30548225
pyindex848:30577860
nodejswelcome1cf:30587006
fc301958:30595537
2e4cg342:30596373

/question

We closed this issue because it is a question about using VS Code rather than an issue or feature request. Please search for help on StackOverflow, where the community has already answered thousands of similar questions. You may find their guide on asking a new question helpful if your question has not already been asked. See also our issue reporting guidelines.
Happy Coding!

authors: VSCodeTriageBot gjsjohnmurray rbavery


text:
Snippet with TM_SELECTED_TEXT does not work well

This problem still occurs even if you disable all extensions. This problem was confirmed in Markdown file.
To reproduce

Create a snippet containing TM_SELECTED_TEXT
like below:
"TM_SELECTED_TEXT": {
  "prefix": "tm_selected_text",
  "body": "the original ${1:$TM_SELECTED_TEXT} is gone.",
  "description": "Snippet included TM_SELECTED_TEXT"
},

Use the snippet made in 1

Version

Windows 11

VS Code
Version  : 1.73.0 (user setup)
Commit   : 8fa188b2b301d36553cbc9ce1b0a146ccb93351f
Date     : 2022-11-01T15: 34: 06.111Z
Electron : 19.0.17
Chromium : 102.0.5005.167
Node.js  : 16.14.2
V8       : 10.2.154.15-electron.0
OS       : Windows_NT x64 10.0.22000
Sandboxed: No

I also checked the Insider version. As in the Stable, TM_SELECTED_TEXT didn't work well.
In addition, the Insider version didn't show snippet suggestions. It was displayed by pressing Ctrl+Space.
Version  : 1.74.0-insider (user setup)
Commit   : 2282be522a8031209a739783baede67bfa9fc95a
Date     : 2022-11-08T05: 23: 21.062Z
Electron : 19.1.3
Chromium : 102.0.5005.167
Node.js  : 16.14.2
V8       : 10.2.154.15-electron.0
OS       : Windows_NT x64 10.0.22000
Sandboxed: Yes

I would like to say, TM_SELECTED_TEXT was working the past week, so this issue is recent.

@jrieken

You need to use "F1 > Insert Snippet", "F1 > Surround With Snippet", or the surround with quick fix (from the light bulb) for this

I know the functions of Insert Snippet and Surround With Snippet. However, until now, simply selecting a snippet displayed in the suggestions would insert the selected text at the specified location by TM_SELECTED_TEXT.
Is there no longer a way to use snippets as before?

this is a regression from https://github.com/microsoft/vscode/commit/1e662b070fd9f847dfefbdf3f45d0fe538d7e974

Thank you for reopening this issue.  Sorry for the confusion caused by my poor explanation of this issue.

have the echo-snippet provided above
in the editor have ddd and select it all
type ech, see and accept the snippet suggestion
🐛 only echo is inserted, not echo ddd

The problem presented by this procedure is the very issue I have raised.

Glad this is opened. Following this one. Hopefully this is resolved quickly.

fixed via https://github.com/microsoft/vscode/pull/165871

fixed via #165871

Do I have to use the insiders version to test these changes?

Still, $TM_SELECTED_TEXT does not work!

It seems there is still something wrong with version 1.74.0.
Consider the following snippet and register it for plaintext, markdown and latex (without LaTeX-Workshop enabled)
	"poo": {
		"prefix": "pair",
		"body": "xx((${0:$TM_SELECTED_TEXT}))xx"
	}

Select some text and type pair with quick suggestions enabled. Observe that

in .txt files, some text is replaced by xx((some text))xx as expected
in .md or .tex files, some replaced is replaced by xx(())xx.

I can open a new issue if you prefer.

I've found patterns where $TM_SELECTED_TEXT doesn't work well. This problem still occurs even if you disable all extensions. And this was confirmed in markdown file.
However, the problem does not reproduce all the time, but occasionally. So sorry I couldn't create a GIF image because the problem doesn't reproduce all the time. However, it is quite irritating when encountered.

Create a snippet like this:{
  "fooBar": {
    "prefix": "foobar",
    "body": "foo${1:$TM_SELECTED_TEXT}bar",
    "description": "fooBar"
  }
}

Select multiple lines of text containing the string contained in "body". (It works fine if it's just single line)

Select whether the string inserted by the snippet adjacents the original string or has only one newline between them.

foo bar
foo bar
foo bar

Use the snippet. The following results are obtained.foobar

On the other hands, When using snippets for text such as the following, it was not possible to confirm the behavior that does not work well.
baz
foo bar
baz
foo bar
baz

my impressions of the problems
I feel that $TM_SELECTED_TEXT does not work well when memory is overloaded... I felt that it was reproduced more often when the extensions was enabled than when all the extensions were disabled.
Additionally, even if once this problem occurs, using Ctrl+Z to undo and then using the snippet again works fine.
Sorry for the unclear report.
Stable version
Version  : 1.74.0 (user setup)
Commit   : 5235c6bb189b60b01b1f49062f4ffa42384f8c91
Date     : 2022-12-05T16:38:16.075Z
Electron : 19.1.8
Chromium : 102.0.5005.167
Node.js  : 16.14.2
V8       : 10.2.154.15-electron.0
OS       : Windows_NT x64 10.0.22621
Sandboxed: No

Now it works for me.
Version: 1.74.0 (user setup)
Commit: 5235c6bb189b60b01b1f49062f4ffa42384f8c91
Date: 2022-12-05T16:38:16.075Z
Electron: 19.1.8
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Windows_NT x64 10.0.19044
Sandboxed: No

This is still not working in *.txt, *.md, *.js, *.ts, and *.json files. Works in *.html, *.xml, including *.config, files though.
Version: 1.74.1 (user setup)
Commit: 1ad8d514439d5077d2b0b7ee64d2ce82a9308e5a
Date: 2022-12-14T10:30:51.966Z
Electron: 19.1.8
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Windows_NT x64 10.0.19042
Sandboxed: No

authors: Yarakashi-Kikohshi emremutlu08 jlelong jrieken marcacyr mreduar ollalla stramin


text:
Version control 'Revert Change' is broken

Type: Bug
When reverting changes using the 'Revert Change' feature, the editor is not reverting the change but actually appending the original line along with the current modification.
For example, if changing the following line:
@pytest.fixture(autouse=True)

To:
@pytest.fixture(autouse=True, scope="module")

Clicking on 'Revert Change' produces:
@pytest.fixture(autouse=True, scope="module")
@pytest.fixture(autouse=True)
@pytest.fixture(autouse=True, scope="module")

But the expected result should be:
@pytest.fixture(autouse=True)

VS Code version: Code 1.76.0 (92da9481c0904c6adfe372c12da3b7748d74bdcb, 2023-03-01T10:25:16.105Z)
OS version: Linux x64 5.19.0-35-generic snap
Modes:
Sandboxed: No

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz (8 x 3500)

GPU Status
2d_canvas: unavailable_softwarecanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: disabled_softwaremultiple_raster_threads: enabled_onopengl: disabled_offrasterization: disabled_softwareraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: disabled_softwarevideo_encode: disabled_softwarevulkan: disabled_offwebgl: unavailable_softwarewebgl2: unavailable_softwarewebgpu: disabled_off

Load (avg)
1, 1, 1

Memory (System)
15.40GB (9.81GB free)

Process Argv
--no-sandbox --force-user-env --unity-launch --crash-reporter-id 8eace1af-0f41-4f71-8f4b-3b02eaf5f265

Screen Reader
no

VM
0%

DESKTOP_SESSION
ubuntu

XDG_CURRENT_DESKTOP
Unity

XDG_SESSION_DESKTOP
ubuntu

XDG_SESSION_TYPE
wayland

Extensions (13)

Extension
Author (truncated)
Version

Bookmarks
ale
13.3.1

aws-toolkit-vscode
ama
1.64.0

gitlens
eam
13.3.2

vsc-material-theme
Equ
33.6.0

vsc-material-theme-icons
equ
2.6.1

theme-monokai-pro-vscode
mon
1.2.0

vscode-docker
ms-
1.24.0

isort
ms-
2022.8.0

python
ms-
2023.4.1

vscode-pylance
ms-
2023.3.20

autodocstring
njp
0.6.1

vscode-yaml
red
1.12.1

ayu
tea
1.0.5

(5 theme extensions excluded)

A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593cf:30376535
pythonvs932:30410667
cppdebug:30492333
vsclangdf:30486550
c4g48928:30535728
dsvsc012:30540252
pynewvextcfv2:30681851
azure-dev_surveyonecf:30548226
pyindex848:30662994
nodejswelcome1:30587005
282f8724:30602487
pyind779:30671433
f6dab269:30613381
pythonsymbol12:30671437
a9j8j154:30646983
vsccsb:30677849
vscodedisable:30660115
pythonb192cf:30669361
funwalk2:30676043
pythonms35:30680984

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.76.1. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

/duplicate and fixed in 1.76. 1

authors: VSCodeTriageBot aalvrz gjsjohnmurray


text:
O VS Code falha ao tentar salvar um arquivo

Type: Bug
O VS Code falha ao tentar salvar um arquivo em um diretório com permissões de gravação somente para leitura.
VS Code version: Code 1.77.3 (704ed70d4fd1c6bd6342c436f1ede30d1cff4710, 2023-04-12T09:16:02.548Z)
OS version: Windows_NT x64 10.0.22621
Modes:
Sandboxed: No

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-1035G1 CPU @ 1.00GHz (8 x 1190)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: disabled_off

Load (avg)
undefined

Memory (System)
7.80GB (1.86GB free)

Process Argv
--crash-reporter-id c7aa809e-78b6-4fe8-b7a7-34a2fe03be4a

Screen Reader
no

VM
0%

Extensions (23)

Extension
Author (truncated)
Version

vscode-django
bat
1.10.0

python-environment-manager
don
1.0.4

python-extension-pack
don
1.7.0

prettier-vscode
esb
9.12.0

code-runner
for
0.12.0

terminal
for
0.0.10

vsc-python-indent
Kev
1.18.0

isort
ms-
2022.8.0

python
ms-
2023.6.1

vscode-pylance
ms-
2023.4.30

jupyter
ms-
2023.3.1201040234

vscode-jupyter-cell-tags
ms-
0.1.8

vscode-jupyter-slideshow
ms-
0.1.5

js-debug-nightly
ms-
2023.4.1317

live-server
ms-
0.4.7

vsliveshare
ms-
1.0.5862

autodocstring
njp
0.6.1

sqlite-viewer
qwt
0.2.4

LiveServer
rit
5.7.9

in-your-face-incredible
TTO
1.1.0

intellicode-api-usage-examples
Vis
0.2.7

vscodeintellicode
Vis
1.2.30

jinja
who
0.0.8

(2 theme extensions excluded)

A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscoreces:30445986
pythondataviewer:30285071
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593cf:30376535
pythonvs932:30410667
cppdebug:30492333
vsclangdf:30486550
c4g48928:30535728
dsvsc012cf:30540253
pynewext54:30695312
azure-dev_surveyone:30548225
vscccc:30610679
nodejswelcome1cf:30587006
3biah626:30602489
pyind779:30671433
89544117:30613380
pythonsymbol12:30671437
2i9eh265:30646982
6233i204:30672705
vsctsb:30705553
azdwalk:30721579
pythonms35:30701012
pythonfmttextcf:30716743

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!

authors: Rikelmelopes VSCodeTriageBot


text:
Freezing Terminal

Type: Bug
My terminal sometimes freezes and loses all colors and formatting when I click in it. Then I have to close the terminal (with the trashcan icon) and reopen it. Unfortunately, I can't really reproduce it, since it only happens once in a while.
VS Code version: Code 1.77.2 (e344f1f539a80912a0e9357cec841f36ce97a4e2, 2023-04-06T10:09:14.609Z)
OS version: Linux x64 5.14.0-1048-oem
Modes:
Sandboxed: No

System Info

Item
Value

CPUs
11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz (8 x 3296)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: disabled_softwarevideo_encode: disabled_softwarevulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: disabled_off

Load (avg)
1, 1, 1

Memory (System)
15.36GB (11.27GB free)

Process Argv
--unity-launch --crash-reporter-id e33ef53e-1793-422b-b06b-f0dc3d14e938

Screen Reader
no

VM
0%

DESKTOP_SESSION
ubuntu

XDG_CURRENT_DESKTOP
Unity

XDG_SESSION_DESKTOP
ubuntu

XDG_SESSION_TYPE
x11

Extensions (36)

Extension
Author (truncated)
Version

better-comments
aar
3.0.2

vscode-sqlite
ale
0.14.1

ng-template
Ang
15.2.1

vscode-tailwindcss
bra
0.9.11

csharpier-vscode
csh
1.3.6

vscode-mysql-client2
cwe
6.4.1

dart-code
Dar
3.62.0

vscode-deno
den
3.17.0

javascript-ejs-support
Dig
1.3.3

prettier-vscode
esb
9.12.0

copilot
Git
1.84.51

go
gol
0.38.0

dotnet
leo
1.3.0

inifmt
lkr
0.1.5

regionfolder
map
1.0.22

vscode-pdf
mat
0.0.6

git-graph
mhu
1.30.0

csharp
ms-
1.25.4

remote-ssh
ms-
0.100.0

remote-ssh-edit
ms-
0.84.0

cpptools
ms-
1.15.4

remote-explorer
ms-
0.4.0

prisma
Pri
4.13.0

quicktype
qui
12.0.46

webgl-glsl-editor
rac
1.3.4

java
red
1.18.0

vscode-xml
red
0.25.0

LiveServer
rit
5.7.9

shader
sle
1.1.5

intellicode-api-usage-examples
Vis
0.2.7

vscodeintellicode
Vis
1.2.30

vscode-java-debug
vsc
0.50.0

vscode-java-dependency
vsc
0.22.0

vscode-java-pack
vsc
0.25.11

vscode-java-test
vsc
0.38.2

vscode-maven
vsc
0.41.0

A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263cf:30335440
vscorecescf:30445987
pythondataviewer:30285071
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593cf:30376535
pythonvs932:30410667
cppdebug:30492333
vscaac:30438847
vsclangdc:30486549
c4g48928:30535728
dsvsc012:30540252
pynewext54:30695312
azure-dev_surveyone:30548225
nodejswelcome1cf:30587006
3biah626:30602489
pyind779:30671433
89544117:30613380
pythonsymbol12:30671437
showlangstatbar:30730054
vsccsb:30705552
azdwalk:30721579
pythonms35:30701012
pythonfmttextcf:30716743
fixhidewlkth:30730051

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.77.3. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

Next time it happens can you take a screenshot?

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!

Hey, I found a way to reproduce it. You need to click between the first terminal line and the panel header (see video)
VSCode version 1.77.1 from AUR package https://aur.archlinux.org/packages/visual-studio-code-bin
using KDE/Xorg/ArchLinux
https://github.com/microsoft/vscode/assets/42669835/6991e4b1-eafc-4a3c-bd5e-3c6d53f6e73c

@LeBogoo clicking shouldn't be able to bring that up, in the meantime pressing tab will put you back to the regular view

@LeBogoo can you reproduce this in insider's?

authors: LeBogoo Tyriar VSCodeTriageBot iTrooz meganrogge


text:
Request to add a new feature to Visual Studio Code

Dear Visual Studio Code Team,
I hope this post finds you well. I am a regular user of Visual Studio Code, and I am writing to request a new feature that I believe would greatly enhance the user experience.
As you know, when writing lengthy code in Visual Studio Code, it is sometimes necessary to scroll up and down to make changes in different sections of the code. This process can be time-consuming, especially when dealing with large files with many lines of code.
Therefore, I would like to suggest adding a new feature to Visual Studio Code that would allow users to pin a specific area of their code in the minimap. By doing so, users could quickly navigate to that particular section of code without having to scroll manually.
The proposed feature would be simple to use. Users would be able to click on the pinned section of the minimap, and they would be taken directly to that section of code in the editor. This feature would save users time and effort, as they would not have to spend time searching for the section of code they need to edit.
I believe this feature would be a valuable addition to Visual Studio Code and would benefit many users. I hope you will consider my request and add this feature in a future update of the application.
Thank you for your time and consideration.
Sincerely,
Brahm Dev Singh

There is a great extension named Bookmarks by Alessandro Fragnani which lets you bookmark locations in your source code.   I would be lost without it.

Some Vim extensions add bookmark functionality with ( ma ).
I'd suggest you change the name of the title to reflect the feature you are trying to request, which if I'm interpreting correctly is: VScode Bookmarks in Minimap

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

I agree, it would be really nice if VS Code had native functionality similar to that provided by the Bookmarks and Numbered Bookmarks extensions, and the minimap would be the perfect way to navigate between them visually. It would also be nice if you could give them names, and navigate between them by name using the keyboard--something that neither of the above extensions seem to support.

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

:slightly_frowning_face: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

authors: Brahmdevsingh MarioRicalde VSCodeTriageBot mccrimmonmd msweeney1999