Yes! I think your technical explanation is also correct. Basically if I type b here: a|c (pipe represents the cursor), then the browser immediately updates the DOM value to abc, but Elm update brings it back to ab (in accordance with the model that didn’t change yet). Then the time message comes in (probably in the next animation frame as you suggested) and the text input gets the final final value of abc. Kind of back and forth. From the browser’s perspective the last two updates are not triggered by input event and this must be throwing off the cursor.
If this is correct then only two ways to prevent it is to either make Time.now synchronous (probably impossible) or update the model in the first pass of the update and later update the version.
I really like the solution suggested by @eike (and in part @rupert). In fact I can delay the whole timestamp business until the user exports the document (in my case it’s either uploading it to the server or downloading a file).
So all I need to do is count the changes since the document was loaded. And since I don’t even care about how many times it was changed, only that it was, I can represent the version as Maybe Time.Posix where Nothing indicates that the document was modified since last export. And when the document is exported check if it was modified (version == Nothing). If so, then update the version before it’s saved. If it’s Just version then keep it as it was.
This should also improve performance when typing - only one update per keystroke!
Thank you all your input. It will help me to model my program better!