-
Notifications
You must be signed in to change notification settings - Fork 294
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix interactive window debug cell, codelens tracking, go to cell, expand/collapse all from toolbar when focus is not on notebook editor #6469
Conversation
Codecov Report
@@ Coverage Diff @@
## main #6469 +/- ##
=====================================
- Coverage 69% 69% -1%
=====================================
Files 410 410
Lines 28248 28248
Branches 4184 4190 +6
=====================================
- Hits 19624 19620 -4
- Misses 6956 6962 +6
+ Partials 1668 1666 -2
|
autoReveal: true | ||
}); | ||
return true; | ||
return this.submitCodeImpl(code, file.fsPath, 0, false, notebookCell); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was actually having to look this up myself. But this try catch block now seems funny. If you're directly returning the promise from submitCodeImpl I don't believe that the try catch block is relevant anymore. Looks to me like a case of this here: https://stackoverflow.com/questions/38708550/difference-between-return-await-promise-and-return-promise/42750371#42750371
const interactiveWindow = this.interactiveWindowProvider.activeWindow; | ||
private expandAllCells(uri?: Uri) { | ||
const interactiveWindow = uri | ||
? this.interactiveWindowProvider.windows.find((window) => window.notebookUri!.toString() === uri.toString()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the code it looks like notebookUri is always defined, but the "!" feels a tiny bit less typesafe here since it is optional on the interface. Would ? accomplish the same thing since undefined won't equal uri.toString()?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohh, looks like you have ? below for exportAs (was just reading on more). Can we use that in these locations as well.
@@ -454,7 +466,7 @@ export class NativeInteractiveWindowCommandListener { | |||
|
|||
private export(uri?: Uri) { | |||
const interactiveWindow = uri | |||
? this.interactiveWindowProvider.windows.find((window) => window.notebookUri!.toString() === uri.toString()) | |||
? this.interactiveWindowProvider.windows.find((window) => window.notebookUri?.toString() === uri.toString()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this 'find matching interactive window' could be on the intearctiveWindowProvider? And then everyone of these functions would use that code instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately we're still using the IInteractiveWindowProvider
interface which is shared for webview, so I'd have to put that method on the old provider too (and it doesn't make sense there). I tracked this item in a list of todos for webview code cleanup #6488 feel free to add more there as well :)
…and/collapse all from toolbar when focus is not on notebook editor (#6469) (#6493) * fix #6423 * Debug cell fixes * update execution count. * Expand/collapse cell should not rely on `activeNotebookEditor` * Format * Refactor add/debug code codepaths * Prettier Co-authored-by: rebornix <penn.lv@gmail.com> Co-authored-by: rebornix <penn.lv@gmail.com>
* prepare release (#6403) * Port jupyter kernel fix to release branch (#6486) * Fix some problems running kernels with 'jupyter' or no raw kernel (#6464) * Fix for 6409 * Jupyter server specific case for kernel data not being used * Update changelog * Fix interactive window debug cell, codelens tracking, go to cell, expand/collapse all from toolbar when focus is not on notebook editor (#6469) (#6493) * fix #6423 * Debug cell fixes * update execution count. * Expand/collapse cell should not rely on `activeNotebookEditor` * Format * Refactor add/debug code codepaths * Prettier Co-authored-by: rebornix <penn.lv@gmail.com> Co-authored-by: rebornix <penn.lv@gmail.com> * enble the debugging setting (#6492) * Port #6503 and #6504 to release (#6507) * Don't pass registrationData twice when registering notebook serializer (#6503) * If in Python daily insiders and VS Code Insiders opt into native interactive window (#6504) * If in Python daily insiders and VS Code Insiders opt into native interactive window * Oops * Remove unused import * Changelog * Format * debugging work (#6505) (#6558) * don't fetch breakpoints on activate * implement IDisposable on the debugging manager * pass on session id's * delete temp files * lint * add try catch * store sessionId * pass jupyter session id * Remove start page in favor of a message (#6576) * prepare release (#6590) * prepare * use same version in package.jpsn and changelog * leave version at 2021.8.0 * publish release * update package-lock Co-authored-by: Rich Chiodo <rchiodo@users.noreply.github.com> Co-authored-by: Joyce Er <joyceerhuiling@gmail.com> Co-authored-by: rebornix <penn.lv@gmail.com> Co-authored-by: Don Jayamanne <don.jayamanne@outlook.com>
For #6418, #6423, #6426, #6457
Debug Cell problem was because executeObservable has side effects (updating execution count) that the
notebook.cell.execute
codepath doesn't.Go to cell problem was because notebook cell metadata wasn't populated.
Cell markers were caused by interactive window editor taking focus when it shouldn't (required fix in core).
Collapse cell problem was because clicking on a toolbar button does not set focus to the interactive window, and the command handler relied on the
activeNotebookEditor
instead of using theinteractive/toolbar
context.Will be porting this PR to release branch.