Unable to undo delete

Here’s a not so nice undo bug:

  1. Type some text really fast in Scriveners main document window (you can even just type junk)
  2. Press backspace to delete text immediately after you’ve stopped typing text
  3. Stop when about half the typed text has been deleted and press cmd-Z (undo)
  4. Scrivener removes all written text
  5. Press cmd-shift-z (redo)
  6. Scrivener redoes the text you didn’t delete, but nothing more (extra cmd-shift-z will do nothing), the deleted text is lost forever

I’d like Scrivener to restore the deleted text at step 4, not delete more text. Undo should undo what you did, in the reverse order you did it and nothing else.

If that’s somehow not possible or not wanted, I’d like to be able to undo my deletion somehow, perhaps with an extra redo to get the deleted text back (when I press cmd-shift-z again in step 6).

This problem exists in several other applications, so it may not even be Scrivener that’s at fault, but I don’t know if you use a faulty module or a faulty algorithm (it exists in Windows as well), so I start here…

That’s the key. I’ve run your example in TextEdit and found the same result. Seeing as how both Scrivener for macOS and TextEdit use the same underlying text engine and accompanying undo system, something of that nature would be too deep to fix. If you used Safari to post here, you might have observed the same behaviour there. In Firefox I don’t, but Firefox doesn’t use the Mac frameworks for its UI components inside the browsing area. Likewise I wouldn’t expect Word or an Adobe product to be identical (though they might), as they also use their own systems.

I’d imagine on Windows/Linux the situation is much the same, only there it would be the Qt framework providing the undo mechanism.

I don’t disagree with you to be clear. I like Firefox’s undo model better than the Mac’s in part because it would record this sequence of events with the result you are describing. It does still chunk typing events together for ease of use, you don’t have to step through each keypress individually like a reverse video of your typing, but deletion events like this are considered undo level events.

In native Mac software, small typo corrections are smoothed over in the algorithm, while larger deletions are be stored. It just has a slightly larger granularity that Firefox. Delete some letters and type over them, that’s not recorded. But if you opt-delete the mistyped word and retype it, that event will be stored in memory (both the deletion and the replacement). Likewise using Shift to select text in conjunction with Opt or Cmd is considered an undo event.

Thanks for the reply!

I had a suspicion that this was a “faulty” module since it happens elsewhere (I’ve seen it in Windows and Linux as well).

I guess I could file a bug report against TextEdit and see what Apple comes up with…

…if that’s the same module that Scrivener uses?

They both use NSTextView, the common editing component that you’ll find in varying levels of complexity through all native Mac software. TextEdit is essentially just a very basic UI over the editor component, and that is why it is useful to double-check editor related bugs with that.

Thanks! It seems you have to have a developer ID to file bugs, but I did at least send them feedback on the issue.

It would probably weigh heavier with the Apple people if a developer reported a bug, and even more so a developer of such a successful software as Scrivener (wink wink) :smiley: