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

[Evan Balster]

There's a lovely TiddlyWiki feature called refresh delay
<http://tiddlywiki.com/#Hidden%20Setting%3A%20Typing%20Refresh%20Delay>
which makes preview mode usable by inducing a brief lag between the latest
keypress and the refreshing of the wiki. (If we transclude the content of
a draft tiddler, it can be seen that this affects the wiki globally.)

I'm currently working on a wiki with a fairly complex dataflow (it's a
modular automated character sheet for role-playing games) and I notice that
my <$edit-text> widgets always trigger a refresh with every keypress. The
same is true of the TW5 search bar, and as a result it's possible for each
of these to become very unresponsive when typing if there's a lot of
information to process.

Is there any way refresh delay could be implemented as a setting of the
edit-text widget?

[Tobias Beer]

Hi Evan,

Post by Evan Balster
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

[Evan Balster]

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 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 marks a tiddler as a "draft"
for the purposes of refresh time.
2. Modify the "change" event listener receive an optional parameter for
the timeout associated with any given change, allowing any source of
changes to define its own timeout value.

#1 could be implemented quickly by changing this line
<https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/startup/render.js#L75>
of the render code to something like:

if(!tiddler || !tiddler.hasField("draft.of") || !
tiddler.hasField("refresh.slow")) {

#2 is a system-wide change and I really don't know enough about TiddlyWiki
to speculate what it would take. I'll await Jeremy's input on this point.

Post by Tobias Beer
Hi Evan,

Post by Evan Balster
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

[Tobias Beer]

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 state should be gone or the widget should figure that it it is
unrelateable via some hash.
If the data it is editing is changed in the store
before it commits the next keypress, so be it.

When the widget finally gets to commit the updated data,
that's what it will do, insofar as it is still able to do so.

Best wishes,

— tb

[PMario]

Post by Evan Balster
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
1. Have a field other than "draft.of" which marks a tiddler as a
"draft" for the purposes of refresh time.
2. Modify the "change" event listener receive an optional parameter
for the timeout associated with any given change, allowing any source of
changes to define its own timeout value.
#1 could be implemented quickly by changing this line
<https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/startup/render.js#L75>
if(!tiddler || !tiddler.hasField("draft.of") || !
tiddler.hasField("refresh.slow")) {

What if you just add a field "draft.of" to your temporary input tiddler.
There would be no need to change the core and it's easy for you to add the
field to your code.

-m

[Jeremy Ruston]

Hi Evan

Post by Evan Balster
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 TiddlyWiki has to be robust, I think.

Anyhow, #1494 rather endlessly repeats the reasons why the originally
proposed solution doesn't work within the context of TiddlyWiki's design.

The best solution to the problem is to extend the existing refresh
dampening mechanism as you propose. Using a field like "refresh.slow" as
you suggest is nice and quick, but may be a bit restrictive. One
alternative would be to consult $:/config/refreshdelay/<tiddlertitle>, but
of course that would be rather expensive, adding a store lookup for every
changed tiddler.

Best wishes

Jeremy.

Post by Evan Balster

Post by Evan Balster
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
1. Have a field other than "draft.of" which marks a tiddler as a
"draft" for the purposes of refresh time.
2. Modify the "change" event listener receive an optional parameter
for the timeout associated with any given change, allowing any source of
changes to define its own timeout value.
#1 could be implemented quickly by changing this line
<https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/startup/render.js#L75>
if(!tiddler || !tiddler.hasField("draft.of") || !
tiddler.hasField("refresh.slow")) {

What if you just add a field "draft.of" to your temporary input tiddler.
There would be no need to change the core and it's easy for you to add the
field to your code.
-m
--
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
Visit this group at http://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/d1e6e6e0-7b4e-4b15-aa3e-8a49afb83a06%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/d1e6e6e0-7b4e-4b15-aa3e-8a49afb83a06%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

--
Jeremy Ruston
mailto:***@gmail.com

[Evan Balster]

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" property, and possibly means to fall back to
default values
- Store this property in the AddTiddler hashmap
- AddTiddler microkernel function
- Extract the delay property from the hashmap argument
- Pass the property to enqueueTiddlerEvent
- enqueueTiddlerEvent wiki.js function
- Accept the delay property as a third argument
- Add this property to the data for the change event
- - "change" event handler
- Extract the delay property from the event argument and schedule delay

One nice thing about this approach is that it would no longer be necessary
to check for draft tiddlers in the change event handler -- instead, the
editor widgets in the EditTemplate would simply assign a delay value.
Probably the most obtrusive element of this solution is that the parameter
of the change event would need to be redefined as a hashmap... It looks as
if there is a lot of code that handles that event, and I don't know enough
about TiddlyWiki to identify other possible datapaths for the delay
variable.

If multiple change events are aggregated, it would be sensible to use the
*lowest* delay value associated with any of them for scheduling purposes.

...Anyway, at this point I'm feeling as if I could try my hand at this
modification -- but I might end up out of my depth as I'm not a JavaScript
expert. Jeremy, let me know if this scheme sounds remotely sensible.

Post by Tobias Beer
Hi Evan

Post by Evan Balster
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 TiddlyWiki has to be robust, I think.
Anyhow, #1494 rather endlessly repeats the reasons why the originally
proposed solution doesn't work within the context of TiddlyWiki's design.
The best solution to the problem is to extend the existing refresh
dampening mechanism as you propose. Using a field like "refresh.slow" as
you suggest is nice and quick, but may be a bit restrictive. One
alternative would be to consult $:/config/refreshdelay/<tiddlertitle>, but
of course that would be rather expensive, adding a store lookup for every
changed tiddler.
Best wishes
Jeremy.

Post by Evan Balster

Post by Evan Balster
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
1. Have a field other than "draft.of" which marks a tiddler as a
"draft" for the purposes of refresh time.
2. Modify the "change" event listener receive an optional parameter
for the timeout associated with any given change, allowing any source of
changes to define its own timeout value.
#1 could be implemented quickly by changing this line
<https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/startup/render.js#L75>
if(!tiddler || !tiddler.hasField("draft.of") ||
!tiddler.hasField("refresh.slow")) {

What if you just add a field "draft.of" to your temporary input tiddler.
There would be no need to change the core and it's easy for you to add the
field to your code.
-m
--
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
<javascript:>.
Visit this group at http://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/d1e6e6e0-7b4e-4b15-aa3e-8a49afb83a06%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/d1e6e6e0-7b4e-4b15-aa3e-8a49afb83a06%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

--
Jeremy Ruston

[Tobias Beer]

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

[Jeremy Ruston]

Hi Evan

Post by Evan Balster
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.

Post by Evan Balster
- State Modifying Widgets
- Add a new "delay" property, and possibly means to fall back to
default values
- Store this property in the AddTiddler hashmap
- AddTiddler microkernel function
- Extract the delay property from the hashmap argument
- Pass the property to enqueueTiddlerEvent
- enqueueTiddlerEvent wiki.js function
- Accept the delay property as a third argument
What would it do if the same tiddler were written twice with different

delays specified?

Post by Evan Balster
- Add this property to the data for the change event
- - "change" event handler
- Extract the delay property from the event argument and schedule delay
I think this proposal essentially duplicates an existing mechanism, but is

not as well encapsulated. Here you have logic in the render.js change
handler, and in the wiki store. The apparent benefit is that the caller
gets to control the delay, but at a great cost: the change event handler
must keep track of a whole bunch of delays, rather than just one. The
caller doesn't in fact have control over the delay because of competition
with other code writing to the same tiddler (including the core).

It feels much neater to make the delay be a concern of the main render
module. The need for these delays is a user interface concern, and
shouldn't be a part of the store.

(Just to be clear that none of this negates the need to extend the existing
mechanism so that we can defer refresh for tiddlers other than the usual
draft tiddlers).

Post by Evan Balster
One nice thing about this approach is that it would no longer be necessary
to check for draft tiddlers in the change event handler -- instead, the
editor widgets in the EditTemplate would simply assign a delay value.

Surely lots of different delay values?

Post by Evan Balster
Probably the most obtrusive element of this solution is that the parameter
of the change event would need to be redefined as a hashmap... It looks as
if there is a lot of code that handles that event, and I don't know enough
about TiddlyWiki to identify other possible datapaths for the delay
variable.

Since the end of the beta the interfaces within TiddlyWiki have been
constrained to backwards compatibility. It's actually not that much of a
constraint, one can usually fix things by adding rather than changing or
taking away.

Post by Evan Balster
If multiple change events are aggregated, it would be sensible to use the
*lowest* delay value associated with any of them for scheduling purposes.

This again means that the caller has even less control than indicated by
the interface. There are two places where the specified delays are
aggregated.

Post by Evan Balster
...Anyway, at this point I'm feeling as if I could try my hand at this
modification -- but I might end up out of my depth as I'm not a JavaScript
expert. Jeremy, let me know if this scheme sounds remotely sensible.

I welcome contributions but would urge you to consider having a go at
something less speculative and therefore controversial. I think there are a
lot of popular issues on GitHub that are amenable to a fix by anyone with
the time, and of course I'll always be happy to advise when I can.

Best wishes

Jeremy.

Post by Evan Balster

Post by Tobias Beer
Hi Evan

Post by Evan Balster
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 TiddlyWiki has to be robust, I think.
Anyhow, #1494 rather endlessly repeats the reasons why the originally
proposed solution doesn't work within the context of TiddlyWiki's design.
The best solution to the problem is to extend the existing refresh
dampening mechanism as you propose. Using a field like "refresh.slow" as
you suggest is nice and quick, but may be a bit restrictive. One
alternative would be to consult $:/config/refreshdelay/<tiddlertitle>, but
of course that would be rather expensive, adding a store lookup for every
changed tiddler.
Best wishes
Jeremy.

Post by Evan Balster

Post by Evan Balster
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
1. Have a field other than "draft.of" which marks a tiddler as a
"draft" for the purposes of refresh time.
2. Modify the "change" event listener receive an optional parameter
for the timeout associated with any given change, allowing any source of
changes to define its own timeout value.
#1 could be implemented quickly by changing this line
<https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/startup/render.js#L75>
if(!tiddler || !tiddler.hasField("draft.of") ||
!tiddler.hasField("refresh.slow")) {

What if you just add a field "draft.of" to your temporary input tiddler.
There would be no need to change the core and it's easy for you to add the
field to your code.
-m
--
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
Visit this group at http://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/d1e6e6e0-7b4e-4b15-aa3e-8a49afb83a06%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/d1e6e6e0-7b4e-4b15-aa3e-8a49afb83a06%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

--
Jeremy Ruston

--
Jeremy Ruston
mailto:***@gmail.com

[Evan Balster]

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 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 apply to
triggering widgets!)

You make a strong case that editor widgets should not have state
independent of the store, to avoid conflicts in or loss of data. This
makes sense to me. I also agree that delay is a feature of the interface /
UX design, and it is my view that the degree of delay should be a function
of the *means* by which the information is changed, rather than *what*
information is changed -- hence the proposal that it be a feature of the
instigating widgets.

The question then becomes how the editor widgets can communicate to the
renderer that the changes they have instigated should be delayed. There
needs to be a means of associating the changes (which the renderer receives
as event notifications from the store) with the specific source and delay
value. If assumption 2 is correct, only a single delay value need be set
per change.


What would it do if the same tiddler were written twice with different

Post by Jeremy Ruston
delays specified?

I don't have a strong understanding of the situations where this might
occur, other than a keypress followed by another keypress (which should
reset the delay).

Post by Jeremy Ruston
Hi Evan

Post by Evan Balster
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.

Post by Evan Balster
- State Modifying Widgets
- Add a new "delay" property, and possibly means to fall back to
default values
- Store this property in the AddTiddler hashmap
- AddTiddler microkernel function
- Extract the delay property from the hashmap argument
- Pass the property to enqueueTiddlerEvent
- enqueueTiddlerEvent wiki.js function
- Accept the delay property as a third argument
What would it do if the same tiddler were written twice with different

delays specified?

Post by Evan Balster
- Add this property to the data for the change event
- - "change" event handler
- Extract the delay property from the event argument and schedule delay
I think this proposal essentially duplicates an existing mechanism, but

is not as well encapsulated. Here you have logic in the render.js change
handler, and in the wiki store. The apparent benefit is that the caller
gets to control the delay, but at a great cost: the change event handler
must keep track of a whole bunch of delays, rather than just one. The
caller doesn't in fact have control over the delay because of competition
with other code writing to the same tiddler (including the core).
It feels much neater to make the delay be a concern of the main render
module. The need for these delays is a user interface concern, and
shouldn't be a part of the store.
(Just to be clear that none of this negates the need to extend the
existing mechanism so that we can defer refresh for tiddlers other than the
usual draft tiddlers).

Post by Evan Balster
One nice thing about this approach is that it would no longer be
necessary to check for draft tiddlers in the change event handler --
instead, the editor widgets in the EditTemplate would simply assign a delay
value.

Surely lots of different delay values?

Post by Evan Balster
Probably the most obtrusive element of this solution is that the
parameter of the change event would need to be redefined as a hashmap...
It looks as if there is a lot of code that handles that event, and I don't
know enough about TiddlyWiki to identify other possible datapaths for the
delay variable.

Since the end of the beta the interfaces within TiddlyWiki have been
constrained to backwards compatibility. It's actually not that much of a
constraint, one can usually fix things by adding rather than changing or
taking away.

Post by Evan Balster
If multiple change events are aggregated, it would be sensible to use the
*lowest* delay value associated with any of them for scheduling purposes.

This again means that the caller has even less control than indicated by
the interface. There are two places where the specified delays are
aggregated.

Post by Evan Balster
...Anyway, at this point I'm feeling as if I could try my hand at this
modification -- but I might end up out of my depth as I'm not a JavaScript
expert. Jeremy, let me know if this scheme sounds remotely sensible.

I welcome contributions but would urge you to consider having a go at
something less speculative and therefore controversial. I think there are a
lot of popular issues on GitHub that are amenable to a fix by anyone with
the time, and of course I'll always be happy to advise when I can.
Best wishes
Jeremy.

Post by Evan Balster

Post by Tobias Beer
Hi Evan

Post by Evan Balster
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 TiddlyWiki has to be robust, I think.
Anyhow, #1494 rather endlessly repeats the reasons why the originally
proposed solution doesn't work within the context of TiddlyWiki's design.
The best solution to the problem is to extend the existing refresh
dampening mechanism as you propose. Using a field like "refresh.slow" as
you suggest is nice and quick, but may be a bit restrictive. One
alternative would be to consult $:/config/refreshdelay/<tiddlertitle>, but
of course that would be rather expensive, adding a store lookup for every
changed tiddler.
Best wishes
Jeremy.

Post by Evan Balster

Post by Evan Balster
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
1. Have a field other than "draft.of" which marks a tiddler as a
"draft" for the purposes of refresh time.
2. Modify the "change" event listener receive an optional
parameter for the timeout associated with any given change, allowing any
source of changes to define its own timeout value.
#1 could be implemented quickly by changing this line
<https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/startup/render.js#L75>
if(!tiddler || !tiddler.hasField("draft.of")
|| !tiddler.hasField("refresh.slow")) {

What if you just add a field "draft.of" to your temporary input
tiddler. There would be no need to change the core and it's easy for you to
add the field to your code.
-m
--
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
Visit this group at http://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/d1e6e6e0-7b4e-4b15-aa3e-8a49afb83a06%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/d1e6e6e0-7b4e-4b15-aa3e-8a49afb83a06%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

--
Jeremy Ruston

--
Jeremy Ruston

[Jeremy Ruston]

Hi Evan

Post by Evan Balster
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 apply to
triggering widgets!)
That's not quite right. Firstly, some user actions might trigger an

asynchronous change to the store - for example, triggering the loading of a
lazily loaded tiddler. Second, changes made by other users in multi-user
scenarios are planned to automatically ripple to other connected browsers.
Third, imagine a clock plugin that just sets $:/currentTime every 1s to the
current time. That would make it easy to display an automatically updating
clock or timer in any required format, and would lead to asynchronous
changes to the tiddler store.

You make a strong case that editor widgets should not have state

Post by Evan Balster
independent of the store, to avoid conflicts in or loss of data. This
makes sense to me. I also agree that delay is a feature of the interface /
UX design, and it is my view that the degree of delay should be a function
of the *means* by which the information is changed, rather than *what*
information is changed -- hence the proposal that it be a feature of the
instigating widgets.

I understand the motivation, but as I mentioned above I think it's hard for
such a system to offer any solid guarantees as to how the specified delay
will be treated.

Post by Evan Balster
The question then becomes how the editor widgets can communicate to the
renderer that the changes they have instigated should be delayed. There
needs to be a means of associating the changes (which the renderer receives
as event notifications from the store) with the specific source and delay
value. If assumption 2 is correct, only a single delay value need be set
per change.

The problem here is how one coalesces adjacent updates. But I maintain that
the fundamental mistake to couple the operation of the tiddler store to the
user interface concerns of how we handle refreshing. Remember that the
refresh cycle is not intrinsic to the tiddler store; it's built on top of
the mechanisms that it provides.

Best wishes

Jeremy.



What would it do if the same tiddler were written twice with different

Post by Evan Balster

Post by Jeremy Ruston
delays specified?

I don't have a strong understanding of the situations where this might
occur, other than a keypress followed by another keypress (which should
reset the delay).

Post by Jeremy Ruston
Hi Evan

Post by Evan Balster
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.

Post by Evan Balster
- State Modifying Widgets
- Add a new "delay" property, and possibly means to fall back to
default values
- Store this property in the AddTiddler hashmap
- AddTiddler microkernel function
- Extract the delay property from the hashmap argument
- Pass the property to enqueueTiddlerEvent
- enqueueTiddlerEvent wiki.js function
- Accept the delay property as a third argument
What would it do if the same tiddler were written twice with different

delays specified?

Post by Evan Balster
- Add this property to the data for the change event
- - "change" event handler
- Extract the delay property from the event argument and schedule delay
I think this proposal essentially duplicates an existing mechanism, but

is not as well encapsulated. Here you have logic in the render.js change
handler, and in the wiki store. The apparent benefit is that the caller
gets to control the delay, but at a great cost: the change event handler
must keep track of a whole bunch of delays, rather than just one. The
caller doesn't in fact have control over the delay because of competition
with other code writing to the same tiddler (including the core).
It feels much neater to make the delay be a concern of the main render
module. The need for these delays is a user interface concern, and
shouldn't be a part of the store.
(Just to be clear that none of this negates the need to extend the
existing mechanism so that we can defer refresh for tiddlers other than the
usual draft tiddlers).

Post by Evan Balster
One nice thing about this approach is that it would no longer be
necessary to check for draft tiddlers in the change event handler --
instead, the editor widgets in the EditTemplate would simply assign a delay
value.

Surely lots of different delay values?

Post by Evan Balster
Probably the most obtrusive element of this solution is that the
parameter of the change event would need to be redefined as a hashmap...
It looks as if there is a lot of code that handles that event, and I don't
know enough about TiddlyWiki to identify other possible datapaths for the
delay variable.

Since the end of the beta the interfaces within TiddlyWiki have been
constrained to backwards compatibility. It's actually not that much of a
constraint, one can usually fix things by adding rather than changing or
taking away.

Post by Evan Balster
If multiple change events are aggregated, it would be sensible to use
the *lowest* delay value associated with any of them for scheduling
purposes.

This again means that the caller has even less control than indicated by
the interface. There are two places where the specified delays are
aggregated.

Post by Evan Balster
...Anyway, at this point I'm feeling as if I could try my hand at this
modification -- but I might end up out of my depth as I'm not a JavaScript
expert. Jeremy, let me know if this scheme sounds remotely sensible.

I welcome contributions but would urge you to consider having a go at
something less speculative and therefore controversial. I think there are a
lot of popular issues on GitHub that are amenable to a fix by anyone with
the time, and of course I'll always be happy to advise when I can.
Best wishes
Jeremy.

Post by Evan Balster

Post by Tobias Beer
Hi Evan

Post by Evan Balster
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 TiddlyWiki has to be robust, I think.
Anyhow, #1494 rather endlessly repeats the reasons why the originally
proposed solution doesn't work within the context of TiddlyWiki's design.
The best solution to the problem is to extend the existing refresh
dampening mechanism as you propose. Using a field like "refresh.slow" as
you suggest is nice and quick, but may be a bit restrictive. One
alternative would be to consult $:/config/refreshdelay/<tiddlertitle>, but
of course that would be rather expensive, adding a store lookup for every
changed tiddler.
Best wishes
Jeremy.

Post by Evan Balster

Post by Evan Balster
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
1. Have a field other than "draft.of" which marks a tiddler as a
"draft" for the purposes of refresh time.
2. Modify the "change" event listener receive an optional
parameter for the timeout associated with any given change, allowing any
source of changes to define its own timeout value.
#1 could be implemented quickly by changing this line
<https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/startup/render.js#L75>
if(!tiddler || !tiddler.hasField("draft.of")
|| !tiddler.hasField("refresh.slow")) {

What if you just add a field "draft.of" to your temporary input
tiddler. There would be no need to change the core and it's easy for you to
add the field to your code.
-m
--
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
Visit this group at http://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/d1e6e6e0-7b4e-4b15-aa3e-8a49afb83a06%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/d1e6e6e0-7b4e-4b15-aa3e-8a49afb83a06%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

--
Jeremy Ruston

--
Jeremy Ruston

--
Jeremy Ruston
mailto:***@gmail.com

[Danielo Rodríguez]

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
mechanism.

Regards

[Tobias Beer]

Hi Danielo,

Post by Danielo Rodríguez
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
mechanism.

Seeing as how the computation of any filtered search results are only
brought about through the refresh mechanism, if I understand correctly,
then this sounds ok to me. Same for a live-preview. The user would be
typing and commiting to the tiddler store instantaneously, but any preview
or updates elsewhere would only refresh and propagate once the user has
stopped typing for a given time.

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 has managed to accumulate delays for 2s, do a refresh
anyway

Best wishes,

— tb

[Jeremy Ruston]

Hi Tobias

Here's how I would interpret possible refresh-delay settings...

Post by Tobias Beer
*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 has managed to accumulate delays for 2s, do a refresh
anyway

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

If I've not been clear enough, I am against introducing a new mechanism to
achieve the same thing as an existing mechanism. The only choice is to
adapt the existing mechanism. I don't see why that is a problem; it works
well, and avoids the problems I've pointed out above. The only thing we
need to improve is the way that dampened tiddlers are configured.

Best wishes

Jeremy.

Post by Tobias Beer
Best wishes,
— tb
--
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
Visit this group at http://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/812f1bbd-c354-41d6-af96-795d2fcc3157%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/812f1bbd-c354-41d6-af96-795d2fcc3157%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

--
Jeremy Ruston
mailto:***@gmail.com

[Tobias Beer]

Hi Jeremy,

Post by Jeremy Ruston
I'd urge you to examine the implementation of the existing refresh
https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/startup/render.js
<javascript:>

Mhhh, now I feel mildly stupid. o.O
Half of what I am rambling on about is already there.
Will re-read the issue thread on github, again.
Not sure, how I missed that.
Sorry for the latency.

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
*$:/tags/DelayRefresh* or some field *tw-refresh-delay:2*
2. implement a *max-refresh-delay*
- seems rather straight forward, using two timers eventually
canceling each other out
- the max-timer not being cleared, though

Do you see problems with 1. or 2.?

Best wishes,

— tb

[Jeremy Ruston]

Hi Tobias

Post by Tobias Beer
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
*$:/tags/DelayRefresh* or some field *tw-refresh-delay:2*

Yes, I think that agrees with the proposal we've started with - see my
comments above "refresh.slow".

Post by Tobias Beer
1. implement a *max-refresh-delay*
- seems rather straight forward, using two timers eventually
canceling each other out
- the max-timer not being cleared, though

There's no maximum delay at the moment with the draft handling. If the user
keeps typing, the refresh is deferred until there's a pause of 400ms, or a
non-draft tiddler is modified. I think the only situation where a maximum
delay would be needed would be if the user were typing for a sustained
period. I think it's reasonable that screen updates are suspended until the
typing ends.

Best wishes

Jeremy.


Do you see problems with 1. or 2.?

Post by Tobias Beer
Best wishes,
— tb

--
Jeremy Ruston
mailto:***@gmail.com

[Tobias Beer]

@Jeremy,

Now, I'm a little confused, again. Sorry.

With this...

I'd urge you to examine the implementation of the existing refresh

Post by Evan Balster
https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/startup/render.js

...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?

<$edit-text field="foo"/>

Best wishes,

— tb

[Jeremy Ruston]

Hi Tobias

Post by Tobias Beer
...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.

Post by Tobias Beer
<$edit-text field="foo"/>
Best wishes,
— tb

[Tobias Beer]

Hi Jeremy,

Because the mechanism works on draft tiddlers, and there’s no draft tiddler

Post by Jeremy Ruston
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 being edited in it
- only commit the text back to the tiddler (field) after the edit delay
passed?

Best wishes,

— tb

[Jeremy Ruston]

Hi Tobias

Post by Tobias Beer
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 that we generally end up at!

The problem with the approach you’ve outlined is that while an edit is deferred the only copy of the edited text is that within the DOM node. But any parent widget of that DOM node is free to destroy the widget tree containing it, and reconstruct it. That loses the deferred state.

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.

Best wishes

Jeremy.

Post by Tobias Beer
Best wishes,
— tb
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
Visit this group at http://groups.google.com/group/tiddlywiki <http://groups.google.com/group/tiddlywiki>.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/200f09a2-4450-4b3a-94b5-6cf6b86b4aa0%40googlegroups.com <https://groups.google.com/d/msgid/tiddlywiki/200f09a2-4450-4b3a-94b5-6cf6b86b4aa0%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

[Tobias Beer]

Hi Jeremy,

Post by Jeremy Ruston
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 — then no refresh of the
tiddler we look at should take place (while typing). But yes, the moment
after the delay when we refresh the current tiddler we still have the
problem of re-focusing the widget that got destroyed at the position we
were when editing. However (!), the state tiddler that we use to store the
edited text could (perhaps) via some qualify identifier be used to store a
reference to the editing widget and thus a widget could check upon creation
if it is that widget and steal the focus back.

Best wishes,

— tb

[Evan Balster]

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
data being changed. To attach that data to a persistent tiddler would mean
associating ephemeral data with long-term information. This is
particularly unintuitive if it must be applied by hand.

To review, the basic UX problem is that it feels very bad when >250ms of
processing delay the response to each keystroke in an edit-box. The
necessary solution involves a query within the rendering mechanism that
determines a quantity of delay to be associated with a given change.
Ideally this solution should be as similar to the existing one as possible.

Within the architectural constraints discussed so far, we could:

1. Add associative state to data which should be delayed, such as a tag,
or slow.refresh field (where the latter could specify a millisecond
value). Editor widgets would apply these tags or fields in addition to
normal changes.
2. Have a global state tiddler, like "$:/Delay", governing the render
mechanism, which describes which tiddlers should be refresh-delayed at any
given moment. Editor widgets would modify this state tiddler if delay is
specified.
3. Use some datapath not involving the tiddler store to communicate a
list of delayed changes between the editor widgets and the rendering
mechanism.

I would tend to prefer (2) because it's simple, avoids the associativity
issue and also seems like it would be easier to "clean up" when the refresh
goes through. In most cases there would only be one delayed item (because
only one editor widget is typically be used at a time) so it doesn't seem
like the performance hit from parsing the refresh state would be too bad
either.

...But of course this is all relatively uninformed opinion. Interested in
your thoughts, Jeremy.

Regards,
Evan

Post by Tobias Beer
Hi Jeremy,

Post by Jeremy Ruston
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 — then no refresh of the
tiddler we look at should take place (while typing). But yes, the moment
after the delay when we refresh the current tiddler we still have the
problem of re-focusing the widget that got destroyed at the position we
were when editing. However (!), the state tiddler that we use to store the
edited text could (perhaps) via some qualify identifier be used to store a
reference to the editing widget and thus a widget could check upon creation
if it is that widget and steal the focus back.
Best wishes,
— tb
--
You received this message because you are subscribed to a topic in the
Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/tiddlywiki/hlIvXE6jRys/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
Visit this group at http://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/c14303fa-7379-4f19-bb34-53766451dee4%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/c14303fa-7379-4f19-bb34-53766451dee4%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.