| Project: | Mori |
| Version: | 1.2.1 |
| Component: | User interface |
| Category: | bug |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
In previous discussions, Jesse has said that in some circumstances Mori requires you "to undo twice" and "needs more refinement", and has even explained the technical aspects of the problem, but currently undo is somewhere on the scale between unpredictable and annoying (at best) and risking data loss (at worst). So for Jesse's convenience, I thought I'd collect the examples that've been posted, put them in a single issue/bug report, and open the floor for votes or additional examples:
- Most of concern: Text moved via Entry > Move To cannot be un-moved and may be lost if focus has changed to a different note and will be lost if Undo is hit too many times. Specifically: Create new folder X, create child note Y, enter note text HELLO. Select this text and select Entry > Move to > X. (HELLO is now a sibling note to X.) Select another folder or note (other than X or Y). Hit undo (no effect), hit undo again. HELLO disappears; Y remains empty. Hit undo again. Y loses its title. Hit undo again. Y is moved leftware. Hit undo again. Y disappears. HELLO?
- Also very concerning: After a link is created and then clicked on, the link cannot be undone. In and of itself, this isn't a big deal, but an unsuspecting user might continue repeatedly selecting 'undo' waiting for the link to be undone, thereby unknowingly undoing and losing actual work on other notes.
- Less harmful but definitiely annoying: To undo a "New Entry" requires 2 undos. It has been shown that 4 new entries can even require 5 or 8 clicks to undo. This was also brought up here.
- Undo sometimes causes icon to change: I can't replicate this one, but it's still open here
Now, in most programs, undo is a tricky beast; undo doesn't work after a file is closed and reopened, etc. But Mori's undo is oddly out of sync with discreet user actions. Usually, just hitting undo until what you want undone is gone is fine, but these examples show that sometimes what you want undone will never be undone, and in fact all the undoing is destroying other data.
Updates
I think most (except for the need for hitting undo multiple times) of these problems are not really Mori bugs, but confusion in Mori's interface. Unless I'm misunderstanding I don't think you can actually lose data in any of these cases. I'll try to explain what is happening.
The key issue is that Mori maintains separate undo stacks for each note. it also maintains another single undo stack for all other mori changes, such as creating/moving/changing attributes of entries. I think what is happening in those cases where you can't undo something is that you are asking the wrong part of Mori's interface to undo.
The trick is that to undo edits to an entries note you need to have that entry selected and the text view needs to have focus.
So in the case of X and Y you can select entry Y, move focus to text view, and then undo. The hello text should reappear.
It should be the same for links. The link should be undoable, but only if the text view that the link is displayed in has focus.
The icon thing, and multiple undo's required thing are bugs, but the multiple thing in particular has been difficult to track down.
In my mind Mori's undo behavior is mostly correct. (i went to a lot of work to have different undo buffers for each note :) ), but obviously I could do a better job of explaining it. Any ideas of how, where I should do that?
| Title: | Beware 'Undo' | » Hi-Fi Undo |
Hi Jesse,
Ahha, I see. The focus determines which undo buffer is being operated on. I was also thrown off in all these examples because (of course) undoing a new note takes two hits. So I think if you are able to get Mori to undo 'File > New Entry' with one undo, we'll be maybe 50% better, but not 100% better. What would make it 100% better? It's 'Hi-Fi Undo', i.e. high fidelity in reversing any command:
*** The user should be able to undo any single command with a single undo -- whether the command is executed through a menu or via keyboard shortcut. ***
Now, for example, if I select text inside a note and execute the command "Entry > Move to > [another folder]", a single undo should (1) put that text back in the original note and (2) delete the new entry. Currently, only (1) happens; further undos end up undoing other text that had already been typed into the note. (That's just screwey!) Multiple actions may have occurred, but that's not the way the user perceives (or should have to perceive) it.
Another example: If I select text inside a note and execute "Entry > Move copy to > [another folder]", the first undo does nothing, the second undo undoes typed before. The copy remains! (!) The only way to undo the copy is to select the Sources View and hit undo twice!
So, basically: Just as a recursive Replace All command can be undone with a single undo, so should any command that affects the notebook's contents.
Once 'hi-fi undo' is achieved and made sacred, users will finally be able to leverage the hard work you put into the robust undo buffer system. I think a brief page in the Users Guide entitle 'How Undo Works in Mori' would suffice. You could also delineate when Mori won't be able to guarantee it - i.e. possibly in the case of some service menu commands and most certainly with scripts.
p.s. And eventually when Mori has a little WriteRoom button, undo should retain its buffers whether a note is being edited in WriteRoom or the main window. That would be one kickin' way to make the tie-in between Mori and WriteRoom extra-special, wouldn't it?
| Status: | active | » closed |
Undo should be working much better in Mori 1.3. I'm going to close this issue, if you find new problems please post a new issue.