Andre Poenitz wrote: >> ...but this has nothing to do with "editing slowdown"... > > But with e.g. buffer loading and buffer switching? [Not sure here, don't > have the sources at hand]
Probably, I agree. >> So: I may agree that its a reasonable change (I even remember proposing >> something along the lines last year), but I don't think we are solving >> any performance problem... > > So you claim that the only reason of the perceived cursor-right > performance problem is redrawing a single full screen full of 2-d data? > > I am not saying this is impossible, but I'd rather expect a larger part > of the problem in the 99 other pages the are not drawn yet touched in > update. 1) Just uncomment the code you have commented out in selHandle and try cursor right. There is at least one call to updateParPositions (called from fitCursor -> redoParagraph -> updateParPositions) for every movement. Compare with cvs. (I've used UserGuide4 which I think is quite larger than Kayvan's document) 2) updateParPositions is the lightest immaginable O(n) algorithm. If we are going to have O(n) in updateCounters and the macro stuff, it will be with a much larger constant... 3) what happened to the "O(n) per user interaction is ok" karma? I've never agreed completely, but I would expect at least to follow it yoursef :-P Alfredo
