[oefrha]

Anyone else noticed that when editing a notebook in VS Code, one could lose unexecuted edits to a cell with accidental arrow key input (that defocuses the current cell and erases changes)? Too many times I have lost a paragraph worth of Markdown text midst typing, it’s kind of maddening.

[derriz]

Yep - it's very annoying but for me it only happens with markdown cells? So now I generally select all and copy now before leaving a markdown cell if I've edited it.

The other issue is the language server seems to get into a funk regularly - the completion stops working as does the display of docstrings so I regularly use the "Developer: reload window" feature to reset everything.

Also the plots view is poor - it's basically just an SVG you can magnify - there's no proper zoom or rotation for 3d plots.

I was also irritated by the "smart" environment discovery stuff - just let me specify which python install or vent I want to use. Don't make be google to see what names/locations I have to use in order for an environment to magically appear in the list.

Also the editor extension (I use vi mode) is ignored. And even saving the notebook doesn't work the way every other editor pane works in vscode.

Hmm... writing this list makes me wonder why I haven't looked at alternatives.

[connor4312]

Fyi VS Code is working on[1] native first-class notebook support, which should make the experience of using a notebook much better. Notebooks right now stretch the bounds what extensions can do, particularly in that they can't use the VS Code's own text editing services, so things like vi mode aren't inherited.

(Disclaimer: I work on VS Code, but am not working on notebooks)

1. https://github.com/microsoft/vscode/issues/88243

[oefrha]

Cool. A while ago I wanted to report bugs wrt notebooks but the bug reporting flow asked me to turn off extensions, and after turning off extensions notebooks no longer work, so I didn’t even know where to report the bugs.

[connor4312]

Jupyter Notebooks today are handled by the Python extension, which is a separate codebase and team from VS Code. You should file issues there: https://github.com/Microsoft/vscode-python

[greazer]

Disclaimer: I am the engineering manager for the jupyter support supplied in the Python extension.

I LOVE this feedback! Keep it coming (though entering issues https://github.com/Microsoft/vscode-python would be ideal)

Yes, as conner4312 VS Code is investigating how to better incorporate a juypter notebook experience within it, natively. As has been pointed out here, there are a number of limitations that the python extension notebook support has run into. We have been working closely with the VS Code team to find solutions to these limitations. The custom editor work (https://github.com/microsoft/vscode/issues/77131) is one such mechanism. We plan on rolling out our use of that work soon after it is officially released (sometime in February). However, this will not address all of the problems mentioned in this thread. Those issues will be addressed as native jupyter support arrives in VS Code.

Here's some additional info: - Find/replace. (Personally, this drove me NUTS! Just ask my team! :) ) That being said a simple find (ctrl-f) is avaiable in the current official release. Unfortunately, it does not include replace. While we recognize that this is a severe limitation for some, implementing a full find and replace solution would end up requiring the extension to duplicate most of the functionality provided by VS Code itself. Therefore, we currently planning to piggy back off of that work when it becomes available. If that winds up taking an inordinate amount of time, we will consider further stop gap work.

- The markdown loss issue has been addressed and will be in the February release.

- For the language server problem discussed above, we need more info. I would encourage you to enter a new issue at https://github.com/Microsoft/vscode-python. In the meantime, there are known related issues that will be fixed the Feb release. One in particular, was caused by the backend jupyter server inexplicably taking a long time to return us a full completion list. So when you don't see completion pop up, it may not be that it's broken, it may just be taking a long time. We are working around this issue for the February release. Also, if you're having docstring issues, you may find that turning off the python jedi language service in settings will help.

- Plots view. Yes, it is limited and honestly can cause rendering slowdowns. We are working through ways of addressing both problems. A good solution for supporting "proper" zoom will require adding ipywidget support overall, which is coming soon.

- "Smart environment stuff". I'm not following completely. Is this a general python extension issue or does it have to do with the jupyter kernel selection support we have for notebooks? Again, feel free to enter additional details at: https://github.com/Microsoft/vscode-python

- Supporting global editor extensions like "VI mode", isn't something that we can support without help from VS Code itself. One of the main reason's VS Code is pursuing native notebook support is to be able to handle issues exactly like this.

- Saving the notebook weirdness will be addressed in the February release. We were waiting for the custom editor support I referred to above to arrive.

Hope this is useful information!

[derriz]

Great response - I really appreciate the detail and also commend the tone you use. It makes me a little worried that I came across as too negative earlier.

To balance that: I haven't forgotten the "WOW WHAT IS THIS" feeling I experienced the first time opened an ipynb file from vscode when the notebook support kicked in and asking my colleagues "did you know about this?" as I excitedly started exploring the feature. Since then (and I'm a relative vscode noob), I've never been tempted to go back to working with notebooks through a browser. Despite my gripes, the overall experience is still miles better (in my opinion) than accessing notebooks through a browser. It's the future for sure.

And thanks for all those updates - I can't wait for the Feb release - and it's very reassuring that these issues are not only well recogonized but also are being aggressively addressed.

Regarding some of your feedback to the feedback:

- Re. the language server issue - it could well be caused by a slow down. I'll test that hypothesis the next time I experience it.

- The "smart environments stuff" is, as you say, actually a general python extension issue. But actually, I withdraw that complaint. I've just checked and I can point the extension at any python interpreter by editing settings.json - it's just the GUI which restricts you to selecting from a list of discovered interpreters.

Thanks again for your response and your engineering efforts in general.

[greazer]

Glad to hear, derriz!

I think environment selection would be considered a bug. I theory any python environment that's on your machine should be selectable in the UI. Could you enter an issue at that same location? I can for you, but I'd prefer that the issue comes directly from an outside user (sometimes we filter bugs based on from where they came).

[oefrha]

> - The markdown loss issue has been addressed and will be in the February release.

Awesome!

> - For the language server problem discussed above...

I don’t think that’s Python-specific, I’ve encountered language server seemingly getting “stuck” in some state for almost any language I’ve used for more than a few minutes in VS Code, including Python, C/C++, Go, Rust, etc. I usually need to reload the window more than once per day.

> - "Smart environment stuff".

Probably talking about the general Python-mode Python selector. One can only choose from a list of detected Pythons; no file system dialogue available, and one can’t even paste in a full path unless it’s in the “sanctioned” list. I’ve cursed on this one too.