[IDEA] Last saved timestamp and what it may enable

[AnthonyMuscio]

Is your feature request related to a problem? Please describe.
If we return to a TiddlyWiki in a tab after some time it is not possible to establish when it was last saved. This makes some solutions impossible to implement.

Describe the solution you'd like
The addition of a tiddler similar to $:/info/startup-timestamp perhaps named $:/info/save-request-timestamp which is updated with a Tiddlywiki serial number date/timestamp before saving just after the save button is selected OR Autosave is actioned but before the save takes place.

The name "save-request-timestamp" is selected intentionally to reflect the fact if the save is not completed due to user intervention or a failure to save it does not misrepresent the timestamps meaning.

Describe alternatives you've considered
Building my own package using message catcher or event catcher widgets but always needing to install it in a wiki before it becomes available is inconvenient. The tm-save-wiki is defined within a javascript module.

The value of such a timestamp is increased if it is reliably available in all wikis we come across. For example it allows us to determine how long since an update was applied (the wiki was saved) by the author.

Additional context
Having the save-request-timestamp provides information that can support

• Identifying the age since last updated
• Allow timed saves to be triggered after a period of time since last saved
• Determine for how long the wiki has being open since loading $:/info/startup-timestamp and/or since it was last saved.
• With publicly accessible sites it indicates to the Author the last update published time.
• Possibly trigger an action if a given wiki is found unsaved for an extended period. eg: Auto check in, retry checkout, refresh external content and more.
• Possibly warn the user if they attempt to save a Wiki they have had open in there browser for an extended period so they do not save a stale copy.
• Use in conjunction with the Local storage plugin which does not set/reset $:/info/save-request-timestamp identify how long has passed since a save committed local storage changes to disk.
  • Perhaps local storage could set its own last saved timestamp as long as it succeeds.
• Be able to list tiddlers created modified since last save ie created/modified > $:/info/save-request-timestamp which is different to [haschanged[]]
• If the loaded and saved timestamps are available we can determine by comparing them
  • Loaded > Saved - No changes saved since loaded
  • Saved > Loaded - Changes made since loading in this window/tab
  • And both can be compared and or relative date with now

Related features;
If it were possible to confirm the save but if it fails restore the last value in $:/info/save-request-timestamp and provide information in the wiki eg; set a flag eg "Save mechanisium XYZ failed at timestamp"

• Store information about the specific "save mechanism" that completed the successful save process.

If it were possible to detect a user returning to a tab and trigger an action it would be possible programmatically compare "now" with loaded and saved timestamps and trigger further smart actions.

• For example if no changes since last saved/loaded reload the whole wiki from disk if its older than 1 hour to retrieve possible updates.

[pmario]

If it were possible to detect a user returning to a tab and trigger an action it would be possible programmatically compare "now" with loaded and saved timestamps and trigger further smart actions.

• For example if no changes since last saved/loaded reload the whole wiki from disk if its older than 1 hour to retrieve possible updates.

I'm in favour of adding this info, because I think it can be used to create "information" or even "actions" that can support the user.

But

I personally don't want any program to be "smart". Most of the time the "automatic" behaviour is just annoying over time.

Information, that the user should probably "reload" the tab can help, to avoid "overwritten content" but it has to be "subtle". Especially if there are tiddlers, that haven't been saved yet.

@Jermolene I think it would be interesting to see, what users come up with, if we implement this info tiddler

[AnthonyMuscio]

A related discussion that would complement this issue, is here https://talk.tiddlywiki.org/t/action-on-return-to-tiddlywiki/3281?u=tw_tones

When a user returns focus to a tab in which the tiddlywiki resides the ability to trigger actions to introgate the last saved time in this issue and other values will allow wikis to respond to there own state.

• for example identify there is nothing to save and was loaded 2 days ago then reload from file to retrive changes.

[AnthonyMuscio]

To provide a "Last Saved Timestamp" in an $:/Info tiddler as specified in this issue requires additional actions on save-wiki.

Another approach to this is to provide a way for the designer to choose one or more actions to trigger before save-wiki and set the $:/info/save-request-timestamp as per the request.

The reason I raise this is, in hindsight this more open solution would allow, on save-wiki, for other actions to be introduced such as clear the $:/status/UserName or "check out".

@pmario I personally don't want any program to be "smart". Most of the time the "automatic" behaviour is just annoying over time.

• Yes this may give people "enough rope to hang themselves" but it makes possible things that are currently not possible or bespoke with core edit.
• By providing the mechanism we at least know where to look to find it, if such a hack is causing problems.

Smart use of these features would typically be

• transparent or
• generate an appropriate prompt explaining what is occurring
  • but not when repeated eg not on autosave
• Be able to be defeated with a setting

[Jermolene]

Hi @AnthonyMuscio I agree, a timestamp tiddler on saving is a good idea.

There is a question of where it should go; $:/info tiddlers are automatically generated by the system at startup, whereas this timestamp behaves more like an ordinary tiddler in that it is loaded into the tiddler store from the HTML file at startup.

Perhaps $:/state/saving/timestamp, which would mean that it would be saved in the single file configuration but not synced in the client-server configuration.

Note that it is already possible to use a filter to determine whether any tiddlers have changed since the last save with something like this:

[haschanged[]] -[prefix[$:/state/]] -[prefix[$:/temp/]] -[prefix[$:/StoryList]] -[prefix[$:/HistoryList]]

[AnthonyMuscio]

Yes I agree $:/state/saving/timestamp is a good name.

Note that it is already possible to use a filter to determine whether any tiddlers have changed since the last save with something like this:

[haschanged[]] -[prefix[$:/state/]] -[prefix[$:/temp/]] -[prefix[$:/StoryList]] -[prefix[$:/HistoryList]]

Yes, I am aware of this. but there are few cases where this is not enough. An example may be with multiple saves without changes.

Because the save-wiki actions are triggered by autosave and the button, would it be possible to trigger some custom action on save wiki should someone want to extend this feature? We could use this mechanism to set the $:/state/saving/timestamp but leave it available to be hacked.

Can someone else please detail the necessary change on this occasion?, it would take me too much time than I can spare this week, and I am a little unclear how to tackle $:/core/modules/saver-handler.js

[pmario]

I did just prepare a PR for a $:/state/saving/timestamp tiddler, which will contain a unix TIMESTAMP value. So it can be directly compared with a match or gt, lt, eq operators.

BUT there is a usecase which can't be resolved with the state tiddler alone.
Eg:

• 2 tabs are opened using the same wiki
• both wikis have "autosave" disabled
• So there may be new tiddlers in the wiki-store but the state has the same timestamp

IMO this can't be resolved with a state tiddler by it's own.

As a second step I was thinking about https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API .. So 2 open tabs from the same origin could show some info, if there is something going on.

So the mechanism now stores the "save timestamp" in unix format in the stat-tiddler _and
is also stores a sha256() of "tiddler title" + "TW timestamp" ...

So it's possible to compare 2 wikis even if they have "autosave" off.

Just some thoughts atm. PR on the way

[pmario]

see:

[saqimtiaz]

I think a more flexible affordance to invoke actions before saving via tagged tiddlers would be preferable, and would also satisfy the OP.

For instance I would like to update a tiddler before the wiki is saved, specifying when and where a backup was last saved.

[pmario]

hmm. At the moment the whole thing is done with 8 lines of code, because I did add 4 new-lines for better readability
plus 2 lines of code for a new utility sha256() function

As I wrote

As a second step I was thinking about https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API .. So 2 open tabs from the same origin could show some info, if there is something going on.

So we need a base functionality, which we can rely on. Since every wiki has to understand it. Custom actions using custom tiddlers imo will cause problems here.

At the moment the saver-handler.js gets its parameters from: tm-save-wiki and tm-download-file

Those messages are created with download or save button and keyboard widgets

For consistency, I think if "custom actions" are needed, they should be usable there too ... Which in turn would be a completely new scope for the whole PR.

[pmario]

For instance I would like to update a tiddler before the wiki is saved, specifying when and where a backup was last saved.

@saqimtiaz Could you be more specific here?

[saqimtiaz]

We need to think more broadly and not focus only on particular use cases.

Wherever possible we should avoid blackbox behaviour and implement new features in a transparent and flexible manner in wikitext.

In this scenario we should look at extending saver-handler to invoke actions before a saver is invoked. If necessary, we can also introduce some default actions in the core that are executed at this time.

Long term I can imagine we might eventually want to refactor portions of saver-handler as wikitext, including offering affordances for end users to transparently see and change the relative priority of savers.

[pmario]

@saqimtiaz .. The idea now is to

• create a new tag eg: $:/tags/PreSaveActions because it will be activated prior to the save action.
• Every tiddler tagged: $:/tags/PreSaveActions contains 1 or more actions. ... Nothing else

• Testing is extra important so it needs to be easy. eg:

<$wikify name="test-actions" text="{{{ [all[shadows+tiddlers]!has[draft.of]tag[$:/tags/PreSaveActions]get[text]] }}}" mode=block>
  <$button actions=<<test-actions>> >create state tiddlers</$button>
</$wikify>

There is a POC ZIP for testing: create-state-saving-tiddlers-poc-plus-testing.zip

The ZIP doesn't contain any core code, just some code that will land in the docs, so users have the possibility to test their actions.

What do you think about the structure? Is it flexible enough for your usecases

IMO the main advantage is, that we don't need to modify any save-buttons or keyboard shortcut codes.

[saqimtiaz]

@pmario the idea behind $:/tags/PreSaveActions sounds good. I'm on the road with only a phone until Wednesday. If you post a draft PR I can review the code, otherwise I won't be able to provide feedback until Wednesday at the earliest.

I imagine we would want to use the same mechanism as startup actions. Off the top of my head I believe the widget method is invokeActionsByTag.

[AnthonyMuscio]

I can't follow all the replies here but being the initiator of a few comments;

• Single file wikis, We need a reliable last saved timestamp that is ideally very close to that on the filename, however that "whole of wiki" save was triggered (Manual or automatic or keyboard) including when downloaded to a new filename.
  • perhaps detecting a filename/path change would be of use? eg last saved time + last saved time / filepath recorded.
• One advantage of this is we can then determine the age since last saved and
  • introduce "time out behaviours" eg; Changes exist and have not being saved for a day, give different treatment.
• The use of a tag for Actions on save is ideal since it is the trigger to save that is important to capture whether manual, automatic or keyboard.

[pmario]

perhaps detecting a filename/path change would be of use? eg last saved time + last saved time / filepath recorded.

That's not possible. The browser doesn't give us any info about the directory or file info. And it would also be too late. The browser save dialogue is activated when the new wiki has already been compiled.

[pmario]

@AnthonyMuscio, @saqimtiaz .. The preview version was created: https://tiddlywiki5-git-fork-pmario-record-state-savin-654a0f-jermolene.vercel.app/#PreSaveActions

It also contains 2 new doc tiddlers

[AnthonyMuscio]

Thanks for your effort and preview version

perhaps detecting a filename/path change would be of use? eg last saved time + last saved time / filepath recorded.

That's not possible. The browser doesn't give us any info about the directory or file info. And it would also be too late. The browser save dialogue is activated when the new wiki has already been compiled.

Mario, I am aware of the limitation when it comes to local files and post save dialogue, even if I change the destination of the save during the save dialogue its happening after pre-save anyway.

This reply gives an example of the OT "Last saved timestamp and what it may enable" but arguably could now me reworded to "Pre-save actions and what they may enable (including last saved time stamp)".

Take your preview wiki, look at $:/info/url/full and $:/info/url/pathname, now lets say we store these in seperate tiddlers during pre-save, then we "save as" to a local file location. To see use the wiki you saved, it must be loaded in a browser tab now look at $:/info/url/full and $:/info/url/pathname again, and compare with the saved values. They have changed.

• Arguably this could be workable without pre-save actions however it is the appropriate "just in time" nature of the pre-save actions that is useful.
• There are other ways to glean or make use of other information at pre-save that once we have the hackability we can innovate.

Your link here looks interesting but I do not understand your vision with this.

As a second step I was thinking about https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API .. So 2 open tabs from the same origin could show some info, if there is something going on.

• In a similar vein introducing "get and set window name" would allow the save process to store the browser tab/target/window name in the wiki and a start up action could "disable save" if the same wiki, at the same path/filename and NOT the same window name is loaded (unless an intervention is made).
• This can be made even more robust by also saving the browser in use at save eg; $:/info/browser/name and $:/info/browser/version
  • There is still the gap if the same browser is opened twice and the same wiki in the same window name

I will start another issue for this Get and Set window name