Hi Mat,
The itemfilter stuff works. There is a noticeable delay which I estimate to
> be proportional to the number of items i.e the list of items is much longer
> for [[ than for << or <$ ... or perhaps more correctly expressed, it's
> probably proportional to the complexity of the itemfilter.
>
Right, there is definitely room for optimization here. I can try to
investigate but this week is very busy on my end. Also, I have new desktop
machines at home and the office since January and in a strange but annoying
twist, they are so powerful that I can't perceive some of the performance
issues that others experience.
A few things for you to consider/try.
- 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
- 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.
\define em-checkTrigger()
<$vars
template={{!!title}}
trigger={{!!em-trigger}}
trigger-end={{!!em-triggerend}}
triggexp={{{ [{!!em-trigger}escaperegexp[]] }}}
triggendexp={{{
[enlist{!!em-triggerend}escaperegexp[]join[|]addprefix[(]addsuffix[)+]split[\/]join[/]trim[]]
}}}
before={{{ [<text>splitbefore{!!em-trigger}] }}}
before-length={{{ [<text>splitbefore{!!em-trigger}length[]] }}}
trigger-length={{{[{!!em-trigger}length[]]}}}
em-itemfilter = {{!!em-itemfilter}}
>
<$action-log $message=<<template>>/>
<$list filter="""[<text>search<trigger>] +[splitregexp<triggexp>]
+[!prefix[ ]!search::regexp<triggendexp>] +[last[]]"""
emptyMessage=<<em-checkNextTrigger>> variable="em-fragment">
<$vars
before-length={{{[<text>splitregexp<triggexp>butlast[]join<trigger>length[]]}}}>
<$action-log $message={{{[[detected: ]addsuffix<template>]}}}/>
<$list
filter="[<em-fragment>length[]add<before-length>add<trigger-length>match<selectionEnd>]"
variable="_NULL" emptyMessage=<<em-checkNextTrigger>>>
<$list filter="[<em-fragment>length[]compare:number:lt<fragmentLength>]"
variable="_NULL" emptyMessage=<<em-checkNextTrigger>>>
<$list filter="[<template>!has[em-itemfilter]] ~[subfilter<em-itemfilter>]"
variable="_NULL" emptyMessage=<<em-checkNextTrigger>>>
<$vars matched="true" fragmentLength={{{[<em-fragment>length[]]}}}
matchedFragment=<<em-fragment>> matchedTemplate=<<template>> >
<<em-checkNextTrigger>>
</$vars>
</$list>
</$list>
</$list>
</$vars>
</$list>
</$vars>
\end
- 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.
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 addressing.
I would also add that it is best to think of this entire dev process as a
proof of concept or prototype. The aim is to understand what kind of code
structure works best, what the potential issues are and what the best user
experience is. If it needs a rewrite later to get it right or fix
performance issues, that is a part of the process.
In short: don't be in a hurry to have something "final" and publish it. Dev
work this extensive and complex with wikitext is a bit harder to plan in
advance and get right (compared to working with established programming
languages).
Cheers,
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/0fe75334-b7f3-4649-a0ac-0020644bdaaao%40googlegroups.com.
