No, it ain't Cells4.<br><br>One is a bug fix to ruled-then-input cells:  "ensure current" used to be satisfied by a cell being flagged as input. Of course a ruled-then-input will not be valid initially, so the test is now that something is c-validp as well as inputp. 
<br><br>The more exciting change (no, i did not run the Cells regression test, but my hairy application seems to work) is one I have seen coming for a while:<br><br>Supose have something like:<br><br>    (make-kid 'ct-button
<br>         :enabled (c? (some #'non-empty (kids (fm-other :thing)))))<br><br>This button is part of a fixed application GUI and it keeps an eye on the kids of :thing. Now thing happens to be a component inside a little workspace, and other user controls allow them to switch the target being worked on in the workspace. A change to the target pretty much rebuilds the entire contents of the little workspace pane, including making a new widget with the name :thing.
<br><br>Well, this used to work without skulduggery because fm-other used to record dependencies everywhere it went in searching for :thing. Maybe that is something I should reinstate (I just realized). Anyway, the fix I came up with today seems Deeply Sensible, so let's see how it pans out:
<br><br>If :thing itself goes away (going back to the above example) at some point c-quiesce will disconnect the kids cell as a dependency of the button enabled cell. The fix is to flag any caller (dependent, such as enabled) as ":uncurrent", a new state between :unevaluated and :valid. I don't like dirty words or variable names, cll notwithstanding. And dirty is vague where uncurrent says what it means and means what it says.
<br><br>What we are saying is that a dependency on cell X of instance Y implies a dependency on the existence of Y. That just seems like a very safe thing to say, so let's see if this works as well as a kazillion kids dependency that would arise from a dependent modelspace search.
<br><br>kt<br><br>