@Mat
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 :-)
>
Naturally, The point about treating it as a prototype is that you can make
large changes, try things and if they don't work as anticipated, try
something else. Part of the question mark over this entire effort has been:
how much can you get done with wikitext? The performance issues are a part
of the answer.
>
> Tests definitely imply it's the detection code. No visible difference when
> popup runs or doesn't run filters.
>
One possibility here is for the filter used in the detection code not to be
the same as used in the popup tools. That actually never was my intention.
The filter for titlepicker has to match the fragment against every tiddler
in the wiki, that is expensive.
How about a filter that that just detects whether the fragment for
titlepicker has disallowed characters?
Or we just live the performance issues.
Naturally its far from ideal that the filter for title picker runs 3 times:
- once in detection
- twice in popup
Note that I refer to title picker as an example
>
>> - 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.
>
If you are sure about this, we can remove this list and the variables that
are there just for its sake.
> 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.
>
<$vars foo={{{ [{!!foo}] }}}>
content
</$vars>
If the value of "foo" in the vars widget changes, the entire widget is
destroyed and re-created, which means so is everything inside it.
If however you do something like the following, the list updates itself
instead of re-drawing from scratch. This is much faster:
<$list filter=[prefix{!!fo}]>
content
</$list>
--
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/a346262f-e620-4174-ab69-e242aced334co%40googlegroups.com.
