Re: [tw5] Re: Typing lag in <$edit-text/> widget

[Hubert]

Hi Jeremy,

That's fantastic, thank you! I really appreciate having this addition.

Many thanks for your support & the great work!

Best regards,
Hubert


On Monday, 14 October 2019 15:08:14 UTC+1, Jeremy Ruston wrote:
>
> Hi Hubert
>
> I've added support for v5.1.22 for the presence of a field called 
> "throttle.refresh" triggering the same throttling process as for draft 
> tiddlers. You can try it out here:
>
> https://tiddlywiki.com/prerelease#RefreshThrottling
>
> Best wishes
>
> Jeremy.
>
> --
> Jeremy Ruston
> jer...@jermolene.com 
> https://jermolene.com
>
> On 11 Oct 2019, at 14:44, Hubert > wrote:
>
> 
> Just to add, sliders created using the <$range/> widget are now also 
> smooth as butter, as long as the tiddler being updated is an unsaved draft, 
> eg:
>
> <$range tiddler="Draft of 'edit-range'" min=0 max=10 default=5 
> increment=0.5/>
>
> I've tested this on desktop and mobile. Even on desktop, removing the few 
> seemingly imperceptible miliseconds of choppiness made a huge difference. 
> This seems to make it clear that the benefits of delayed refresh go so much 
> farther and are not limited to smooth typing experience alone.
>
> Regards,
> Hubert
>
> On Friday, 11 October 2019 11:51:25 UTC+1, Hubert wrote:
>>
>> Hi Jeremy,
>>
>> Thank you for taking the time to respond, I appreciate it.
>>
>> We could add an additional field that we check for along with the 
>>> “draft.of” field, such as “refresh.slow” as suggested in the thread above. 
>>> I don’t think that’s going to be particularly convenient in lots of 
>>> situations (e.g. ensuring that $:/temp/search gets that field). Another 
>>> possibility might be to use a special prefix e.g. $:/dampened/ or perhaps 
>>> $:/volatile/.
>>>
>>
>> I would be happy with either solution so long as such a non-draft tiddler 
>> is excluded from instant refreshes. Perhaps a tiddler having a field 
>> refresh.slow could be referenced in $:/temp/search in italics (similar to 
>> how shadow tiddlers are in bold)?
>>
>> May I ask whether this is something that could be considered for the next 
>> release?
>>
>> I’m not sure what you mean here. Are you talking about the draft tiddler 
>>> notification at the bottom of the screen?
>>>
>>
>> Yes, that's exactly it. I've found it's defined in 
>> $:/core/ui/PageTemplate/drafts and have already overwritten it accordingly, 
>> removing only the single "Draft of..." tiddler I'm editing using 
>> <$edit-text/> widget in another tiddler.
>>
>> I may have missed something in the thread earlier, but you can keep a 
>>> perpetual draft by not opening it directly, instead editing it via an 
>>> edit-text widget from another tiddler.
>>>
>>
>> This is exactly the approach I'm taking now, but I failed to express it 
>> as concisely.
>>
>> Best regards,
>> Hubert
>>
>>
>>
>>
>> On Friday, 11 October 2019 11:25:09 UTC+1, Jeremy Ruston wrote:
>>>
>>> Hi Hubert,
>>>
>>> Thank you for finding this thread from 2015:
>>>
>>> https://groups.google.com/d/topic/tiddlywiki/hlIvXE6jRys/discussion
>>>
>>> As you note, I think we are still in the same place: on lower powered 
>>> devices, it would be useful to be able to extend the refresh dampening 
>>> mechanism to selectively apply to tiddlers that are not drafts.
>>>
>>> The code that checks for tiddlers that should be included in refresh 
>>> dampening looks for the presence of the “draft.of” field:
>>>
>>>
>>> https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/startup/render.js#L82-L88
>>>
>>> We can change that logic, but we need to keep it simple because it will 
>>> be executed every time any tiddler is modified. So, for example, using a 
>>> filter would be ruled out.
>>>
>>> We could add an additional field that we check for along with the 
>>> “draft.of” field, such as “refresh.slow” as suggested in the thread above. 
>>> I don’t think that’s going to be particularly convenient in lots of 
>>> situations (e.g. ensuring that $:/temp/search gets that field). Another 
>>> possibility might be to use a special prefix e.g. $:/dampened/ or perhaps 
>>> $:/volatile/.
>>>
>>> You asked
>>>
>>> Now I have to figure out how I can prevent this open text tiddler from 
>>> being constantly referenced in a red notification rectangle
>>>
>>>
>>> I’m not sure what you mean here. Are you talking about the draft tiddler 
>>> notification at the bottom of the screen?
>>>
>>>
>>> and to prevent TW from saving it, because once it exits editing mode the 
>>> lag is reintroduced.
>>>
>>>
>>> I may have missed something in the thread earlier, but you can keep a 
>>> perpetual draft by not opening it directly, instead editing it via an 
>>> edit-text widget from another tiddler.
>>>
>>> Best wishes
>>>
>>> Jeremy
>>>
>>>
>>>
>>>
>>> Regards,
>>> Hubert
>>>
>>>
>>>
>>> On Friday, 11 October 2019 09:09:34 UTC+1, Hubert wrote:

 Hi Mark,

 My TW now has 63k entries, and, in a meeting the other day,I was able 
> to look up entries about as fast as people asked.
>

Re: [tw5] Re: Typing lag in <$edit-text/> widget

[Jeremy Ruston]

Hi Hubert

I've added support for v5.1.22 for the presence of a field called 
"throttle.refresh" triggering the same throttling process as for draft 
tiddlers. You can try it out here:

https://tiddlywiki.com/prerelease#RefreshThrottling

Best wishes

Jeremy.

--
Jeremy Ruston
jer...@jermolene.com
https://jermolene.com

> On 11 Oct 2019, at 14:44, Hubert  wrote:
> 
> 
> Just to add, sliders created using the <$range/> widget are now also smooth 
> as butter, as long as the tiddler being updated is an unsaved draft, eg:
> 
> <$range tiddler="Draft of 'edit-range'" min=0 max=10 default=5 increment=0.5/>
> 
> I've tested this on desktop and mobile. Even on desktop, removing the few 
> seemingly imperceptible miliseconds of choppiness made a huge difference. 
> This seems to make it clear that the benefits of delayed refresh go so much 
> farther and are not limited to smooth typing experience alone.
> 
> Regards,
> Hubert
> 
>> On Friday, 11 October 2019 11:51:25 UTC+1, Hubert wrote:
>> Hi Jeremy,
>> 
>> Thank you for taking the time to respond, I appreciate it.
>> 
>>> We could add an additional field that we check for along with the 
>>> “draft.of” field, such as “refresh.slow” as suggested in the thread above. 
>>> I don’t think that’s going to be particularly convenient in lots of 
>>> situations (e.g. ensuring that $:/temp/search gets that field). Another 
>>> possibility might be to use a special prefix e.g. $:/dampened/ or perhaps 
>>> $:/volatile/.
>> 
>> I would be happy with either solution so long as such a non-draft tiddler is 
>> excluded from instant refreshes. Perhaps a tiddler having a field 
>> refresh.slow could be referenced in $:/temp/search in italics (similar to 
>> how shadow tiddlers are in bold)?
>> 
>> May I ask whether this is something that could be considered for the next 
>> release?
>> 
>>> I’m not sure what you mean here. Are you talking about the draft tiddler 
>>> notification at the bottom of the screen?
>> 
>> Yes, that's exactly it. I've found it's defined in 
>> $:/core/ui/PageTemplate/drafts and have already overwritten it accordingly, 
>> removing only the single "Draft of..." tiddler I'm editing using 
>> <$edit-text/> widget in another tiddler.
>> 
>>> I may have missed something in the thread earlier, but you can keep a 
>>> perpetual draft by not opening it directly, instead editing it via an 
>>> edit-text widget from another tiddler.
>> 
>> This is exactly the approach I'm taking now, but I failed to express it as 
>> concisely.
>> 
>> Best regards,
>> Hubert
>> 
>> 
>> 
>> 
>>> On Friday, 11 October 2019 11:25:09 UTC+1, Jeremy Ruston wrote:
>>> Hi Hubert,
>>> 
>>> Thank you for finding this thread from 2015:
>>> 
>>> https://groups.google.com/d/topic/tiddlywiki/hlIvXE6jRys/discussion
>>> 
>>> As you note, I think we are still in the same place: on lower powered 
>>> devices, it would be useful to be able to extend the refresh dampening 
>>> mechanism to selectively apply to tiddlers that are not drafts.
>>> 
>>> The code that checks for tiddlers that should be included in refresh 
>>> dampening looks for the presence of the “draft.of” field:
>>> 
>>> https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/startup/render.js#L82-L88
>>> 
>>> We can change that logic, but we need to keep it simple because it will be 
>>> executed every time any tiddler is modified. So, for example, using a 
>>> filter would be ruled out.
>>> 
>>> We could add an additional field that we check for along with the 
>>> “draft.of” field, such as “refresh.slow” as suggested in the thread above. 
>>> I don’t think that’s going to be particularly convenient in lots of 
>>> situations (e.g. ensuring that $:/temp/search gets that field). Another 
>>> possibility might be to use a special prefix e.g. $:/dampened/ or perhaps 
>>> $:/volatile/.
>>> 
>>> You asked
>>> 
 Now I have to figure out how I can prevent this open text tiddler from 
 being constantly referenced in a red notification rectangle
>>> 
>>> I’m not sure what you mean here. Are you talking about the draft tiddler 
>>> notification at the bottom of the screen?
>>> 
>>> 
>>> 
 and to prevent TW from saving it, because once it exits editing mode the 
 lag is reintroduced.
>>> 
>>> I may have missed something in the thread earlier, but you can keep a 
>>> perpetual draft by not opening it directly, instead editing it via an 
>>> edit-text widget from another tiddler.
>>> 
>>> Best wishes
>>> 
>>> Jeremy
>>> 
>>> 
>>> 
 
 Regards,
 Hubert
 
 
 
> On Friday, 11 October 2019 09:09:34 UTC+1, Hubert wrote:
> Hi Mark,
> 
>> My TW now has 63k entries, and, in a meeting the other day,I was able to 
>> look up entries about as fast as people asked.
> 
> That's impressive. Did you use a search bar or your own  
> widget? I'm particularly interested if it was the latter.
> 
>> But that was using a Kindle Fire, which might have a stronger processor
>

Re: [tw5] Re: Typing lag in <$edit-text/> widget

[Hubert]

Just to add, sliders created using the <$range/> widget are now also smooth 
as butter, as long as the tiddler being updated is an unsaved draft, eg:

<$range tiddler="Draft of 'edit-range'" min=0 max=10 default=5 
increment=0.5/>

I've tested this on desktop and mobile. Even on desktop, removing the few 
seemingly imperceptible miliseconds of choppiness made a huge difference. 
This seems to make it clear that the benefits of delayed refresh go so much 
farther and are not limited to smooth typing experience alone.

Regards,
Hubert

On Friday, 11 October 2019 11:51:25 UTC+1, Hubert wrote:
>
> Hi Jeremy,
>
> Thank you for taking the time to respond, I appreciate it.
>
> We could add an additional field that we check for along with the 
>> “draft.of” field, such as “refresh.slow” as suggested in the thread above. 
>> I don’t think that’s going to be particularly convenient in lots of 
>> situations (e.g. ensuring that $:/temp/search gets that field). Another 
>> possibility might be to use a special prefix e.g. $:/dampened/ or perhaps 
>> $:/volatile/.
>>
>
> I would be happy with either solution so long as such a non-draft tiddler 
> is excluded from instant refreshes. Perhaps a tiddler having a field 
> refresh.slow could be referenced in $:/temp/search in italics (similar to 
> how shadow tiddlers are in bold)?
>
> May I ask whether this is something that could be considered for the next 
> release?
>
> I’m not sure what you mean here. Are you talking about the draft tiddler 
>> notification at the bottom of the screen?
>>
>
> Yes, that's exactly it. I've found it's defined in 
> $:/core/ui/PageTemplate/drafts and have already overwritten it accordingly, 
> removing only the single "Draft of..." tiddler I'm editing using 
> <$edit-text/> widget in another tiddler.
>
> I may have missed something in the thread earlier, but you can keep a 
>> perpetual draft by not opening it directly, instead editing it via an 
>> edit-text widget from another tiddler.
>>
>
> This is exactly the approach I'm taking now, but I failed to express it as 
> concisely.
>
> Best regards,
> Hubert
>
>
>
>
> On Friday, 11 October 2019 11:25:09 UTC+1, Jeremy Ruston wrote:
>>
>> Hi Hubert,
>>
>> Thank you for finding this thread from 2015:
>>
>> https://groups.google.com/d/topic/tiddlywiki/hlIvXE6jRys/discussion
>>
>> As you note, I think we are still in the same place: on lower powered 
>> devices, it would be useful to be able to extend the refresh dampening 
>> mechanism to selectively apply to tiddlers that are not drafts.
>>
>> The code that checks for tiddlers that should be included in refresh 
>> dampening looks for the presence of the “draft.of” field:
>>
>>
>> https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/startup/render.js#L82-L88
>>
>> We can change that logic, but we need to keep it simple because it will 
>> be executed every time any tiddler is modified. So, for example, using a 
>> filter would be ruled out.
>>
>> We could add an additional field that we check for along with the 
>> “draft.of” field, such as “refresh.slow” as suggested in the thread above. 
>> I don’t think that’s going to be particularly convenient in lots of 
>> situations (e.g. ensuring that $:/temp/search gets that field). Another 
>> possibility might be to use a special prefix e.g. $:/dampened/ or perhaps 
>> $:/volatile/.
>>
>> You asked
>>
>> Now I have to figure out how I can prevent this open text tiddler from 
>> being constantly referenced in a red notification rectangle
>>
>>
>> I’m not sure what you mean here. Are you talking about the draft tiddler 
>> notification at the bottom of the screen?
>>
>>
>> and to prevent TW from saving it, because once it exits editing mode the 
>> lag is reintroduced.
>>
>>
>> I may have missed something in the thread earlier, but you can keep a 
>> perpetual draft by not opening it directly, instead editing it via an 
>> edit-text widget from another tiddler.
>>
>> Best wishes
>>
>> Jeremy
>>
>>
>>
>>
>> Regards,
>> Hubert
>>
>>
>>
>> On Friday, 11 October 2019 09:09:34 UTC+1, Hubert wrote:
>>>
>>> Hi Mark,
>>>
>>> My TW now has 63k entries, and, in a meeting the other day,I was able to 
 look up entries about as fast as people asked.

>>>
>>> That's impressive. Did you use a search bar or your own  
>>> widget? I'm particularly interested if it was the latter.
>>>
>>> But that was using a Kindle Fire, which might have a stronger processor
 than a motorola phone.

 I don't believe you've mentioned what browser you're using. My tests 
 were on an old version of FF that I'm not upgrading because it
 can still use TiddlyFox.

 It might be worth experimenting with different browsers. I believe 
 browser makers have wide latitude in how they implement JS internals.

>>>
>>> I'm now at a Windows PC with i7 processor, 8 gigs of RAM and running 
>>> latest FF. The lag is still there, albeit of course not that annoying as on 
>>> mobile. Same issue on

Re: [tw5] Re: Typing lag in <$edit-text/> widget

[Hubert]

Hi Jeremy,

Thank you for taking the time to respond, I appreciate it.

We could add an additional field that we check for along with the 
> “draft.of” field, such as “refresh.slow” as suggested in the thread above. 
> I don’t think that’s going to be particularly convenient in lots of 
> situations (e.g. ensuring that $:/temp/search gets that field). Another 
> possibility might be to use a special prefix e.g. $:/dampened/ or perhaps 
> $:/volatile/.
>

I would be happy with either solution so long as such a non-draft tiddler 
is excluded from instant refreshes. Perhaps a tiddler having a field 
refresh.slow could be referenced in $:/temp/search in italics (similar to 
how shadow tiddlers are in bold)?

May I ask whether this is something that could be considered for the next 
release?

I’m not sure what you mean here. Are you talking about the draft tiddler 
> notification at the bottom of the screen?
>

Yes, that's exactly it. I've found it's defined in 
$:/core/ui/PageTemplate/drafts and have already overwritten it accordingly, 
removing only the single "Draft of..." tiddler I'm editing using 
<$edit-text/> widget in another tiddler.

I may have missed something in the thread earlier, but you can keep a 
> perpetual draft by not opening it directly, instead editing it via an 
> edit-text widget from another tiddler.
>

This is exactly the approach I'm taking now, but I failed to express it as 
concisely.

Best regards,
Hubert




On Friday, 11 October 2019 11:25:09 UTC+1, Jeremy Ruston wrote:
>
> Hi Hubert,
>
> Thank you for finding this thread from 2015:
>
> https://groups.google.com/d/topic/tiddlywiki/hlIvXE6jRys/discussion
>
> As you note, I think we are still in the same place: on lower powered 
> devices, it would be useful to be able to extend the refresh dampening 
> mechanism to selectively apply to tiddlers that are not drafts.
>
> The code that checks for tiddlers that should be included in refresh 
> dampening looks for the presence of the “draft.of” field:
>
>
> https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/startup/render.js#L82-L88
>
> We can change that logic, but we need to keep it simple because it will be 
> executed every time any tiddler is modified. So, for example, using a 
> filter would be ruled out.
>
> We could add an additional field that we check for along with the 
> “draft.of” field, such as “refresh.slow” as suggested in the thread above. 
> I don’t think that’s going to be particularly convenient in lots of 
> situations (e.g. ensuring that $:/temp/search gets that field). Another 
> possibility might be to use a special prefix e.g. $:/dampened/ or perhaps 
> $:/volatile/.
>
> You asked
>
> Now I have to figure out how I can prevent this open text tiddler from 
> being constantly referenced in a red notification rectangle
>
>
> I’m not sure what you mean here. Are you talking about the draft tiddler 
> notification at the bottom of the screen?
>
>
> and to prevent TW from saving it, because once it exits editing mode the 
> lag is reintroduced.
>
>
> I may have missed something in the thread earlier, but you can keep a 
> perpetual draft by not opening it directly, instead editing it via an 
> edit-text widget from another tiddler.
>
> Best wishes
>
> Jeremy
>
>
>
>
> Regards,
> Hubert
>
>
>
> On Friday, 11 October 2019 09:09:34 UTC+1, Hubert wrote:
>>
>> Hi Mark,
>>
>> My TW now has 63k entries, and, in a meeting the other day,I was able to 
>>> look up entries about as fast as people asked.
>>>
>>
>> That's impressive. Did you use a search bar or your own  
>> widget? I'm particularly interested if it was the latter.
>>
>> But that was using a Kindle Fire, which might have a stronger processor
>>> than a motorola phone.
>>>
>>> I don't believe you've mentioned what browser you're using. My tests 
>>> were on an old version of FF that I'm not upgrading because it
>>> can still use TiddlyFox.
>>>
>>> It might be worth experimenting with different browsers. I believe 
>>> browser makers have wide latitude in how they implement JS internals.
>>>
>>
>> I'm now at a Windows PC with i7 processor, 8 gigs of RAM and running 
>> latest FF. The lag is still there, albeit of course not that annoying as on 
>> mobile. Same issue on Chrome.
>>
>>
>> On Thursday, 10 October 2019 16:29:56 UTC+1, Mark S. wrote:
>>>
>>> In my case, I kept the tags but removed all usage of the tag filter 
>>> operator. My TW now has 63k entries, and, in a meeting the other day,
>>> I was able to look up entries about as fast as people asked. But that 
>>> was using a Kindle Fire, which might have a stronger processor
>>> than a motorola phone.
>>>
>>> I don't believe you've mentioned what browser you're using. My tests 
>>> were on an old version of FF that I'm not upgrading because it
>>> can still use TiddlyFox.
>>>
>>> It might be worth experimenting with different browsers. I believe 
>>> browser makers have wide latitude in how they implement JS internals.
>>>
>>> Good luck!
>>>
>

Re: [tw5] Re: Typing lag in <$edit-text/> widget

[Jeremy Ruston]

Hi Hubert,

Thank you for finding this thread from 2015:

https://groups.google.com/d/topic/tiddlywiki/hlIvXE6jRys/discussion

As you note, I think we are still in the same place: on lower powered devices, 
it would be useful to be able to extend the refresh dampening mechanism to 
selectively apply to tiddlers that are not drafts.

The code that checks for tiddlers that should be included in refresh dampening 
looks for the presence of the “draft.of” field:

https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/startup/render.js#L82-L88
 


We can change that logic, but we need to keep it simple because it will be 
executed every time any tiddler is modified. So, for example, using a filter 
would be ruled out.

We could add an additional field that we check for along with the “draft.of” 
field, such as “refresh.slow” as suggested in the thread above. I don’t think 
that’s going to be particularly convenient in lots of situations (e.g. ensuring 
that $:/temp/search gets that field). Another possibility might be to use a 
special prefix e.g. $:/dampened/ or perhaps $:/volatile/.

You asked

> Now I have to figure out how I can prevent this open text tiddler from being 
> constantly referenced in a red notification rectangle

I’m not sure what you mean here. Are you talking about the draft tiddler 
notification at the bottom of the screen?


> and to prevent TW from saving it, because once it exits editing mode the lag 
> is reintroduced.

I may have missed something in the thread earlier, but you can keep a perpetual 
draft by not opening it directly, instead editing it via an edit-text widget 
from another tiddler.

Best wishes

Jeremy



> 
> Regards,
> Hubert
> 
> 
> 
> On Friday, 11 October 2019 09:09:34 UTC+1, Hubert wrote:
> Hi Mark,
> 
> My TW now has 63k entries, and, in a meeting the other day,I was able to look 
> up entries about as fast as people asked.
> 
> That's impressive. Did you use a search bar or your own  widget? 
> I'm particularly interested if it was the latter.
> 
> But that was using a Kindle Fire, which might have a stronger processor
> than a motorola phone.
> 
> I don't believe you've mentioned what browser you're using. My tests were on 
> an old version of FF that I'm not upgrading because it
> can still use TiddlyFox.
> 
> It might be worth experimenting with different browsers. I believe browser 
> makers have wide latitude in how they implement JS internals.
> 
> I'm now at a Windows PC with i7 processor, 8 gigs of RAM and running latest 
> FF. The lag is still there, albeit of course not that annoying as on mobile. 
> Same issue on Chrome.
> 
> 
> On Thursday, 10 October 2019 16:29:56 UTC+1, Mark S. wrote:
> In my case, I kept the tags but removed all usage of the tag filter operator. 
> My TW now has 63k entries, and, in a meeting the other day,
> I was able to look up entries about as fast as people asked. But that was 
> using a Kindle Fire, which might have a stronger processor
> than a motorola phone.
> 
> I don't believe you've mentioned what browser you're using. My tests were on 
> an old version of FF that I'm not upgrading because it
> can still use TiddlyFox.
> 
> It might be worth experimenting with different browsers. I believe browser 
> makers have wide latitude in how they implement JS internals.
> 
> Good luck!
> 
> 
> On Thursday, October 10, 2019 at 8:00:47 AM UTC-7, Hubert wrote:
> Sounds counter-intuitive, but I've just checked it nevertheless.
> 
> Nope, 400 is much worse in my case.
> 
> The circumstantial evidence I have so far is pointing to tags...
> 
> On Thursday, 10 October 2019 15:49:30 UTC+1, Mark S. wrote:
> I you know, I think experienced this before, and commented. Try resetting the 
> timeout back to 400 and reloading.
> 
> After setting the TO to 6, it feels slower when typing into the input box.
> 
> On Thursday, October 10, 2019 at 5:53:07 AM UTC-7, Hubert wrote:
> Hi Mark,
>  
> Just testing now, and setting it to 6 doesn't seem to impact the speed 
> with regular editing nor inside a form box.
> 
> Have you reloaded the wiki after setting it to 6? It might not take 
> effect until reloaded.
> 
> Is there anything special about your TW file? Have you tested on an empty ?
> 
> No and yes, respectively.
> 
> The lag on mobile may be more or less noticeable, which could even depend on 
> the size of the wiki and/or on the number of tiddlers currently open. I lack 
> the knowledge to draw conclusions but I do suspect it has to do with the 
> refresh mechanism.
> 
> BTW. my wiki is just slightly over 5 megs.
> 
> Regards,
> Hubert
> 
> 
> On Wednesday, 9 October 2019 21:15:04 UTC+1, Mark S. wrote:
> I've mentioned typing speeds in the past. I never found that the draft speed 
> setting really changed anything one
> way or the other. Maybe it makes a difference on Mac but not on Android.
> 
> Just testing now, and setting it

[tw5] Re: Typing lag in <$edit-text/> widget

[Hubert]

Mark,

I've found this old post of yours 
, 
again, in relation to performance issues specifically related to typing. 
This was even before TypingTimeout was a user-adjustable setting.

This led me to experiment with an altogether different approach that has 
tentatively *solved the issue*. Now I can type with no lag at all, but 
unfortunately this approach requires that a tiddler I'm typing into is 
constantly open (a 'draft of' tiddler), so as such it's a band aid approach.

The reasons behind this is that TW exempts draft tiddlers from constant 
refreshes or at least allows us to defer processing by a value we set in 
TypingTimeout, which regrettably is a value that only affects draft 
tiddlers (the ones that remain in editing mode).

Example code:

<$edit-text tiddler="Draft of 'text'"/>


   1. Create a tiddler titled text, save it
   2. Open the tiddler and navigate away from it (without closing it or 
   saving it)
   3. Open a tiddler with the edit-text widget and type with no lag
   
This is the level of typing experience I was expecting.

Now I have to figure out how I can prevent this open text tiddler from 
being constantly referenced in a red notification rectangle and to prevent 
TW from saving it, because once it exits editing mode the lag is 
reintroduced.

Regards,
Hubert



On Friday, 11 October 2019 09:09:34 UTC+1, Hubert wrote:
>
> Hi Mark,
>
> My TW now has 63k entries, and, in a meeting the other day,I was able to 
>> look up entries about as fast as people asked.
>>
>
> That's impressive. Did you use a search bar or your own  
> widget? I'm particularly interested if it was the latter.
>
> But that was using a Kindle Fire, which might have a stronger processor
>> than a motorola phone.
>>
>> I don't believe you've mentioned what browser you're using. My tests were 
>> on an old version of FF that I'm not upgrading because it
>> can still use TiddlyFox.
>>
>> It might be worth experimenting with different browsers. I believe 
>> browser makers have wide latitude in how they implement JS internals.
>>
>
> I'm now at a Windows PC with i7 processor, 8 gigs of RAM and running 
> latest FF. The lag is still there, albeit of course not that annoying as on 
> mobile. Same issue on Chrome.
>
>
> On Thursday, 10 October 2019 16:29:56 UTC+1, Mark S. wrote:
>>
>> In my case, I kept the tags but removed all usage of the tag filter 
>> operator. My TW now has 63k entries, and, in a meeting the other day,
>> I was able to look up entries about as fast as people asked. But that was 
>> using a Kindle Fire, which might have a stronger processor
>> than a motorola phone.
>>
>> I don't believe you've mentioned what browser you're using. My tests were 
>> on an old version of FF that I'm not upgrading because it
>> can still use TiddlyFox.
>>
>> It might be worth experimenting with different browsers. I believe 
>> browser makers have wide latitude in how they implement JS internals.
>>
>> Good luck!
>>
>>
>> On Thursday, October 10, 2019 at 8:00:47 AM UTC-7, Hubert wrote:
>>
>>> Sounds counter-intuitive, but I've just checked it nevertheless.
>>>
>>> Nope, 400 is much worse in my case.
>>>
>>> The circumstantial evidence I have so far is pointing to tags...
>>>
>>> On Thursday, 10 October 2019 15:49:30 UTC+1, Mark S. wrote:

 I you know, I think experienced this before, and commented. Try 
 resetting the timeout back to 400 and reloading.

 After setting the TO to 6, it feels *slower* when typing into the 
 input box.

 On Thursday, October 10, 2019 at 5:53:07 AM UTC-7, Hubert wrote:
>
> Hi Mark,
>  
>
>> Just testing now, and setting it to 6 doesn't seem to impact the 
>> speed with regular editing nor inside a form box.
>>
>
> Have you reloaded the wiki after setting it to 6? It might not 
> take effect until reloaded.
>
> Is there anything special about your TW file? Have you tested on an 
>> empty ?
>>
>
> No and yes, respectively.
>
> The lag on mobile may be more or less noticeable, which could even 
> depend on the size of the wiki and/or on the number of tiddlers currently 
> open. I lack the knowledge to draw conclusions but I do suspect it has to 
> do with the refresh mechanism.
>
> BTW. my wiki is just slightly over 5 megs.
>
> Regards,
> Hubert
>
>
> On Wednesday, 9 October 2019 21:15:04 UTC+1, Mark S. wrote:
>>
>> I've mentioned typing speeds in the past. I never found that the 
>> draft speed setting really changed anything one
>> way or the other. Maybe it makes a difference on Mac but not on 
>> Android.
>>
>> Just testing now, and setting it to 6 doesn't seem to impact the 
>> speed with regular editing nor inside a form box.
>>
>> Is there anything special about your TW file? Have you tested on an 
>> empt

[tw5] Re: Typing lag in <$edit-text/> widget

[Hubert]

Hi Mark,

My TW now has 63k entries, and, in a meeting the other day,I was able to 
> look up entries about as fast as people asked.
>

That's impressive. Did you use a search bar or your own  
widget? I'm particularly interested if it was the latter.

But that was using a Kindle Fire, which might have a stronger processor
> than a motorola phone.
>
> I don't believe you've mentioned what browser you're using. My tests were 
> on an old version of FF that I'm not upgrading because it
> can still use TiddlyFox.
>
> It might be worth experimenting with different browsers. I believe browser 
> makers have wide latitude in how they implement JS internals.
>

I'm now at a Windows PC with i7 processor, 8 gigs of RAM and running latest 
FF. The lag is still there, albeit of course not that annoying as on 
mobile. Same issue on Chrome.


On Thursday, 10 October 2019 16:29:56 UTC+1, Mark S. wrote:
>
> In my case, I kept the tags but removed all usage of the tag filter 
> operator. My TW now has 63k entries, and, in a meeting the other day,
> I was able to look up entries about as fast as people asked. But that was 
> using a Kindle Fire, which might have a stronger processor
> than a motorola phone.
>
> I don't believe you've mentioned what browser you're using. My tests were 
> on an old version of FF that I'm not upgrading because it
> can still use TiddlyFox.
>
> It might be worth experimenting with different browsers. I believe browser 
> makers have wide latitude in how they implement JS internals.
>
> Good luck!
>
>
> On Thursday, October 10, 2019 at 8:00:47 AM UTC-7, Hubert wrote:
>
>> Sounds counter-intuitive, but I've just checked it nevertheless.
>>
>> Nope, 400 is much worse in my case.
>>
>> The circumstantial evidence I have so far is pointing to tags...
>>
>> On Thursday, 10 October 2019 15:49:30 UTC+1, Mark S. wrote:
>>>
>>> I you know, I think experienced this before, and commented. Try 
>>> resetting the timeout back to 400 and reloading.
>>>
>>> After setting the TO to 6, it feels *slower* when typing into the 
>>> input box.
>>>
>>> On Thursday, October 10, 2019 at 5:53:07 AM UTC-7, Hubert wrote:

 Hi Mark,
  

> Just testing now, and setting it to 6 doesn't seem to impact the 
> speed with regular editing nor inside a form box.
>

 Have you reloaded the wiki after setting it to 6? It might not take 
 effect until reloaded.

 Is there anything special about your TW file? Have you tested on an 
> empty ?
>

 No and yes, respectively.

 The lag on mobile may be more or less noticeable, which could even 
 depend on the size of the wiki and/or on the number of tiddlers currently 
 open. I lack the knowledge to draw conclusions but I do suspect it has to 
 do with the refresh mechanism.

 BTW. my wiki is just slightly over 5 megs.

 Regards,
 Hubert


 On Wednesday, 9 October 2019 21:15:04 UTC+1, Mark S. wrote:
>
> I've mentioned typing speeds in the past. I never found that the draft 
> speed setting really changed anything one
> way or the other. Maybe it makes a difference on Mac but not on 
> Android.
>
> Just testing now, and setting it to 6 doesn't seem to impact the 
> speed with regular editing nor inside a form box.
>
> Is there anything special about your TW file? Have you tested on an 
> empty ?
>
> Good luck!
>
> On Wednesday, October 9, 2019 at 12:49:43 PM UTC-7, Hubert wrote:
>>
>> Hi Mark,
>>
>> What vintage is your phone?
>>
>>
>> It's a fairly recent midrange Motorola. 
>>
>> What version of TW are you using? There are size/speed improvements 
>>> in 5.1.20.
>>
>>
>> I'm using the latest stable TW version (5.1.21).
>>
>> I tried your test on the full downloaded TiddlyWiki.com page on my 
>>> 2012 era samsung phone. The speed of course was slow, but it was the 
>>> same 
>>> for the edit box as for editing the tiddler itself.
>>
>>
>> Thanks for having a go with the test on mobile. Have you modified the 
>> TypingTimeout value before testing? I'm having a "native" (no lag) 
>> typing 
>> experience when editing a tiddler after setting the value in 
>> $:/config/Drafts/TypingTimeout to 6. By default, this value is 
>> around 
>> 400 (ms), which results in a noticeable lag in my case, so just 
>> wondering.
>>
>> You probably know this already, but be sure to not have your "recent" 
>>> tiddler opened in the sidebar.
>>
>>
>> Yes, I do :). I have it disabled across the whole wiki.
>>
>>
>>
>> On Wednesday, 9 October 2019 19:55:31 UTC+1, Mark S. wrote:
>>>
>>> What vintage is your phone?
>>>
>>> What version of TW are you using? There are size/speed improvements 
>>> in 5.1.20.
>>>
>>> I tried your test on the full down

[tw5] Re: Typing lag in <$edit-text/> widget

['Mark S.' via TiddlyWiki]

In my case, I kept the tags but removed all usage of the tag filter 
operator. My TW now has 63k entries, and, in a meeting the other day,
I was able to look up entries about as fast as people asked. But that was 
using a Kindle Fire, which might have a stronger processor
than a motorola phone.

I don't believe you've mentioned what browser you're using. My tests were 
on an old version of FF that I'm not upgrading because it
can still use TiddlyFox.

It might be worth experimenting with different browsers. I believe browser 
makers have wide latitude in how they implement JS internals.

Good luck!


On Thursday, October 10, 2019 at 8:00:47 AM UTC-7, Hubert wrote:

> Sounds counter-intuitive, but I've just checked it nevertheless.
>
> Nope, 400 is much worse in my case.
>
> The circumstantial evidence I have so far is pointing to tags...
>
> On Thursday, 10 October 2019 15:49:30 UTC+1, Mark S. wrote:
>>
>> I you know, I think experienced this before, and commented. Try resetting 
>> the timeout back to 400 and reloading.
>>
>> After setting the TO to 6, it feels *slower* when typing into the 
>> input box.
>>
>> On Thursday, October 10, 2019 at 5:53:07 AM UTC-7, Hubert wrote:
>>>
>>> Hi Mark,
>>>  
>>>
 Just testing now, and setting it to 6 doesn't seem to impact the 
 speed with regular editing nor inside a form box.

>>>
>>> Have you reloaded the wiki after setting it to 6? It might not take 
>>> effect until reloaded.
>>>
>>> Is there anything special about your TW file? Have you tested on an 
 empty ?

>>>
>>> No and yes, respectively.
>>>
>>> The lag on mobile may be more or less noticeable, which could even 
>>> depend on the size of the wiki and/or on the number of tiddlers currently 
>>> open. I lack the knowledge to draw conclusions but I do suspect it has to 
>>> do with the refresh mechanism.
>>>
>>> BTW. my wiki is just slightly over 5 megs.
>>>
>>> Regards,
>>> Hubert
>>>
>>>
>>> On Wednesday, 9 October 2019 21:15:04 UTC+1, Mark S. wrote:

 I've mentioned typing speeds in the past. I never found that the draft 
 speed setting really changed anything one
 way or the other. Maybe it makes a difference on Mac but not on Android.

 Just testing now, and setting it to 6 doesn't seem to impact the 
 speed with regular editing nor inside a form box.

 Is there anything special about your TW file? Have you tested on an 
 empty ?

 Good luck!

 On Wednesday, October 9, 2019 at 12:49:43 PM UTC-7, Hubert wrote:
>
> Hi Mark,
>
> What vintage is your phone?
>
>
> It's a fairly recent midrange Motorola. 
>
> What version of TW are you using? There are size/speed improvements in 
>> 5.1.20.
>
>
> I'm using the latest stable TW version (5.1.21).
>
> I tried your test on the full downloaded TiddlyWiki.com page on my 
>> 2012 era samsung phone. The speed of course was slow, but it was the 
>> same 
>> for the edit box as for editing the tiddler itself.
>
>
> Thanks for having a go with the test on mobile. Have you modified the 
> TypingTimeout value before testing? I'm having a "native" (no lag) typing 
> experience when editing a tiddler after setting the value in 
> $:/config/Drafts/TypingTimeout to 6. By default, this value is around 
> 400 (ms), which results in a noticeable lag in my case, so just wondering.
>
> You probably know this already, but be sure to not have your "recent" 
>> tiddler opened in the sidebar.
>
>
> Yes, I do :). I have it disabled across the whole wiki.
>
>
>
> On Wednesday, 9 October 2019 19:55:31 UTC+1, Mark S. wrote:
>>
>> What vintage is your phone?
>>
>> What version of TW are you using? There are size/speed improvements 
>> in 5.1.20.
>>
>> I tried your test on the full downloaded TiddlyWiki.com page on my 
>> 2012 era samsung phone. The speed of course was slow, but it was the same
>> for the edit box as for editing the tiddler itself. In either case, 
>> the upper limit to typing was my ability to use the tiny keyboard.
>>
>> You probably know this already, but be sure to not have your "recent" 
>> tiddler opened in the sidebar.
>>
>> Good luck!
>>
>>
>> On Tuesday, October 8, 2019 at 7:47:00 AM UTC-7, Hubert wrote:
>>>
>>> Hello,
>>>
>>> Before I go into details, my $:/config/Drafts/TypingTimeout tiddler 
>>> has a value of 6 (60 seconds), which fixed the lag when entering 
>>> text / 
>>> typing in a tiddler in edit mode.
>>>
>>> However, I'm still experiencing lag when entering text using 
>>> <$edit-text/> widgets (of course, the tiddler being populated as I type 
>>> is 
>>> separate to the one that has the edit-text widget).
>>>
>>> This lag is negligible on my Chromebook or Windows PC (I have no 
>>> mea

[tw5] Re: Typing lag in <$edit-text/> widget

[Hubert]

Sounds counter-intuitive, but I've just checked it nevertheless.

Nope, 400 is much worse in my case.

The circumstantial evidence I have so far is pointing to tags...

On Thursday, 10 October 2019 15:49:30 UTC+1, Mark S. wrote:
>
> I you know, I think experienced this before, and commented. Try resetting 
> the timeout back to 400 and reloading.
>
> After setting the TO to 6, it feels *slower* when typing into the 
> input box.
>
> On Thursday, October 10, 2019 at 5:53:07 AM UTC-7, Hubert wrote:
>>
>> Hi Mark,
>>  
>>
>>> Just testing now, and setting it to 6 doesn't seem to impact the 
>>> speed with regular editing nor inside a form box.
>>>
>>
>> Have you reloaded the wiki after setting it to 6? It might not take 
>> effect until reloaded.
>>
>> Is there anything special about your TW file? Have you tested on an empty 
>>> ?
>>>
>>
>> No and yes, respectively.
>>
>> The lag on mobile may be more or less noticeable, which could even depend 
>> on the size of the wiki and/or on the number of tiddlers currently open. I 
>> lack the knowledge to draw conclusions but I do suspect it has to do with 
>> the refresh mechanism.
>>
>> BTW. my wiki is just slightly over 5 megs.
>>
>> Regards,
>> Hubert
>>
>>
>> On Wednesday, 9 October 2019 21:15:04 UTC+1, Mark S. wrote:
>>>
>>> I've mentioned typing speeds in the past. I never found that the draft 
>>> speed setting really changed anything one
>>> way or the other. Maybe it makes a difference on Mac but not on Android.
>>>
>>> Just testing now, and setting it to 6 doesn't seem to impact the 
>>> speed with regular editing nor inside a form box.
>>>
>>> Is there anything special about your TW file? Have you tested on an 
>>> empty ?
>>>
>>> Good luck!
>>>
>>> On Wednesday, October 9, 2019 at 12:49:43 PM UTC-7, Hubert wrote:

 Hi Mark,

 What vintage is your phone?


 It's a fairly recent midrange Motorola. 

 What version of TW are you using? There are size/speed improvements in 
> 5.1.20.


 I'm using the latest stable TW version (5.1.21).

 I tried your test on the full downloaded TiddlyWiki.com page on my 2012 
> era samsung phone. The speed of course was slow, but it was the same for 
> the edit box as for editing the tiddler itself.


 Thanks for having a go with the test on mobile. Have you modified the 
 TypingTimeout value before testing? I'm having a "native" (no lag) typing 
 experience when editing a tiddler after setting the value in 
 $:/config/Drafts/TypingTimeout to 6. By default, this value is around 
 400 (ms), which results in a noticeable lag in my case, so just wondering.

 You probably know this already, but be sure to not have your "recent" 
> tiddler opened in the sidebar.


 Yes, I do :). I have it disabled across the whole wiki.



 On Wednesday, 9 October 2019 19:55:31 UTC+1, Mark S. wrote:
>
> What vintage is your phone?
>
> What version of TW are you using? There are size/speed improvements in 
> 5.1.20.
>
> I tried your test on the full downloaded TiddlyWiki.com page on my 
> 2012 era samsung phone. The speed of course was slow, but it was the same
> for the edit box as for editing the tiddler itself. In either case, 
> the upper limit to typing was my ability to use the tiny keyboard.
>
> You probably know this already, but be sure to not have your "recent" 
> tiddler opened in the sidebar.
>
> Good luck!
>
>
> On Tuesday, October 8, 2019 at 7:47:00 AM UTC-7, Hubert wrote:
>>
>> Hello,
>>
>> Before I go into details, my $:/config/Drafts/TypingTimeout tiddler 
>> has a value of 6 (60 seconds), which fixed the lag when entering 
>> text / 
>> typing in a tiddler in edit mode.
>>
>> However, I'm still experiencing lag when entering text using 
>> <$edit-text/> widgets (of course, the tiddler being populated as I type 
>> is 
>> separate to the one that has the edit-text widget).
>>
>> This lag is negligible on my Chromebook or Windows PC (I have no 
>> means of measuring it but even if it's 5ms then it's not much to worry 
>> about) but it is very noticeable on Android (using Chrome as an 
>> example). 
>> It gets better if I close all tiddlers except the one that has the 
>> <$edit-text/> widget and I assume that the lag has to do with TiddlyWiki 
>> re-rendering all the open tiddlers as I type (though I'm not sure if 
>> that's 
>> the case).
>>
>> What exactly is introducing the lag when using <$edit-text/> widgets? 
>> Is it realtime rendering? If so, could the scope of 
>> $:/config/Drafts/TypingTimeout be extended to also include <$edit-text/> 
>> widgets, so that the lag is fixed at the expense of instantaneous 
>> rendering? Is there any other mechanism that is at fault here? I do not 
>>

[tw5] Re: Typing lag in <$edit-text/> widget

['Mark S.' via TiddlyWiki]

I you know, I think experienced this before, and commented. Try resetting 
the timeout back to 400 and reloading.

After setting the TO to 6, it feels *slower* when typing into the input 
box.

On Thursday, October 10, 2019 at 5:53:07 AM UTC-7, Hubert wrote:
>
> Hi Mark,
>  
>
>> Just testing now, and setting it to 6 doesn't seem to impact the 
>> speed with regular editing nor inside a form box.
>>
>
> Have you reloaded the wiki after setting it to 6? It might not take 
> effect until reloaded.
>
> Is there anything special about your TW file? Have you tested on an empty ?
>>
>
> No and yes, respectively.
>
> The lag on mobile may be more or less noticeable, which could even depend 
> on the size of the wiki and/or on the number of tiddlers currently open. I 
> lack the knowledge to draw conclusions but I do suspect it has to do with 
> the refresh mechanism.
>
> BTW. my wiki is just slightly over 5 megs.
>
> Regards,
> Hubert
>
>
> On Wednesday, 9 October 2019 21:15:04 UTC+1, Mark S. wrote:
>>
>> I've mentioned typing speeds in the past. I never found that the draft 
>> speed setting really changed anything one
>> way or the other. Maybe it makes a difference on Mac but not on Android.
>>
>> Just testing now, and setting it to 6 doesn't seem to impact the 
>> speed with regular editing nor inside a form box.
>>
>> Is there anything special about your TW file? Have you tested on an empty 
>> ?
>>
>> Good luck!
>>
>> On Wednesday, October 9, 2019 at 12:49:43 PM UTC-7, Hubert wrote:
>>>
>>> Hi Mark,
>>>
>>> What vintage is your phone?
>>>
>>>
>>> It's a fairly recent midrange Motorola. 
>>>
>>> What version of TW are you using? There are size/speed improvements in 
 5.1.20.
>>>
>>>
>>> I'm using the latest stable TW version (5.1.21).
>>>
>>> I tried your test on the full downloaded TiddlyWiki.com page on my 2012 
 era samsung phone. The speed of course was slow, but it was the same for 
 the edit box as for editing the tiddler itself.
>>>
>>>
>>> Thanks for having a go with the test on mobile. Have you modified the 
>>> TypingTimeout value before testing? I'm having a "native" (no lag) typing 
>>> experience when editing a tiddler after setting the value in 
>>> $:/config/Drafts/TypingTimeout to 6. By default, this value is around 
>>> 400 (ms), which results in a noticeable lag in my case, so just wondering.
>>>
>>> You probably know this already, but be sure to not have your "recent" 
 tiddler opened in the sidebar.
>>>
>>>
>>> Yes, I do :). I have it disabled across the whole wiki.
>>>
>>>
>>>
>>> On Wednesday, 9 October 2019 19:55:31 UTC+1, Mark S. wrote:

 What vintage is your phone?

 What version of TW are you using? There are size/speed improvements in 
 5.1.20.

 I tried your test on the full downloaded TiddlyWiki.com page on my 2012 
 era samsung phone. The speed of course was slow, but it was the same
 for the edit box as for editing the tiddler itself. In either case, the 
 upper limit to typing was my ability to use the tiny keyboard.

 You probably know this already, but be sure to not have your "recent" 
 tiddler opened in the sidebar.

 Good luck!


 On Tuesday, October 8, 2019 at 7:47:00 AM UTC-7, Hubert wrote:
>
> Hello,
>
> Before I go into details, my $:/config/Drafts/TypingTimeout tiddler 
> has a value of 6 (60 seconds), which fixed the lag when entering text 
> / 
> typing in a tiddler in edit mode.
>
> However, I'm still experiencing lag when entering text using 
> <$edit-text/> widgets (of course, the tiddler being populated as I type 
> is 
> separate to the one that has the edit-text widget).
>
> This lag is negligible on my Chromebook or Windows PC (I have no means 
> of measuring it but even if it's 5ms then it's not much to worry about) 
> but 
> it is very noticeable on Android (using Chrome as an example). It gets 
> better if I close all tiddlers except the one that has the <$edit-text/> 
> widget and I assume that the lag has to do with TiddlyWiki re-rendering 
> all 
> the open tiddlers as I type (though I'm not sure if that's the case).
>
> What exactly is introducing the lag when using <$edit-text/> widgets? 
> Is it realtime rendering? If so, could the scope of 
> $:/config/Drafts/TypingTimeout be extended to also include <$edit-text/> 
> widgets, so that the lag is fixed at the expense of instantaneous 
> rendering? Is there any other mechanism that is at fault here? I do not 
> believe that we should require a multicore workstation to have a smooth 
> typing experience.
>
> Typing into a tiddler in edit mode and entering text in a password 
> prompt both work with absolutely no lag on mobile (this is the 'native' 
> typing feel), but these are the only two examples.
>
> The <$range/> widget seems to suffer from the same 

[tw5] Re: Typing lag in <$edit-text/> widget

[Hubert]

Update: having read Mark's post about hitting a barrier at 36000 tiddlers 
, 
I've removed all tags from my wiki and made another typing test using a PC.

Pressing and holding a letter key produced 10 rows of text in 16 seconds in 
my wiki, while after removing all tags from the wiki this time was reduced 
to 10 seconds, an improvement in the lag by some 40% (mysterious in itself 
as none of the tagged tiddlers were open at the time of the test).

This might also explain why typing in empty.html is indeed somewhat faster.

-Hubert

On Thursday, 10 October 2019 13:53:07 UTC+1, Hubert wrote:
>
> Hi Mark,
>  
>
>> Just testing now, and setting it to 6 doesn't seem to impact the 
>> speed with regular editing nor inside a form box.
>>
>
> Have you reloaded the wiki after setting it to 6? It might not take 
> effect until reloaded.
>
> Is there anything special about your TW file? Have you tested on an empty ?
>>
>
> No and yes, respectively.
>
> The lag on mobile may be more or less noticeable, which could even depend 
> on the size of the wiki and/or on the number of tiddlers currently open. I 
> lack the knowledge to draw conclusions but I do suspect it has to do with 
> the refresh mechanism.
>
> BTW. my wiki is just slightly over 5 megs.
>
> Regards,
> Hubert
>
>
> On Wednesday, 9 October 2019 21:15:04 UTC+1, Mark S. wrote:
>>
>> I've mentioned typing speeds in the past. I never found that the draft 
>> speed setting really changed anything one
>> way or the other. Maybe it makes a difference on Mac but not on Android.
>>
>> Just testing now, and setting it to 6 doesn't seem to impact the 
>> speed with regular editing nor inside a form box.
>>
>> Is there anything special about your TW file? Have you tested on an empty 
>> ?
>>
>> Good luck!
>>
>> On Wednesday, October 9, 2019 at 12:49:43 PM UTC-7, Hubert wrote:
>>>
>>> Hi Mark,
>>>
>>> What vintage is your phone?
>>>
>>>
>>> It's a fairly recent midrange Motorola. 
>>>
>>> What version of TW are you using? There are size/speed improvements in 
 5.1.20.
>>>
>>>
>>> I'm using the latest stable TW version (5.1.21).
>>>
>>> I tried your test on the full downloaded TiddlyWiki.com page on my 2012 
 era samsung phone. The speed of course was slow, but it was the same for 
 the edit box as for editing the tiddler itself.
>>>
>>>
>>> Thanks for having a go with the test on mobile. Have you modified the 
>>> TypingTimeout value before testing? I'm having a "native" (no lag) typing 
>>> experience when editing a tiddler after setting the value in 
>>> $:/config/Drafts/TypingTimeout to 6. By default, this value is around 
>>> 400 (ms), which results in a noticeable lag in my case, so just wondering.
>>>
>>> You probably know this already, but be sure to not have your "recent" 
 tiddler opened in the sidebar.
>>>
>>>
>>> Yes, I do :). I have it disabled across the whole wiki.
>>>
>>>
>>>
>>> On Wednesday, 9 October 2019 19:55:31 UTC+1, Mark S. wrote:

 What vintage is your phone?

 What version of TW are you using? There are size/speed improvements in 
 5.1.20.

 I tried your test on the full downloaded TiddlyWiki.com page on my 2012 
 era samsung phone. The speed of course was slow, but it was the same
 for the edit box as for editing the tiddler itself. In either case, the 
 upper limit to typing was my ability to use the tiny keyboard.

 You probably know this already, but be sure to not have your "recent" 
 tiddler opened in the sidebar.

 Good luck!


 On Tuesday, October 8, 2019 at 7:47:00 AM UTC-7, Hubert wrote:
>
> Hello,
>
> Before I go into details, my $:/config/Drafts/TypingTimeout tiddler 
> has a value of 6 (60 seconds), which fixed the lag when entering text 
> / 
> typing in a tiddler in edit mode.
>
> However, I'm still experiencing lag when entering text using 
> <$edit-text/> widgets (of course, the tiddler being populated as I type 
> is 
> separate to the one that has the edit-text widget).
>
> This lag is negligible on my Chromebook or Windows PC (I have no means 
> of measuring it but even if it's 5ms then it's not much to worry about) 
> but 
> it is very noticeable on Android (using Chrome as an example). It gets 
> better if I close all tiddlers except the one that has the <$edit-text/> 
> widget and I assume that the lag has to do with TiddlyWiki re-rendering 
> all 
> the open tiddlers as I type (though I'm not sure if that's the case).
>
> What exactly is introducing the lag when using <$edit-text/> widgets? 
> Is it realtime rendering? If so, could the scope of 
> $:/config/Drafts/TypingTimeout be extended to also include <$edit-text/> 
> widgets, so that the lag is fixed at the expense of instantaneous 
> rendering? Is there any other mechanism that is

[tw5] Re: Typing lag in <$edit-text/> widget

[Hubert]

Hi Mark,
 

> Just testing now, and setting it to 6 doesn't seem to impact the speed 
> with regular editing nor inside a form box.
>

Have you reloaded the wiki after setting it to 6? It might not take 
effect until reloaded.

Is there anything special about your TW file? Have you tested on an empty ?
>

No and yes, respectively.

The lag on mobile may be more or less noticeable, which could even depend 
on the size of the wiki and/or on the number of tiddlers currently open. I 
lack the knowledge to draw conclusions but I do suspect it has to do with 
the refresh mechanism.

BTW. my wiki is just slightly over 5 megs.

Regards,
Hubert


On Wednesday, 9 October 2019 21:15:04 UTC+1, Mark S. wrote:
>
> I've mentioned typing speeds in the past. I never found that the draft 
> speed setting really changed anything one
> way or the other. Maybe it makes a difference on Mac but not on Android.
>
> Just testing now, and setting it to 6 doesn't seem to impact the speed 
> with regular editing nor inside a form box.
>
> Is there anything special about your TW file? Have you tested on an empty ?
>
> Good luck!
>
> On Wednesday, October 9, 2019 at 12:49:43 PM UTC-7, Hubert wrote:
>>
>> Hi Mark,
>>
>> What vintage is your phone?
>>
>>
>> It's a fairly recent midrange Motorola. 
>>
>> What version of TW are you using? There are size/speed improvements in 
>>> 5.1.20.
>>
>>
>> I'm using the latest stable TW version (5.1.21).
>>
>> I tried your test on the full downloaded TiddlyWiki.com page on my 2012 
>>> era samsung phone. The speed of course was slow, but it was the same for 
>>> the edit box as for editing the tiddler itself.
>>
>>
>> Thanks for having a go with the test on mobile. Have you modified the 
>> TypingTimeout value before testing? I'm having a "native" (no lag) typing 
>> experience when editing a tiddler after setting the value in 
>> $:/config/Drafts/TypingTimeout to 6. By default, this value is around 
>> 400 (ms), which results in a noticeable lag in my case, so just wondering.
>>
>> You probably know this already, but be sure to not have your "recent" 
>>> tiddler opened in the sidebar.
>>
>>
>> Yes, I do :). I have it disabled across the whole wiki.
>>
>>
>>
>> On Wednesday, 9 October 2019 19:55:31 UTC+1, Mark S. wrote:
>>>
>>> What vintage is your phone?
>>>
>>> What version of TW are you using? There are size/speed improvements in 
>>> 5.1.20.
>>>
>>> I tried your test on the full downloaded TiddlyWiki.com page on my 2012 
>>> era samsung phone. The speed of course was slow, but it was the same
>>> for the edit box as for editing the tiddler itself. In either case, the 
>>> upper limit to typing was my ability to use the tiny keyboard.
>>>
>>> You probably know this already, but be sure to not have your "recent" 
>>> tiddler opened in the sidebar.
>>>
>>> Good luck!
>>>
>>>
>>> On Tuesday, October 8, 2019 at 7:47:00 AM UTC-7, Hubert wrote:

 Hello,

 Before I go into details, my $:/config/Drafts/TypingTimeout tiddler has 
 a value of 6 (60 seconds), which fixed the lag when entering text / 
 typing in a tiddler in edit mode.

 However, I'm still experiencing lag when entering text using 
 <$edit-text/> widgets (of course, the tiddler being populated as I type is 
 separate to the one that has the edit-text widget).

 This lag is negligible on my Chromebook or Windows PC (I have no means 
 of measuring it but even if it's 5ms then it's not much to worry about) 
 but 
 it is very noticeable on Android (using Chrome as an example). It gets 
 better if I close all tiddlers except the one that has the <$edit-text/> 
 widget and I assume that the lag has to do with TiddlyWiki re-rendering 
 all 
 the open tiddlers as I type (though I'm not sure if that's the case).

 What exactly is introducing the lag when using <$edit-text/> widgets? 
 Is it realtime rendering? If so, could the scope of 
 $:/config/Drafts/TypingTimeout be extended to also include <$edit-text/> 
 widgets, so that the lag is fixed at the expense of instantaneous 
 rendering? Is there any other mechanism that is at fault here? I do not 
 believe that we should require a multicore workstation to have a smooth 
 typing experience.

 Typing into a tiddler in edit mode and entering text in a password 
 prompt both work with absolutely no lag on mobile (this is the 'native' 
 typing feel), but these are the only two examples.

 The <$range/> widget seems to suffer from the same lag occasionally 
 (it's not super smooth) but I'm not sure if it's affected by the same root 
 cause.

 Finally, apologies for awkward phrasing; English is not my first 
 language.

 Many thanks,
 Hubert




-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send

[tw5] Re: Typing lag in <$edit-text/> widget

['Mark S.' via TiddlyWiki]

I've mentioned typing speeds in the past. I never found that the draft 
speed setting really changed anything one
way or the other. Maybe it makes a difference on Mac but not on Android.

Just testing now, and setting it to 6 doesn't seem to impact the speed 
with regular editing nor inside a form box.

Is there anything special about your TW file? Have you tested on an empty ?

Good luck!

On Wednesday, October 9, 2019 at 12:49:43 PM UTC-7, Hubert wrote:
>
> Hi Mark,
>
> What vintage is your phone?
>
>
> It's a fairly recent midrange Motorola. 
>
> What version of TW are you using? There are size/speed improvements in 
>> 5.1.20.
>
>
> I'm using the latest stable TW version (5.1.21).
>
> I tried your test on the full downloaded TiddlyWiki.com page on my 2012 
>> era samsung phone. The speed of course was slow, but it was the same for 
>> the edit box as for editing the tiddler itself.
>
>
> Thanks for having a go with the test on mobile. Have you modified the 
> TypingTimeout value before testing? I'm having a "native" (no lag) typing 
> experience when editing a tiddler after setting the value in 
> $:/config/Drafts/TypingTimeout to 6. By default, this value is around 
> 400 (ms), which results in a noticeable lag in my case, so just wondering.
>
> You probably know this already, but be sure to not have your "recent" 
>> tiddler opened in the sidebar.
>
>
> Yes, I do :). I have it disabled across the whole wiki.
>
>
>
> On Wednesday, 9 October 2019 19:55:31 UTC+1, Mark S. wrote:
>>
>> What vintage is your phone?
>>
>> What version of TW are you using? There are size/speed improvements in 
>> 5.1.20.
>>
>> I tried your test on the full downloaded TiddlyWiki.com page on my 2012 
>> era samsung phone. The speed of course was slow, but it was the same
>> for the edit box as for editing the tiddler itself. In either case, the 
>> upper limit to typing was my ability to use the tiny keyboard.
>>
>> You probably know this already, but be sure to not have your "recent" 
>> tiddler opened in the sidebar.
>>
>> Good luck!
>>
>>
>> On Tuesday, October 8, 2019 at 7:47:00 AM UTC-7, Hubert wrote:
>>>
>>> Hello,
>>>
>>> Before I go into details, my $:/config/Drafts/TypingTimeout tiddler has 
>>> a value of 6 (60 seconds), which fixed the lag when entering text / 
>>> typing in a tiddler in edit mode.
>>>
>>> However, I'm still experiencing lag when entering text using 
>>> <$edit-text/> widgets (of course, the tiddler being populated as I type is 
>>> separate to the one that has the edit-text widget).
>>>
>>> This lag is negligible on my Chromebook or Windows PC (I have no means 
>>> of measuring it but even if it's 5ms then it's not much to worry about) but 
>>> it is very noticeable on Android (using Chrome as an example). It gets 
>>> better if I close all tiddlers except the one that has the <$edit-text/> 
>>> widget and I assume that the lag has to do with TiddlyWiki re-rendering all 
>>> the open tiddlers as I type (though I'm not sure if that's the case).
>>>
>>> What exactly is introducing the lag when using <$edit-text/> widgets? Is 
>>> it realtime rendering? If so, could the scope of 
>>> $:/config/Drafts/TypingTimeout be extended to also include <$edit-text/> 
>>> widgets, so that the lag is fixed at the expense of instantaneous 
>>> rendering? Is there any other mechanism that is at fault here? I do not 
>>> believe that we should require a multicore workstation to have a smooth 
>>> typing experience.
>>>
>>> Typing into a tiddler in edit mode and entering text in a password 
>>> prompt both work with absolutely no lag on mobile (this is the 'native' 
>>> typing feel), but these are the only two examples.
>>>
>>> The <$range/> widget seems to suffer from the same lag occasionally 
>>> (it's not super smooth) but I'm not sure if it's affected by the same root 
>>> cause.
>>>
>>> Finally, apologies for awkward phrasing; English is not my first 
>>> language.
>>>
>>> Many thanks,
>>> Hubert
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/74ba05a6-2c58-41d1-9382-71d54d7e0d80%40googlegroups.com.

[tw5] Re: Typing lag in <$edit-text/> widget

[Hubert]

Hi Mark,

What vintage is your phone?


It's a fairly recent midrange Motorola. 

What version of TW are you using? There are size/speed improvements in 
> 5.1.20.


I'm using the latest stable TW version (5.1.21).

I tried your test on the full downloaded TiddlyWiki.com page on my 2012 era 
> samsung phone. The speed of course was slow, but it was the same for the 
> edit box as for editing the tiddler itself.


Thanks for having a go with the test on mobile. Have you modified the 
TypingTimeout value before testing? I'm having a "native" (no lag) typing 
experience when editing a tiddler after setting the value in 
$:/config/Drafts/TypingTimeout to 6. By default, this value is around 
400 (ms), which results in a noticeable lag in my case, so just wondering.

You probably know this already, but be sure to not have your "recent" 
> tiddler opened in the sidebar.


Yes, I do :). I have it disabled across the whole wiki.



On Wednesday, 9 October 2019 19:55:31 UTC+1, Mark S. wrote:
>
> What vintage is your phone?
>
> What version of TW are you using? There are size/speed improvements in 
> 5.1.20.
>
> I tried your test on the full downloaded TiddlyWiki.com page on my 2012 
> era samsung phone. The speed of course was slow, but it was the same
> for the edit box as for editing the tiddler itself. In either case, the 
> upper limit to typing was my ability to use the tiny keyboard.
>
> You probably know this already, but be sure to not have your "recent" 
> tiddler opened in the sidebar.
>
> Good luck!
>
>
> On Tuesday, October 8, 2019 at 7:47:00 AM UTC-7, Hubert wrote:
>>
>> Hello,
>>
>> Before I go into details, my $:/config/Drafts/TypingTimeout tiddler has a 
>> value of 6 (60 seconds), which fixed the lag when entering text / 
>> typing in a tiddler in edit mode.
>>
>> However, I'm still experiencing lag when entering text using 
>> <$edit-text/> widgets (of course, the tiddler being populated as I type is 
>> separate to the one that has the edit-text widget).
>>
>> This lag is negligible on my Chromebook or Windows PC (I have no means of 
>> measuring it but even if it's 5ms then it's not much to worry about) but it 
>> is very noticeable on Android (using Chrome as an example). It gets better 
>> if I close all tiddlers except the one that has the <$edit-text/> widget 
>> and I assume that the lag has to do with TiddlyWiki re-rendering all the 
>> open tiddlers as I type (though I'm not sure if that's the case).
>>
>> What exactly is introducing the lag when using <$edit-text/> widgets? Is 
>> it realtime rendering? If so, could the scope of 
>> $:/config/Drafts/TypingTimeout be extended to also include <$edit-text/> 
>> widgets, so that the lag is fixed at the expense of instantaneous 
>> rendering? Is there any other mechanism that is at fault here? I do not 
>> believe that we should require a multicore workstation to have a smooth 
>> typing experience.
>>
>> Typing into a tiddler in edit mode and entering text in a password prompt 
>> both work with absolutely no lag on mobile (this is the 'native' typing 
>> feel), but these are the only two examples.
>>
>> The <$range/> widget seems to suffer from the same lag occasionally (it's 
>> not super smooth) but I'm not sure if it's affected by the same root cause.
>>
>> Finally, apologies for awkward phrasing; English is not my first language.
>>
>> Many thanks,
>> Hubert
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/7211092e-bb05-4010-83d6-e8d12c091d06%40googlegroups.com.

[tw5] Re: Typing lag in <$edit-text/> widget

['Mark S.' via TiddlyWiki]

What vintage is your phone?

What version of TW are you using? There are size/speed improvements in 
5.1.20.

I tried your test on the full downloaded TiddlyWiki.com page on my 2012 era 
samsung phone. The speed of course was slow, but it was the same
for the edit box as for editing the tiddler itself. In either case, the 
upper limit to typing was my ability to use the tiny keyboard.

You probably know this already, but be sure to not have your "recent" 
tiddler opened in the sidebar.

Good luck!


On Tuesday, October 8, 2019 at 7:47:00 AM UTC-7, Hubert wrote:
>
> Hello,
>
> Before I go into details, my $:/config/Drafts/TypingTimeout tiddler has a 
> value of 6 (60 seconds), which fixed the lag when entering text / 
> typing in a tiddler in edit mode.
>
> However, I'm still experiencing lag when entering text using <$edit-text/> 
> widgets (of course, the tiddler being populated as I type is separate to 
> the one that has the edit-text widget).
>
> This lag is negligible on my Chromebook or Windows PC (I have no means of 
> measuring it but even if it's 5ms then it's not much to worry about) but it 
> is very noticeable on Android (using Chrome as an example). It gets better 
> if I close all tiddlers except the one that has the <$edit-text/> widget 
> and I assume that the lag has to do with TiddlyWiki re-rendering all the 
> open tiddlers as I type (though I'm not sure if that's the case).
>
> What exactly is introducing the lag when using <$edit-text/> widgets? Is 
> it realtime rendering? If so, could the scope of 
> $:/config/Drafts/TypingTimeout be extended to also include <$edit-text/> 
> widgets, so that the lag is fixed at the expense of instantaneous 
> rendering? Is there any other mechanism that is at fault here? I do not 
> believe that we should require a multicore workstation to have a smooth 
> typing experience.
>
> Typing into a tiddler in edit mode and entering text in a password prompt 
> both work with absolutely no lag on mobile (this is the 'native' typing 
> feel), but these are the only two examples.
>
> The <$range/> widget seems to suffer from the same lag occasionally (it's 
> not super smooth) but I'm not sure if it's affected by the same root cause.
>
> Finally, apologies for awkward phrasing; English is not my first language.
>
> Many thanks,
> Hubert
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/2a1bf6eb-1307-4211-a645-70ff840c6a1c%40googlegroups.com.

[tw5] Re: Typing lag in <$edit-text/> widget

['Mark S.' via TiddlyWiki]

Hah! You don't remember something *you* wrote? Welcome to my world! ;-) 

On Tuesday, October 8, 2019 at 10:10:51 PM UTC-7, TonyM wrote:
>
> Birthe C
>
> I had a habit of naming things quick in the past, but do not recall QuickDB
>
> Yes, Tiddlywiki is a "divergent thinking muse".
>
> Regards
> Tony
>
> On Wednesday, October 9, 2019 at 4:02:38 PM UTC+11, Birthe C wrote:
>>
>> Thank you Tony,
>>
>> And now I recall. It was you who came up with the QuickDB I am using that 
>> one for a lot of stuff now. For years I have tried to get my partner and my 
>> best friend to use tiddlywiki. No big luck, I am afraid. QuickDB with a lot 
>> of other easy stuff got at least some interest - at least they are now 
>> keeping an eye on my Tiddlywiki. (There may be trickery and necessity into 
>> that effect also..;-) )
>>
>> I am a much simpler user, but I really understand what you are saying, 
>> being cornered in a TW project. That happens all the time, because we get 
>> more ideas than we have time...and it is a never ending story getting even 
>> more into it. I think it is a question about how early on the route we get 
>> caught up LOL.
>>
>> Birthe
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/b18ee835-5804-4e50-a94e-d402516b31cb%40googlegroups.com.

[tw5] Re: Typing lag in <$edit-text/> widget

[TonyM]

Hubert

Thanks for the example. I reproduced it in tiddloid. I see even back space lags.

Now I have something to hack.

Regards
Tony

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/434255f5-f4d8-4912-85f2-c022b2f54484%40googlegroups.com.

[tw5] Re: Typing lag in <$edit-text/> widget

[Hubert]

Thank you Tony.

Perhaps something I did not make clear I tend to allow edit and view of 
> content through the view template such that there is nothing in the current 
> tiddler that needs refreshing. In my examples of caption and description 
> these are not displayed by rendering the current tiddler but by refreshing 
> the view template, the same ui elements in which you are typing.
>

That was perfectly clear Tony and I fully understand your approach. I use 
view templates myself in my own wiki, quite extensively, and your solution 
constitutes a form of "reverse transclusion". I use the more traditional 
approach in that, at the most basic level, I write in tiddler "One" that 
has the edit-text widget to update a tiddler "Two" (or any of its fields of 
indices, for that matter), where "Two" is out of view (closed, folded etc.) 
and where "Two" is *not* the current tiddler.

Both approaches are similar in that we don't type into the current tiddler. 
This is the quite obvious prerequisite. Once that's out of the way (the 
totally avoidable loss of focus, which I'm not talking about here), the 
refresh mechanism remains the sole issue and, I believe, the root of the 
problem I'm reporting. Again, the problem is barely perceptible on 
desktops/laptops but is an issue on mobile.

Please consider this: please create a new Tiddler titled "Typing" and paste 
this bare bones edit-text widget into its body (no need to create any 
additional tiddlers):

<$edit-text tiddler="test"/>

Now open the wiki on mobile, close or fold all tiddlers and navigate to the 
tiddler "Typing". Now, try typing anything. The lag is still there. No 
dependencies, no complex code. The lag persists. In my humble view, there 
is no fix other than an upgrade of the refresh mechanism itself, which is 
part of the core and something that Jeremy is overseeing.

Regards,
Hubert


On Wednesday, 9 October 2019 11:27:30 UTC+1, TonyM wrote:
>
> Hubert,
>
> I stand to be corrected, and will test on mobile myself. Perhaps something 
> I did not make clear I tend to allow edit and view of content through the 
> view template such that there is nothing in the current tiddler that needs 
> refreshing. In my examples of caption and description these are not 
> displayed by rendering the current tiddler but by refreshing the view 
> template, the same ui elements in which you are typing.
>
> If as you suggest it must be a seperate tiddler and I assume undisplayed 
> tiddler, then I potentialy have another solution up my sleeve. However I 
> will examin your argument and mobile use to understand more, before 
> proposing that other method. I only partialy understand the refresh 
> argument but if you can concieve of even a long winded solution to this I 
> think I can simplify it.
>
> I love a seriouse challenge, especialy when it seems imposible. 
>
> regards
> Tony
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/856e3fcb-0ee7-4aa4-8106-ca0611d65618%40googlegroups.com.

[tw5] Re: Typing lag in <$edit-text/> widget

[TonyM]

Hubert,

I stand to be corrected, and will test on mobile myself. Perhaps something I 
did not make clear I tend to allow edit and view of content through the view 
template such that there is nothing in the current tiddler that needs 
refreshing. In my examples of caption and description these are not displayed 
by rendering the current tiddler but by refreshing the view template, the same 
ui elements in which you are typing.

If as you suggest it must be a seperate tiddler and I assume undisplayed 
tiddler, then I potentialy have another solution up my sleeve. However I will 
examin your argument and mobile use to understand more, before proposing that 
other method. I only partialy understand the refresh argument but if you can 
concieve of even a long winded solution to this I think I can simplify it.

I love a seriouse challenge, especialy when it seems imposible. 

regards
Tony

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/532fb5ac-6fe2-44dc-9ddc-d76140896c87%40googlegroups.com.

[tw5] Re: Typing lag in <$edit-text/> widget

[Hubert]

Hi Tony,

Thanks for taking the time to help.

I'm sorry that I didn't make it more clear in my original post (which, I 
admit, is a bit convoluted) -- I'm *not* attempting to type into the 
current tiddler using edit-text as this will of course introduce lag and 
loss of focus. This is a known issue with quite an easy workaround and this 
is *not* something that I'm facing.

Your solutions are clever and well thought out but, I hate to say this, 
they still lag on mobile for the simple fact that having separate tiddlers 
to "write/being written to" is *not a solution, it is a prerequisite*.

The culprit in lagging is in the *widget refresh mechanism*, as I have 
learned through searching this forum in-depth since I made this post. 
Again, this may not be much of a problem on desktops/laptops etc. but it 
does become a major usability problem on mobile.

To reference what my issue is, here's a post 
 
from about 2 years ago brought up by Evan Balster. If I see that correctly, 
no solution has been proposed since then.

I believe that the fix (again, mostly manifesting itself on mobile) would 
involve two things:

   - using separate tiddlers: one containing the edit-text widget, another 
   one being typed into (this one is obvious, though it's a frequent mistake 
   made by TW noobs)
   - the introduction of, perhaps, a *parameter* or a user-adjustable 
   attribute to the edit-text widget 
    that will affect the 
*widget 
   refresh mechanism*, eg. 
   
Tony, again, thank you for your time and for your ideas and I'm sorry that 
I didn't make myself clearer in my original post.

Regards,
Hubert

On Wednesday, 9 October 2019 06:50:48 UTC+1, Birthe C wrote:
>
> Tony,
>
> I found it: 
> https://groups.google.com/d/msg/tiddlywiki/kLqyVrjcJ50/EyawWyGCEQAJ  
> 
>
>
> Birthe
>
> onsdag den 9. oktober 2019 kl. 07.29.14 UTC+2 skrev Birthe C:
>>
>> Tony,
>>
>> I recalled QuickDB because it is field editing in viewmode, and having an 
>> edit-field-list to enter the names that will be the entries in the db.
>> Very lovely when being in a hurry, saving the little details.
>>
>> Birthe
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/12213ff4-43ea-43a3-acd4-8a61eb7f41f0%40googlegroups.com.

[tw5] Re: Typing lag in <$edit-text/> widget

[Birthe C]

Tony,

I found it: 
https://groups.google.com/d/msg/tiddlywiki/kLqyVrjcJ50/EyawWyGCEQAJ  



Birthe

onsdag den 9. oktober 2019 kl. 07.29.14 UTC+2 skrev Birthe C:
>
> Tony,
>
> I recalled QuickDB because it is field editing in viewmode, and having an 
> edit-field-list to enter the names that will be the entries in the db.
> Very lovely when being in a hurry, saving the little details.
>
> Birthe
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/4d52d568-a9a3-467f-b47e-fe1a72c23d02%40googlegroups.com.

[tw5] Re: Typing lag in <$edit-text/> widget

[Birthe C]

Tony,

I recalled QuickDB because it is field editing in viewmode, and having an 
edit-field-list to enter the names that will be the entries in the db.
Very lovely when being in a hurry, saving the little details.

Birthe

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/f7eb9974-37b0-4183-9174-93ef22eff7d4%40googlegroups.com.

[tw5] Re: Typing lag in <$edit-text/> widget

[TonyM]

Birthe C

I had a habit of naming thing quick in the past, but do not recall QuickDB

Yes, Tiddlywiki is a "divergent thinking muse".

Regards
Tony

On Wednesday, October 9, 2019 at 4:02:38 PM UTC+11, Birthe C wrote:
>
> Thank you Tony,
>
> And now I recall. It was you who came up with the QuickDB I am using that 
> one for a lot of stuff now. For years I have tried to get my partner and my 
> best friend to use tiddlywiki. No big luck, I am afraid. QuickDB with a lot 
> of other easy stuff got at least some interest - at least they are now 
> keeping an eye on my Tiddlywiki. (There may be trickery and necessity into 
> that effect also..;-) )
>
> I am a much simpler user, but I really understand what you are saying, 
> being cornered in a TW project. That happens all the time, because we get 
> more ideas than we have time...and it is a never ending story getting even 
> more into it. I think it is a question about how early on the route we get 
> caught up LOL.
>
> Birthe
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/4e3c7bc8-8bc5-444c-92cc-691a408f6bbc%40googlegroups.com.

[tw5] Re: Typing lag in <$edit-text/> widget

[Birthe C]

Thank you Tony,

And now I recall. It was you who came up with the QuickDB I am using that 
one for a lot of stuff now. For years I have tried to get my partner and my 
best friend to use tiddlywiki. No big luck, I am afraid. QuickDB with a lot 
of other easy stuff got at least some interest - at least they are now 
keeping an eye on my Tiddlywiki. (There may be trickery and necessity into 
that effect also..;-) )

I am a much simpler user, but I really understand what you are saying, 
being cornered in a TW project. That happens all the time, because we get 
more ideas than we have time...and it is a never ending story getting even 
more into it. I think it is a question about how early on the route we get 
caught up LOL.

Birthe

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/e888ec3f-bcdf-4fd1-8a2c-94dd4d113d47%40googlegroups.com.

[tw5] Re: Typing lag in <$edit-text/> widget

[TonyM]

Hubert,

If you use the online forum to access Google Groups you can actually edit 
your original post. One idea for collaboration is if you are happy with the 
result update your initial post with the answer you accepted, but leave the 
original intact.

Regards
Tony

On Wednesday, October 9, 2019 at 1:47:00 AM UTC+11, Hubert wrote:
>
> Hello,
>
> Before I go into details, my $:/config/Drafts/TypingTimeout tiddler has a 
> value of 6 (60 seconds), which fixed the lag when entering text / 
> typing in a tiddler in edit mode.
>
> However, I'm still experiencing lag when entering text using <$edit-text/> 
> widgets (of course, the tiddler being populated as I type is separate to 
> the one that has the edit-text widget).
>
> This lag is negligible on my Chromebook or Windows PC (I have no means of 
> measuring it but even if it's 5ms then it's not much to worry about) but it 
> is very noticeable on Android (using Chrome as an example). It gets better 
> if I close all tiddlers except the one that has the <$edit-text/> widget 
> and I assume that the lag has to do with TiddlyWiki re-rendering all the 
> open tiddlers as I type (though I'm not sure if that's the case).
>
> What exactly is introducing the lag when using <$edit-text/> widgets? Is 
> it realtime rendering? If so, could the scope of 
> $:/config/Drafts/TypingTimeout be extended to also include <$edit-text/> 
> widgets, so that the lag is fixed at the expense of instantaneous 
> rendering? Is there any other mechanism that is at fault here? I do not 
> believe that we should require a multicore workstation to have a smooth 
> typing experience.
>
> Typing into a tiddler in edit mode and entering text in a password prompt 
> both work with absolutely no lag on mobile (this is the 'native' typing 
> feel), but these are the only two examples.
>
> The <$range/> widget seems to suffer from the same lag occasionally (it's 
> not super smooth) but I'm not sure if it's affected by the same root cause.
>
> Finally, apologies for awkward phrasing; English is not my first language.
>
> Many thanks,
> Hubert
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/ad39d932-b8f5-4a45-97a0-dedb1643c7a9%40googlegroups.com.

[tw5] Re: Typing lag in <$edit-text/> widget

[TonyM]

Example 2

In a tiddler called CodeTiddler place 
Caption: <$edit-text field="caption" size=80/>

In a tiddler called GlobalMacro tagged $:/tags/Macro place
\define edit-caption() {{||CodeTiddler}}

In any tiddler place
<>


*Notes* 

   - This does not work on the CodeTiddler itself but you can edit the 
   current tiddlers caption field on any other tiddler containing the macro 
   without lag or focus loss.

Regards
Tony

On Wednesday, October 9, 2019 at 2:28:09 PM UTC+11, TonyM wrote:
>
> Here we Go, Example 1
>
> In a tiddler called CodeTiddler place 
> Description: <$edit-text field="description" size=80/>
>
> In a tiddler called "Edit view" tagged $:/tags/ViewTemplate enter
> {{||CodeTiddler}}
> Click on the $:/tags/ViewTemplate tag pill and drag the "Edit view" to 
> above $:/core/ui/ViewTemplate/body
>
> *Notes* 
>
>- This does not work on the CodeTiddler or Edit view themself but you 
>can edit the current tiddlers description field on any other tiddler 
>without lag or focus loss.
>- Fields are created as soon as you enter something (nice fact)
>- Note the use of "||" in the CodeTiddler! this means transclude here 
>with the currentTiddler, otherwise you will edit yourself and it breaks.
>
>
> Regards
> Tony
>
> On Wednesday, October 9, 2019 at 2:10:54 PM UTC+11, TonyM wrote:
>>
>> Birthe,
>>
>> Seriously, I have attempted to a number of times, even create minimal 
>> test case. But have failed. It is easy to get caught in complex loops and 
>> twists where the slightest change breaks it. 
>>
>> I will have another go.
>>
>> Regards
>> Tony
>>
>> On Wednesday, October 9, 2019 at 12:36:19 PM UTC+11, Birthe C wrote:
>>>
>>> Hi Tony,
>>> You seem to have a lot of exiting things going on. Need and curiosity is 
>>> getting the best of me when reading about it. You know curiosity killed the 
>>> cat...and (Do I need to say more...).
>>>
>>> I understand that complexity and lack of time can make it difficult to 
>>> publish the all shining and glamorous solution, but is it not possible in a 
>>> wiki to show us some examples and list the needed tiddlers. That would, I 
>>> am sure, give you some feedback and even suggestions to make it even 
>>> better. Your choice of course.
>>>
>>> All respect for your work,
>>> Birthe
>>>
>>> onsdag den 9. oktober 2019 kl. 00.29.40 UTC+2 skrev TonyM:

 Hubert,

 The lag often occurs when you are editing text or fields in the same or 
 another tiddler that is being rendered in front of your eyes.

 If you can edit values in a tiddler that is not visible this can be 
 eliminated. 

 There are workarounds, and I have built these into a number of 
 sophisticated solutions I have built (not yet published), but while I can 
 hint at how I have done it, I can not possibly document this, because it 
 is 
 annoyingly complex and self referential (that being the problem here).


- Place the edit text in a macro in another tiddler that references 
the current tiddler
- Use a View template to overlay the current tiddler with the edit 
text macros
- something else that is not quite so obvious.

 I have on a number of occasions tried to communicate a need to remedy 
 this by providing a mechanism to reduce the complexity of this practice. I 
 almost always get negative technical responses rather than positive 
 creative solutions. Since I have done it, I know it is possible and 
 workable, that is, it is technically possible, but due to its complexity 
 and my current knowledge, I am not yet ready to publish my solution (I 
 have 
 tried) let alone show how a better mechanism could be designed. It is 
 technically feasible, it is one of tiddlywikis worst features, it needs a 
 solution.

 Regards
 Tony

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/6031db76-065f-4e6f-925b-e7192aaafb00%40googlegroups.com.

[tw5] Re: Typing lag in <$edit-text/> widget

[TonyM]

Here we Go, Example 1

In a tiddler called CodeTiddler place 
Description: <$edit-text field="description" size=80/>

In a tiddler called "Edit view" tagged $:/tags/ViewTemplate enter
{{||CodeTiddler}}
Click on the $:/tags/ViewTemplate tag pill and drag the "Edit view" to 
above $:/core/ui/ViewTemplate/body

*Notes* 

   - This does not work on the CodeTiddler or Edit view themself but you 
   can edit the current tiddlers description field on any other tiddler 
   without lag or focus loss.
   - Fields are created as soon as you enter something (nice fact)
   - Note the use of "||" in the CodeTiddler! this means transclude here 
   with the currentTiddler, otherwise you will edit yourself and it breaks.


Regards
Tony

On Wednesday, October 9, 2019 at 2:10:54 PM UTC+11, TonyM wrote:
>
> Birthe,
>
> Seriously, I have attempted to a number of times, even create minimal test 
> case. But have failed. It is easy to get caught in complex loops and twists 
> where the slightest change breaks it. 
>
> I will have another go.
>
> Regards
> Tony
>
> On Wednesday, October 9, 2019 at 12:36:19 PM UTC+11, Birthe C wrote:
>>
>> Hi Tony,
>> You seem to have a lot of exiting things going on. Need and curiosity is 
>> getting the best of me when reading about it. You know curiosity killed the 
>> cat...and (Do I need to say more...).
>>
>> I understand that complexity and lack of time can make it difficult to 
>> publish the all shining and glamorous solution, but is it not possible in a 
>> wiki to show us some examples and list the needed tiddlers. That would, I 
>> am sure, give you some feedback and even suggestions to make it even 
>> better. Your choice of course.
>>
>> All respect for your work,
>> Birthe
>>
>> onsdag den 9. oktober 2019 kl. 00.29.40 UTC+2 skrev TonyM:
>>>
>>> Hubert,
>>>
>>> The lag often occurs when you are editing text or fields in the same or 
>>> another tiddler that is being rendered in front of your eyes.
>>>
>>> If you can edit values in a tiddler that is not visible this can be 
>>> eliminated. 
>>>
>>> There are workarounds, and I have built these into a number of 
>>> sophisticated solutions I have built (not yet published), but while I can 
>>> hint at how I have done it, I can not possibly document this, because it is 
>>> annoyingly complex and self referential (that being the problem here).
>>>
>>>
>>>- Place the edit text in a macro in another tiddler that references 
>>>the current tiddler
>>>- Use a View template to overlay the current tiddler with the edit 
>>>text macros
>>>- something else that is not quite so obvious.
>>>
>>> I have on a number of occasions tried to communicate a need to remedy 
>>> this by providing a mechanism to reduce the complexity of this practice. I 
>>> almost always get negative technical responses rather than positive 
>>> creative solutions. Since I have done it, I know it is possible and 
>>> workable, that is, it is technically possible, but due to its complexity 
>>> and my current knowledge, I am not yet ready to publish my solution (I have 
>>> tried) let alone show how a better mechanism could be designed. It is 
>>> technically feasible, it is one of tiddlywikis worst features, it needs a 
>>> solution.
>>>
>>> Regards
>>> Tony
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/048dee42-fd95-4a16-a31c-d7605bf9f7be%40googlegroups.com.

[tw5] Re: Typing lag in <$edit-text/> widget

[TonyM]

Birthe,

Seriously, I have attempted to a number of times, even create minimal test 
case. But have failed. It is easy to get caught in complex loops and twists 
where the slightest change breaks it. 

I will have another go.

Regards
Tony

On Wednesday, October 9, 2019 at 12:36:19 PM UTC+11, Birthe C wrote:
>
> Hi Tony,
> You seem to have a lot of exiting things going on. Need and curiosity is 
> getting the best of me when reading about it. You know curiosity killed the 
> cat...and (Do I need to say more...).
>
> I understand that complexity and lack of time can make it difficult to 
> publish the all shining and glamorous solution, but is it not possible in a 
> wiki to show us some examples and list the needed tiddlers. That would, I 
> am sure, give you some feedback and even suggestions to make it even 
> better. Your choice of course.
>
> All respect for your work,
> Birthe
>
> onsdag den 9. oktober 2019 kl. 00.29.40 UTC+2 skrev TonyM:
>>
>> Hubert,
>>
>> The lag often occurs when you are editing text or fields in the same or 
>> another tiddler that is being rendered in front of your eyes.
>>
>> If you can edit values in a tiddler that is not visible this can be 
>> eliminated. 
>>
>> There are workarounds, and I have built these into a number of 
>> sophisticated solutions I have built (not yet published), but while I can 
>> hint at how I have done it, I can not possibly document this, because it is 
>> annoyingly complex and self referential (that being the problem here).
>>
>>
>>- Place the edit text in a macro in another tiddler that references 
>>the current tiddler
>>- Use a View template to overlay the current tiddler with the edit 
>>text macros
>>- something else that is not quite so obvious.
>>
>> I have on a number of occasions tried to communicate a need to remedy 
>> this by providing a mechanism to reduce the complexity of this practice. I 
>> almost always get negative technical responses rather than positive 
>> creative solutions. Since I have done it, I know it is possible and 
>> workable, that is, it is technically possible, but due to its complexity 
>> and my current knowledge, I am not yet ready to publish my solution (I have 
>> tried) let alone show how a better mechanism could be designed. It is 
>> technically feasible, it is one of tiddlywikis worst features, it needs a 
>> solution.
>>
>> Regards
>> Tony
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/f4c48711-ebd9-458b-90fb-95c39823737e%40googlegroups.com.

[tw5] Re: Typing lag in <$edit-text/> widget

[Birthe C]

Hi Tony,
You seem to have a lot of exiting things going on. Need and curiosity is 
getting the best of me when reading about it. You know curiosity killed the 
cat...and (Do I need to say more...).

I understand that complexity and lack of time can make it difficult to 
publish the all shining and glamorous solution, but is it not possible in a 
wiki to show us some examples and list the needed tiddlers. That would, I 
am sure, give you some feedback and even suggestions to make it even 
better. Your choice of course.

All respect for your work,
Birthe

onsdag den 9. oktober 2019 kl. 00.29.40 UTC+2 skrev TonyM:
>
> Hubert,
>
> The lag often occurs when you are editing text or fields in the same or 
> another tiddler that is being rendered in front of your eyes.
>
> If you can edit values in a tiddler that is not visible this can be 
> eliminated. 
>
> There are workarounds, and I have built these into a number of 
> sophisticated solutions I have built (not yet published), but while I can 
> hint at how I have done it, I can not possibly document this, because it is 
> annoyingly complex and self referential (that being the problem here).
>
>
>- Place the edit text in a macro in another tiddler that references 
>the current tiddler
>- Use a View template to overlay the current tiddler with the edit 
>text macros
>- something else that is not quite so obvious.
>
> I have on a number of occasions tried to communicate a need to remedy this 
> by providing a mechanism to reduce the complexity of this practice. I 
> almost always get negative technical responses rather than positive 
> creative solutions. Since I have done it, I know it is possible and 
> workable, that is, it is technically possible, but due to its complexity 
> and my current knowledge, I am not yet ready to publish my solution (I have 
> tried) let alone show how a better mechanism could be designed. It is 
> technically feasible, it is one of tiddlywikis worst features, it needs a 
> solution.
>
> Regards
> Tony
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/db17a623-0cb0-4725-b931-cbb02b069294%40googlegroups.com.

[tw5] Re: Typing lag in <$edit-text/> widget

[TonyM]

Hubert,

The lag often occurs when you are editing text or fields in the same or 
another tiddler that is being rendered in front of your eyes.

If you can edit values in a tiddler that is not visible this can be 
eliminated. 

There are workarounds, and I have built these into a number of 
sophisticated solutions I have built (not yet published), but while I can 
hint at how I have done it, I can not possibly document this, because it is 
annoyingly complex and self referential (that being the problem here).


   - Place the edit text in a macro in another tiddler that references the 
   current tiddler
   - Use a View template to overlay the current tiddler with the edit text 
   macros
   - something else that is not quite so obvious.

I have on a number of occasions tried to communicate a need to remedy this 
by providing a mechanism to reduce the complexity of this practice. I 
almost always get negative technical responses rather than positive 
creative solutions. Since I have done it, I know it is possible and 
workable, that is, it is technically possible, but due to its complexity 
and my current knowledge, I am not yet ready to publish my solution (I have 
tried) let alone show how a better mechanism could be designed. It is 
technically feasible, it is one of tiddlywikis worst features, it needs a 
solution.

Regards
Tony


On Wednesday, October 9, 2019 at 1:47:00 AM UTC+11, Hubert wrote:
>
> Hello,
>
> Before I go into details, my $:/config/Drafts/TypingTimeout tiddler has a 
> value of 6 (60 seconds), which fixed the lag when entering text / 
> typing in a tiddler in edit mode.
>
> However, I'm still experiencing lag when entering text using <$edit-text/> 
> widgets (of course, the tiddler being populated as I type is separate to 
> the one that has the edit-text widget).
>
> This lag is negligible on my Chromebook or Windows PC (I have no means of 
> measuring it but even if it's 5ms then it's not much to worry about) but it 
> is very noticeable on Android (using Chrome as an example). It gets better 
> if I close all tiddlers except the one that has the <$edit-text/> widget 
> and I assume that the lag has to do with TiddlyWiki re-rendering all the 
> open tiddlers as I type (though I'm not sure if that's the case).
>
> What exactly is introducing the lag when using <$edit-text/> widgets? Is 
> it realtime rendering? If so, could the scope of 
> $:/config/Drafts/TypingTimeout be extended to also include <$edit-text/> 
> widgets, so that the lag is fixed at the expense of instantaneous 
> rendering? Is there any other mechanism that is at fault here? I do not 
> believe that we should require a multicore workstation to have a smooth 
> typing experience.
>
> Typing into a tiddler in edit mode and entering text in a password prompt 
> both work with absolutely no lag on mobile (this is the 'native' typing 
> feel), but these are the only two examples.
>
> The <$range/> widget seems to suffer from the same lag occasionally (it's 
> not super smooth) but I'm not sure if it's affected by the same root cause.
>
> Finally, apologies for awkward phrasing; English is not my first language.
>
> Many thanks,
> Hubert
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/927a04cc-aa2e-4835-bd03-ee5fd2055320%40googlegroups.com.