Expected: search window pops up, able to type in strings to find them in the document
Actual: No search window
Please provide as much info as you readily know
None
A lot of the features that are common to the VS Code editor will not be supported for a while.
We can't wait for VS Code to support custom editors to enable this functionality.
I appreciate that Kutu said it was a high priority. It is difficult to understand how a professional data scientist can operate without ever using find while scripting.
If it helps to understand the use-case picture this: I thought maybe this native ipynb was a killer feature for me. I was porting in a script to a native ipynb from another source file via cut and paste. I was formatting it for a jupyter notebook, and while reviewing code I thought "hey which block did I define this variable in?" Ctrl +F... nothing. "Oh wow..."
I can her the frustration, and I can join the party.
The best approach I could find out of the spot is exporting the code in python style (so a native window) and use the CTRL+F there.
It's not a very efficient solution, I understand that, but at least it can work in the meantime and in the meantime the guys seek for some collaboration between the teams?
After all, my understanding is this extension has been created just a month ago, and in all honesty I can see lots of potentials in not using the webeditor anymore.
Probably related: the command "Replace in Files" does not behave as expected with Jupyter notebook files. Clicking on search results displays the search result in a new tab with the file opened as a plain text file. Executing a replacement causes the search pane to announce that the replace was successful, but the view of the file does not update, even though the underlying file has been changed.
I find if I make an edit and then save the file, the changes are reloaded from the file. However doing search and replace like this is probably a dangerous operation because it operates on the underlying JSON.
VS Code is adding custom editor support in their February release (https://github.com/microsoft/vscode/issues/77131). This support will allow us to fix several nagging problems we've had with notebook support, including the ctrl-f and save-as among other things.
Our target for providing this support is either the first Python extension release after VS Code's Feb release, or a point release soon after.
Here's the costing for the work per microsoft/vscode-python#9457.
Change nativeEditorProvider into a WebViewCustomEditorProvider - 1 day
Wire up WebPanel class into the webviewPanel (instead of creating our own webViewPanel) - 1 day
Remove code that tries to mess with active panels - .5 day
Implement save/saveAs - 1 day
Fire edit events - 1 day
Support undo/redo - 3 days
What to do about blank files? (Question out to VS code for answer)
Write tests that mock the new API but still open notebook editors - 3 days
Please note for all interested parties. At first we had thought that this new VS Code custom editor support was required to make Ctrl-F (Find) available. However, during our investigation we discovered that Find for webviews was already available. We turned that on in the January 2020 release of the python extension.
So the work done to complete this particular issue (support the new custom editor api) will not provide any additional behavior to the current webview Find behavior, which is pretty limited.
However, this work will improve much of the other problematic behavior we've had to workaround in our notebook implementation.
This effort is well underway, but cannot be released until VS Code ships its support in the official release. If available for March, we will ship that month.
Unfortunately, due to the churn on the custom editor API, there has never been a good time to turn this functionality on. At this point the new VS Code Native editor API work has begun and will address all of the issues (plus more) that this effort would have. Therefore, closing.
Please see https://github.com/microsoft/vscode/issues/91987.
After further consideration, and our understanding that the direction of the notebook api support in VS Code will be built on the same model as custom editor, we are bringing this back in.,
@greazer @rchiodo gentlemen, I am trying to get an idea if June 2020 is still the target release date for this.
This issue is driving me crazy. The fix in microsoft/vscode-python#11891 partially handles the problem, but is very buggy (sorry @rchiodo). Other issues are being closed referencing this issue.
So, I am just trying to understand where things are at. Thank you for all the hard work and if you need help testing things, please don't hesitate to holler.
I don't think it likely at this time we'll get this in for June (we have 3 days left before we lock down). So maybe for July.
Experiment for a subset of customers has been activated. If all is looking good, we will raise the percentage and continue to monitor.
Most helpful comment
After further consideration, and our understanding that the direction of the notebook api support in VS Code will be built on the same model as custom editor, we are bringing this back in.,