Bob Arning  <arning at charm.net> is claimed by the authorities to have written:

> IMO, what _should_ be handling it is PluggableListView>>update: where getListSelector matches #messageList. Either it did not get set as a dependent or it's just doing the wrong thing.
After spending some time tracing through, it's all set up ok for
dependents etc; the 'culprit' is in PluggableListView>list: where the
first thing done is to check to see if the incoming list of items is
that same object as the currently cached list of items. For _any_
application where the list is being added to etc this is a complete
failure case - you add something (or remove something, or replace
something) and the list Paragraph will not be updated. So either the
'optimisation' needs to do something nearer to checking the incoming
list against the list in the Paragraph, or it needs to become a well
known invariant that the collection must not be cached by the
application. Or something else.


Unfortunately if you comment out this 'optimisation' you get the
multiple updates  tango as well as some odd cases where the list
background goes white. (hmm, odd thing here later while checking
something, it doesn't seem to happen now. )

Oh, and there are some very odd things that happen to the tracing
browser where it appears that the  MessageSet's methodListIndex is ok at
the beginning of TracingMessageBrowser>
addChildMessages:autoSelectString: but 0 by the second 'sentence'. Which
causes another whole chain of debugger fun that I don't have timeto play
with right now.

The signature on the #list:  methods is Dan's dating from last june or
so.

tim 
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: BPB: Branch on Program Bug