Armel Asselin:
if it can be 'automatic' and could profit any situation I may well go on and use something similar to the PhysicalLayout.
It should be automatic and help many workloads.
> However, I don't expect maintaining ContractionState to be > expensive enough to add an extra feature, mostly because of the > maintenance cost. uh, I do not understand this sentence. If I implement ConstractionState as PhysicalLayout in SinkWorld would you be happy to put it Scintilla or on the contrary you consider ContractionState is good enough and doing that is just over the top. Or this is the "defer until last command" which you do not like?
I don't like "defer until last command" unless it really is needed. If it is needed, then its scope should be minimized, so if ContractionState can be made efficient enough then it should remain updated rather than deferred. However, there may still be a need to defer at another level. Something based on PhysicalLayout would be a good implementation of ContractionState but MaxFinder and widths should be dropped from PhysicalLayout since the scroll width feature doesn't work. Scintilla's implementations of SplitVector and Partitioning should be used in preference to SinkWorld's as these have been in real world use. Neil _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
