4 ms·
> Leaving version control up to the user isn't the worst, but it does mean that it won't be straightforward to put an "undo" in the GUI (if the GUI already has
by eridius 11y ago
> Leaving version control up to the user isn't the worst, but it does mean that it won't be straightforward to put an "undo" in the GUI (if the GUI already has undo somehow I'd like to hear how they do it).
The GUI does have an Undo, and it works exactly as you expect: it reverts changes made in the GUI app. If you have a note open and you make an external change, the app will at some point notice the change and ask you if you want to reload; if you say yes, it reloads from disk and throws away the undo history. I was able to get it to reload content without realizing it changed (by editing the note, then closing it in Quiver before it detected the change and reopening) and this didn't throw away the undo history, which seems like just a fairly simple bug.
Or to put it more generally, Undo works in Quiver pretty much the same way you'd expect it to work in any editor that can reload files that change on disk; the undo history simply doesn't concern itself with undoing changes made outside of the app, and in most cases reloading the file from disk throws away undo history.
- seagreen 11y agoOh, that makes sense! So it's exactly like Vim (with noswapfile turned on) or any other program that tracks history at the application-level, but doesn't write it to the directory you're working in.
- m_mueller 11y agoSublime seems to work very well in the case you describe: The changes coming in from a reload are simply put into the undo history just like any other change. No need to throw anything away.