On Thu, Aug 18, 2022 at 09:55:50AM +0200, Jürgen Spitzmüller wrote: > showMessage() is triggered on any cursor action. That's way too often. > E.g., it would fire down statistics unnecessarily if you move with the > arrow keys through your document.
I'll add just few observational notes collected few weeks back when I was looking into the issue. 1) On the trigger. The nice part of Daniel's patch was that it did not trigger statistics recount at *every* cursor action, most importantly the update did not happen when you start moving with cursor (and hold) but only when you release the movement key. So no update firestorm in such case. If you just move with the cursor slowly via hit&release on the keyboard the stat recount was not noticeable in my behavioral measurements. I agree it's not conceptually cleanest to pin it to showMessage. OTOH when I tried to look whether we have some natural point of entry in the code where to trigger the update I was not particularly succesfull. Unless the showMessage trick was used it seemed many different place needed touch and most problematic was how to make sure I did not forget about some route how buffer changes. Or prevent future implementation miss (but you might say the same about showMessage, or even worse because no strict policy about its call is in place). 2) On the update execution. If you go by multi-threading route, you enter swampland. The only crash free solution would be to clone the whole buffer and do counting on it, but that does not make sense performace wise, because clone takes asymptotically the same as stats themselves. Otherwise you need to avoid buffer changes while counting stats. Getting this right seemed like recipy for headache and chasing out-of-nowhere crashes - be it from my own overlooking or subtleties/bugs of underlying libraries. So while initially I saw QTimer attachment to the same thread as a drawback, on a second thought we'll get rid of race condition headaches. If we can get the trigger right this should be good enough. I do not have strong opinion about the final solution, just voicing my thoughts when I was playing with the code... Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
