When you create a new cell, it’s in the same state as a cell with no code in it (not counting comments and whitespace as code); we know the output will always be
undefined. We’d rather show new cells like this:
than like this:
We could special-case new cells as “not yet evaluated”, and have the
output appear when you first shift-return. But this doesn’t work with multiplayer editing because the new cell appears immediately (and is evaluated) upon creation on other editors’ windows, too.
We have a couple of related, competing improvements planned.
First, we’re considering deferring saving a new cell until you commit some code to it, rather than saving it (empty) immediately upon creation. This would avoid the problem of the empty cell with
undefined output appearing with multiplayer, and perhaps then we would only hide the cell output when a cell is not yet evaluated, not when it’s empty.
Second, we’d like to synchronize cell evaluations independently of edits so that we can synchronize and potentially save edits in realtime (per key stroke) with collaborative editing. This isn’t trivial because it will mean that the output of a cell can be “stale” (reflecting an older version of code), even when you aren’t the person who edited the code. We need to design that state carefully. And we’d then want the empty cell appearing immediately upon creation, so that we can see a remote editor typing into the new cell.
I hope it’s clear there are a lot of subtle considerations in play here.
If you don’t mind me asking, why do you want the error to “get out of the way”? Why is showing
undefined better than showing the error message? Are you essentially keeping track of which cells need fixing when something is broken, and using commenting to focus on one broken cell at a time? Something we could do, potentially, is to offer a “disabled” state for cells, where we don’t run the code. Then you wouldn’t have to comment out all the code to prevent it from running.