Re: [tw] Re: [TW5] Request: Refresh Delay in edit-text widget

Hi Jeremy, Because the mechanism works on draft tiddlers, and there’s no draft tiddler > involved when you use the edit-text widget directly. So, could we perhaps introduce a single state tiddler to... - store the information of any edit-text widget instance given focus - store the text

Re: [tw] Re: [TW5] Request: Refresh Delay in edit-text widget

@Jeremy, Now, I'm a little confused, again. Sorry. With this... I'd urge you to examine the implementation of the existing refresh > dampening mechanism: > > https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/startup/render.js ...how come this delay works well with the preview

Re: [tw] Re: [TW5] Request: Refresh Delay in edit-text widget

Hi Tobias > So, could we perhaps introduce a single state tiddler to... > store the information of any edit-text widget instance given focus > store the text being edited in it > only commit the text back to the tiddler (field) after the edit delay passed? You’re circling around the same point

Re: [tw] Re: [TW5] Request: Refresh Delay in edit-text widget

Hi Tobias > ...how come this delay works well with the preview in edit mode > but not when I edit a field of the current tiddler in view-mode? Because the mechanism works on draft tiddlers, and there’s no draft tiddler involved when you use the edit-text widget directly. Best wishes Jeremy.

Re: [tw] Re: [TW5] Request: Refresh Delay in edit-text widget

Hi Jeremy, > We’ve discussed this before: it’s why the existing mechanism defers the > refresh cycle, and doesn’t try to defer updating the value of the tiddler. > If we managed to dynamically rebind the input to a state tiddler during editing — rather than the tiddler which we look at —

Re: [tw] Re: [TW5] Request: Refresh Delay in edit-text widget

I'll get around to finishing the message I drafted two weeks ago here... I see a lot of sense in Jeremy's point about always editing the Tiddler store directly, and I won't contest that. My main objection to the tag / field approach to refresh delay is that the delay isn't a descriptor of the

Re: [tw] Re: [TW5] Request: Refresh Delay in edit-text widget

Hi Tobias > > So, what could be done is extending these bits so as to: > >1. also delay refreshing for (certain, perhaps state / temp) tiddlers >instead of just drafts, e.g. those storing a search-terms > - those tiddlers could perhaps simply have a tag >

[tw] Re: [TW5] Request: Refresh Delay in edit-text widget

I can see people focusing on delaying the write to the tiddler store where the actual problem, in my opinion, is the refresh of the widget tree. >From my point of view, for consistency we should keep the changes to the tiddler store immediate, and focus in adding a delay to the refresh

[tw] Re: [TW5] Request: Refresh Delay in edit-text widget

Hi Danielo, > I can see people focusing on delaying the write to the tiddler store where > the actual problem, in my opinion, is the refresh of the widget tree. > From my point of view, for consistency we should keep the changes to the > tiddler store immediate, and focus in adding a delay to

Re: [tw] Re: [TW5] Request: Refresh Delay in edit-text widget

Hi Evan > >1. The user's direct interaction initiates all changes to the state of >the tiddler store -- or at least the vast majority of changes. >2. The user's interaction with editor widgets can change the state of *at >most* one tiddler at a time. (I understand this does not

Re: [tw] Re: [TW5] Request: Refresh Delay in edit-text widget

Hi Jeremy, > I'd urge you to examine the implementation of the existing refresh > dampening mechanism: > > https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/startup/render.js > > Mhhh, now I feel mildly stupid. o.O Half of what I am rambling on about is already there. Will

Re: [tw] Re: [TW5] Request: Refresh Delay in edit-text widget

Hi Tobias Here's how I would interpret possible refresh-delay settings... > > *delay: 300ms* > >- after an update, do not refresh for 300ms >- after those 300ms only refresh so long as the triggering widget did >not fire another refresh event > > *max-delay: 2s* > >- if the user

Re: [tw] Re: [TW5] Request: Refresh Delay in edit-text widget

Hi Evan > So the source of objection to this feature is that the data might be erased if the containing widget tree is refreshed within that small interval of time? I would consider that acceptable... I don't think random, hard to find data loss is at all acceptable. The basic design of

Re: [tw] Re: [TW5] Request: Refresh Delay in edit-text widget

Hi Evan, Jeremy, I am beginning to wonder, can't a focused editor put some kind of write-lock to the field being edited? That way it's pretty clear that when some other place tries to apply changes, that it can't ...and react accordingly. Best wishes, — tb -- You received this message

Re: [tw] Re: [TW5] Request: Refresh Delay in edit-text widget

Hey, Jeremy -- The other day I picked through the code to ascertain what would be necessary to implement a refresh delay setting in $edit-text and friends. It looks like a time value would need to percolate through a few abstractions: - State Modifying Widgets - Add a new "delay"

[tw] Re: [TW5] Request: Refresh Delay in edit-text widget

On Tuesday, September 22, 2015 at 9:09:31 PM UTC+2, Evan Balster wrote: > > However, based on a quick look at the code, I can speculate about two ways > of implementing this change that do not involve storing editor state in the > widget tree: > >1. Have a field other than "draft.of" which

Re: [tw] Re: [TW5] Request: Refresh Delay in edit-text widget

Hi Evan On Wed, Sep 23, 2015 at 8:21 PM, Evan Balster wrote: > The other day I picked through the code to ascertain what would be > necessary to implement a refresh delay setting in $edit-text and friends. > Great stuff, there's a lot to navigate there. > >- State

Re: [tw] Re: [TW5] Request: Refresh Delay in edit-text widget

Haha, well, my motivations are selfish -- I'm working on an interactive application which is having responsiveness issues due to the current updating behavior. My proposal relies on a few assumptions, which may be faulty: 1. The user's direct interaction initiates all changes to the state

[tw] Re: [TW5] Request: Refresh Delay in edit-text widget

Hmm... Reading through the old topic. So the source of objection to this feature is that the data might be erased if the containing widget tree is refreshed within that small interval of time? I would consider that acceptable... However, based on a quick look at the code, I can speculate

[tw] Re: [TW5] Request: Refresh Delay in edit-text widget

Hi Evan, > Is there any way refresh delay could be implemented as a setting of the > edit-text widget? > For now there's only this... *#1494 refresh delay for text input fields* https://github.com/Jermolene/TiddlyWiki5/issues/1494 Best wishes, — tb -- You received this message because

[tw] Re: [TW5] Request: Refresh Delay in edit-text widget

Hi Evan, Tbh, I never quite grasped the problem of the delay with respect to the refresh cycle, as you can possibly infer from that issue's discussion thread. If a widget is destroyed before it can submit its state, then it's gone. If it is refreshed before it can submit its state, the editing