No, it ain't Cells4.
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.
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:
Supose have something like:
(make-kid 'ct-button
:enabled (c? (some #'non-empty (kids (fm-other :thing)))))
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.
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:
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.
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.
kt