@Saq First, again, I really appreciate your help. Even if you say we should just treat it as prototype, I think it is desirable that it at least works fairly OK - and it feels like it is close to doing that :-)
Okidok, tests done: > > - is the delay coming from the detection code or the display code? For > example for [[ just set the popup code to not run any filters and display > a > static message like "TitlePicker" and see if the delay is still there. If > its significantly reduced then we know the delay is mostly from display > code, and vice versa > > Tests definitely imply it's the detection code. No visible difference when popup runs or doesn't run filters. > > - For the detection code, see if swapping the list with the > item-filter to be the innermost one helps with performance. Simple cut and > paste. > > That did not show any discernible difference. > > - I am also unsure if we need this list anymore (after introducing > em-itemfilter): > <$list > > filter="[<em-fragment>length[]add<before-length>add<trigger-length>match<selectionEnd>]" > > variable="_NULL" emptyMessage=<<em-checkNextTrigger>>> > I recommend doing a side by side comparison with and without this in > some complex text with a lot of unclosed triggers, and see if the > behaviour > is identical. If it helps avoid even a few false matches it is worth > keeping as the filter it runs is a fast one. > > No discernible difference in a side by side. It is striking however, in all tests, how the detection is much slower for the first letters of the fragment than the later. (This is of course to be expected.) > I had a quick look at _Popup and TitlePicker. I think they look OK. One > potential issue with the vars we set up in _Popup is going to be that they > will force the entire popup to redraw itself from scratch on every > keystroke, rather than say a title list that just updates itself. Let's see > if the display code is causing any performance issues before deciding > whether that is worth adressing > Please elaborate. > In short: don't be in a hurry to have something "final" and publish it > [...] > Thank you for your calm and experienced words in process Saq. <:-) -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/ba3ba2f0-2d19-4482-8f98-3b296158f3d5o%40googlegroups.com.
