Change:
templateDisposables.add(scopedInstaService.createInstance(RunToolbar, this.notebookEditor, contextKeyService, container, runButtonContainer)), templateDisposables.add(new CellDecorations(rootContainer, decorationContainer)), templateDisposables.add(scopedInstaService.createInstance(CellComments, this.notebookEditor, cellCommentPartContainer)), <del> templateDisposables.add(new CellExecutionPart(this.notebookEditor, executionOrderLabel)), </del> <ins> templateDisposables.add(scopedInstaService.createInstance(CellExecutionPart, this.notebookEditor, executionOrderLabel)), </ins> templateDisposables.add(scopedInstaService.createInstance(CollapsedCellOutput, this.notebookEditor, cellOutputCollapsedContainer)), templateDisposables.add(new CollapsedCellInput(this.notebookEditor, cellInputCollapsedContainer)), templateDisposables.add(new CellFocusPart(container, focusSinkElement, this.notebookEditor)),

Discussion:
Testing A lot of flickering goes on when executing a cell, can the number in [] not get its text cleared and instead go from [5] to [6] for example to minimize flickering? !
We clear the execution order when execution starts, and jupyter itself does not provide the new execution order until slightly after execution starts. All I can think of is doing something on the rendering side, like wait a bit to render a cleared execution order?
``
Found it annoying while testing Not that in the video, I was dragging an ipywidgets slider, which somehow is updating execution status. Though it didn't really increment the execution count, it kept flickering. https://user- It's also annoying to see the spinner. Bump it to July as I found this UX a bit unpleasant.
I wonder if that is related to creating a fake execution to update an output. Should be possible to do that atomically but I can check
To summarize since this goes on the plan, two related issues: Blinking when doing normal execution due to updating the execution count async Blinking and showing running state when updating outputs with the "fake" execution object. I'm not sure what we will be able to do about the running state - we even have code that specifically ensures that if the cell enters the running state, it should show the running indicator for some minimum amount of time
So far I have Fixed an issue with the extension using temp executions unnecessarily, so for the original report it doesn't blink anymore Fixed some unnecessary blinking for normal executions However, it's hard to avoid this for actual fake executions, because since this is a workaround for our API, it's not really clear how to detect this and treat them differently. We've said that we want an execution to show the progress spinner for a minimum time, 500ms, so that you can definitely tell in the UI that an execution happened, even if it is very fast. So then even if an execution is created and completed within the same js task, we will still show the progress spinner. This is good for fast normal executions and not good for "fake" executions. We could say that an execution that is completed immediately does not get the spinner at all, but I don't like that because it could hurt some simple kernel that doesn't need to do any async work as part of an execution. So I'm very open to ideas on how to improve this.

For future reference, here is a snippet that does a "fake" execution to update outputs outside of an execution.
Interesting, I hadn't realize this - in the snippet above in vscode adds outputs to the cell. In Jupyter lab, it actually writes to a different log instead of adding outputs to the cell. To understand this usecase I'm looking for an example that updates the output in jupyter lab outside of an execution - I remember there was one which I think involved subprocess, but I can't find an example anywhere. Wondering whether you have one handy
Verification steps: No flickering of the execution order or timer in a normal execution of a cell in a Jupyter notebook No flickering when changing the slider with this code:Some other ipywidget scenarios will still produce flickering from "fake executions", this is probably not solvable without API changes. Discovered that it's actually not working as expected in some other cases and so it could get more investigation later.
Verified