Understanding The Undo Function

I don’t quite follow which actions can be undone and which cannot. It seems that many things I do accidentally cannot be undone.

For example, moving an item to another database, renaming an item, adding a new item. All these cannot be undone. This is confusing because I’m used to hitting cmd-z for as many times as I want to undo actions, and doing that actually revert things I’ve done before that.

Is there a way to make “undo” work like I expect it to? Or do I have to get used to this?

Regards,
Alex

[original reply was not useful]

Well, just undo everything I did :smiley:. I am still exploring the many options I have, just now for example I tried “unify” (“vereinigen”). Something happend but I was not sure what. I am trying things because I have the German version of DT but the documentation is in English, so I have troubles finding explanations for the functions.

Other things I tried are “split document” or “use as name”. Tried it - but had to revert the results manually. It happened several times during the last days, probably because there is a dozen ways to create or rename a document.

So I just have to live with it, right? Well, as a first lesson I learned not to hit cmd-z but open the menu first to see what will be undone.

Undo/Redo not applying to renaming (and certain other actions) can make it hard to anticipate how it will behave in that context.

I’m still checking there, more frequently than I’d like, when DT’s Undo behavior seems unintuitive and unpredictable. Related comment (from a related topic):

Some apps are more thorough than others about dynamically/contextual appending explanatory text to the Undo/Redo menu items, e.g. “Undo Typing”. I’d like to see DT’s be improved, especially in cases where it’s likely the outcome may seem counterintuitive.

Generally, DT’s Undo/Redo usage requires more mindful effort for me than in other apps. Too often I’ve thought/expected to undo the most recent action but instead ended up undoing some earlier one.

I’ve been trying to be conscious of my usage of undo and maybe today I can explain better what yesterday was more a feeling:

With DT I have to take mental notes of the actions I took, for example:
Did I create a replicate? Then I can undo. Did I duplicate? Then not. Did I move? Good. But was it in the same database? No! Will this action (split, combine, convert, …) create a new document? No undo! Am I going to rename that file, better look twice at the current name so I can restore it later, just in case. And so on.

With the Finder, for example, no thinking at all. I can delete, move, copy, no matter if to the same or another disc or partition, rename etc. I don’t care if I moved or renamed, internal or external drive, if it was a link or a copy or an alias. When thinking: “oh - three steps ago, did I drop the right file at the correct place?”, I can simply hit cmd-z three times and am back to where I was.

I think intuitive usage is a good word to describe it. I hope that my comparison with the Finder helps to understand what I mean.

Regards,
Alex

You seem to be trying to explain what I was trying to in my reply, Alex.

Some more troubles I have with undo:

  • text edits can’t be undone after saving. I think this should really be possible.
  • when editing texts and undoing all the changes (before saving it), the modification date is changed even though the document has not been modified at all.

To revert the changed modification date, I’m exporting the document, set the date with “touch -mt” and import it again. Is there an easier way to do this within DevonThink?

1 Like

Not sure I agree with that; there are reasonable arguments both for and against it.

I couldn’t reproduce that when editing a RTF document, but this bug still exists:

[i]• Undo of all edits doesn’t clear the the modified state

When a text document is edited, either in a pane or separate window, the dark dot in the red gumdrop still indicates the document is modified after undoing all changes. Closing a separate window after undoing all changes in it brings up the “Do you want to save changes …?” dialog unnecessarily.
[/i]

I think this is related. I was always working in one window in the triple pane view and never (really!) got to see this “do you want to save…” dialogue. Interesting enough, I found three different behaviours on exiting without saving after an edit:

  1. If I work with one tab only, as soon as I navigate elsewhere, the document is saved automatically. Whether the modifications have all been undone or not. This was what I described earlier.

  2. However, when editing in multiple tabs, it’s different: closing the tab does not save the document, even if there were actual changes. The red dark dot shows but the tab just closes.

  3. When I edit the document in a separate window, I get the behaviour you describe (with a dialogue). This is the one I would prefer if I had to choose between the three.

I tried it with a web archieve and a RTF, not sure if I tested all combinations. The dark red dot stays in all three cases after undoing everything.

An easily reproducible bug in that context is DT still considering the document as modified even after undoing all edits.

I believe you, but couldn’t figure out how to reproduce that.

Are you saying you’d want that dialog to appear when editing in panes similarly to how it currently appears when editing in windows?

I usually edit in separate windows so unintended changes can be discarded, without updating the document modification date/time after full undos.

Yep, full undo doesn’t clear its “change indicator” state.

Here’s how I did it:

Go to the 3 pane view. Open one document (I chose a pdf). Ctrl- or right-click on a web archive, “open in tab”. Switch to this second tab. Edit the document. Close current tab by clicking the “(X)”. All changes to the second tab are lost.
I did this in the inbox of my active database, if that makes a difference.

When closing an unsaved document I can only think of the options to autosave, or to autodiscard the changes, or to ask the user. The problem with the first two options is that neither of them is right at all times - but if the action was unwanted, it cannot be reverted (remember: no undo here :wink: ).

So I would vote for a dialogue, yes. Practically I guess this means that I have to get used to working with windows.

Do you mean select a document that displays its content in the bottom-right pane? To me “open” means open in a separate window.

There’s “Open In Tabs…” in the context menu.

There’s only an ‘x’ for the selected/current tab. Closing that saves changes and the original tab (with pending changes, if any) is selected. I can’t figure out any combination of editing/selecting/closing that loses changes.

Apparently not; I tried this within Inbox of an open db.

I’m not a DT tab user so maybe I’ve gotten something wrong. When originally trying them it confused me that the document selection didn’t change when selecting different tabs. In other words, a selected document and tab pane content can be easily mismatched.

And prompting to save/discard changes made in panes would definitely annoy plenty of users.

I lock certain documents to avoid accidental modifications, trying not to make choosing which are/aren’t lock-worthy too tedious.

And that’s one of those contexts where Undo usage may have unexpected/unwanted results. “Whoops - a document I moved before several other actions just returned to its original location”.

I normally type Command-O when intending to edit a document in the window it opens in.

It’s still too easy for input focus to land in a content pane and accidentally make a change that can’t be full undone (because of the unnecessary modtime update). I’ve written plenty about these types of navigation/focus problems in DT, increasingly losing motivation after seeing no significant sign of improvements.

Good tip, I’ll keep that in mind.

Considering that your comments on this topic are years old, I prefer to pause the discussion here until someone from DevonTech shows interest. I suppose that’s in your interest, too.

Also, Data > Reveal (Command-R) can be useful in a separate document window if you want to (re)open/locate its parent group window/view.

Yup, further discussion just between us about specific Undo/Redo issues (which we generally agree on anyway) doesn’t seem productive without Dtech’s intervening feedback.

For starters, I’d be satisfied if that “Undo of all edits doesn’t clear the the modified state” bug I reported over fours years ago and reminded them again of here would finally be fixed. :slight_smile: