A feature I would like is use my VScode against a python programming environment in docker.<p>The only way I have found this possible is to actually run VSCode itself in docker.
Not to hijack the thread, but does anyone know a good way to run vscode remotely? I have a large c++ code base that only compiles on a specific server, and I'd like to run it there. I tried code-server, but it's extremely buggy, and not quite ready for prime time. X forwarding was also painfully slow. Is vnc the only option?
I’ve found the language server practically useless because of regressions introduced in later versions. This wouldn’t be too bad except the language server auto updates. For now I’ve switched to the default Jedi version which was been working reliably.
I enjoyed Golang in VSCode so much that I started using Python in it for a few weeks.<p>My favorite things about VSCode are the speed (compared to Pycharm), the custom keybindings, and the integrated terminal that I can snap back and forth to with the keybindings.<p>The main thing that it lacked was the <i>excellent</i> Python refactoring tools that Pycharm free edition has. I should never have to find and replace to refactor when I'm dealing with code all in the same language.
edit: Also the auto-imports were terrible in VSCode, while they are also excellent Pycharm.<p>Still using it for Golang, but I'm back to Pycharm for Python.
Overall I really like this extension and especially its interactive programming / notebook features. I am a big fan of jupyter notebooks, and wrote my own version for Scala (it was more inspired by Mathematica since Juypter didn't exist yet) a long long time ago.<p>However having all the output be in a dedicated window as this extension does, that allows for scrolling back in the order things were run rather than in the order they are laid out in the notebook is turning out to be better for some use cases. Also, it allows having the output side-by-side which takes better advantage of the horizontal to vertical pixel ratio of monitors.<p>Another thing I like is that editing cells as plain text using #%% to separate them is just a better more intuitive interface for a programmer than having a bunch of separate text-areas (imho). And it nicely dodges all the padding and unnecessary white-space problems that a Jupyter notebook has compared to a mathematica one, allowing more information to fit on the screen.<p>For one downside: I haven't ever used an extension that is so inclined to randomly pop up with tips and surveys while I am programming as this one. It's incredibly annoying and I've spent a lot of time trying to figure out how to disable it. Including looking through the code on github, but don't see anyway at all to do it.<p>It's a catch-22 situation because VS Code doesn't have the option to disable notifications like these, the person in charge of deciding if there should be a feature to prevent popups says that it's an extension issue and to take it up with them. And the extension clearly doesn't have the mindset that it is an issue and frankly I don't think it's an extensions job to re-invent the wheel on this every time so I don't blame them. They are using the tools they have as extension authors because it's clearly not the extensions job to set the style of of notification deliver to the user, only that there is one to present, perhaps with an associated urgency level. The IDE ought to then deliver it in the manner most desired by it's user.<p>Contrast this with Intellij which works around all of this by simply having a thought out system for notifications, wherein the user, can force them all to go to a log in a panel without a popup, which, for me is great because I'm coding, don't knock me out of the zone!
Great new features, though it's a little bit shame that we still need to import a .ipynb file manually to work with it (I know it is not the VScode team's fault).<p>I really wish that the Jupyter community would consider re-design .ipynb file format, such as separating a source code (cells) as a file and stopping using JSON format.<p>The current .ipynb file format is highly against modern software engineering. Since it contains everything inside of a single file including giant binaries, it is almost impossible to properly version control, and there is no point of using human-readable JSON format because its content is already not human-readable.