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 <edit-text/> >> 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 60000, 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 60000 doesn't seem to impact the >>>>>>> speed with regular editing nor inside a form box. >>>>>>> >>>>>> >>>>>> Have you reloaded the wiki after setting it to 60000? 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 60000 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 60000. 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 60000 (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 [email protected] <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywiki/fe01d5db-9694-480a-bb2a-bd0625a0812e%40googlegroups.com > > <https://groups.google.com/d/msgid/tiddlywiki/fe01d5db-9694-480a-bb2a-bd0625a0812e%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/67558afd-142a-4d2b-9e4f-d888727b5409%40googlegroups.com.
