Repository navigation
Refresh the cells below a run, and notice runs the VS Code webview never renders - #131
Merged
TorreyBetts merged 3 commits intoOct 25, 2026
Conversation
Jonathan-Schaefer-git
force-pushed
the
refresh-cells-after-run
branch
from
October 20, 2026 15:57
dc15158 to
e0150e6
Compare
Contributor
Author
|
|
…ver renders After a run the editor asked the kernel again for the diagnostics of the cell that ran, and of no other. A run changes what the cells after it can refer to, so a cell below kept the errors it had before, a name the run had just defined still marked as unknown, until the user clicked into it. Now the cell that ran and every cell below it are asked again, top to bottom and one at a time, so the cells nearest the run update first and a run started in the meantime waits behind at most one request. A cell whose answer still holds is skipped, and nothing is asked while a cell runs. Cells above the run are asked on their next focus, as before. In the VS Code webview not even the cell that ran was refreshed. A cell noticed its run end by seeing IsExecuting turn false, but the host's executing and executed notifications for a quick cell are both handled before the next render, so the cell was never rendered as executing. A cell now also counts a moved execution count as the end of a run. A count cleared by a restart does not count, so a restart still clears the markers without asking again. Signed-off-by: Jonathan Schäfer <jonathan.schaefer.mail@gmail.com>
… out On the CI runners the note past a cell's line limit has taken many seconds to appear after the editors are measured, and twice not within the 10 seconds the test allowed. The editors themselves are given 60, so the note is given the same. Signed-off-by: Jonathan Schäfer <jonathan.schaefer.mail@gmail.com>
Jonathan-Schaefer-git
force-pushed
the
refresh-cells-after-run
branch
from
October 21, 2026 07:52
d15db52 to
90e145d
Compare
TorreyBetts
reviewed
Oct 23, 2026
| }); | ||
| } | ||
|
|
||
| function queueRefreshAfterRun(elementId) { |
Contributor
There was a problem hiding this comment.
Thanks for this, the execution count fix for the VS Code webview looks good.
One thing on the walk: a run marks every editor stale, so every cell below gets a full kernel check, one at a time. In a long F# or C# notebook that's a lot of background work after each run. Could you limit it to the cell that ran plus the cells below that are currently showing markers? The rest would still pick up changes on their next focus.
Contributor
Author
There was a problem hiding this comment.
Yes. The new commit incorporates this, so that only the running cell and those below that already show kernel markers will get asked again. The rest only on focus of the corresponding cell
A run ended by asking again for the cell that ran and for every cell below it. For C# and F# each request is a full compilation, so in a long notebook every run was followed by one per cell below, one at a time. Now the cells below are asked only while they are showing kernel markers, which are the ones a run can visibly fix, such as a name the run has just defined. The other cells below pick up a change on their next focus, as the cells above already did. Signed-off-by: Jonathan Schäfer <jonathan.schaefer.mail@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #130
A run changes what the cells after it can refer to, but afterwards the editor asked the kernel again only for the diagnostics of the cell that ran. A cell below kept its markers, so a name the run had just defined stayed marked as unknown until the cell was clicked into. In the VS Code webview not even the cell that ran was refreshed.
Every cell from the run down is refreshed. After a run, the cell that ran and every cell below it are asked again, top to bottom and one at a time. The cells nearest the run update first, and a run started in the meantime waits behind at most one request, since Verso.Host answers one at a time. A cell whose answer still holds for its text and kernel state is skipped. Nothing is asked while a cell runs; the walk resumes when the run is over. Cells above the run are asked on their next focus, as before.
A moved execution count also ends a run. Cell.razor noticed a run end only when IsExecuting turned false. In the webview, the executing and executed notifications for a quick cell are both handled before the next render, so the cell was never rendered as executing. A count cleared by a restart doesn’t count, so a restart still clears the editor markers without asking again.
The entry point is renamed for what it does. The editor’s after-run entry point is now versoMonaco.refreshAfterRun (MonacoEditor.RefreshAfterRunAsync).