cursor movements caused the loss of the redo history

[shenguhan]

 This is really bothersome, Is there some way to make the undo history only track  text editing?   

[chrisant]

I find this very frustrating as well.  In my opinion it means SlickEdit essentially does not have a Redo feature.

I have not found any way to exclude cursor movement from the Undo history.

[ScottW, VP of Dev]

Setting def_undo_with_cursor to 1 should "enable the undo of each cursor movement". When set to 0, which is the default, it appears to treat all cursor movements in a sequence as one operation. Setting it to 1 allows you to undo each, individual cursor movement. It sounds like we need another value to completely exclude cursor movement from the undo stack.

If we do that, how should undo/redo work? Would it undo/redo the changes at the location they were made or at the current cursor location? If we undo/redo at the original location, doesn't that imply a cursor movement? It seems like undo should undo the change at the original location, but redo would make the same change at the new location. Does that sound right?

Can you describe a series of edits and how you would like this to work. I'm sorry if I sound thick, but I want to make sure I precisely understand the behaviors you want so I can file the change and get it right. Obviously, we're missing an important behavior and we must not think it's terribly obvious or we would have added it by version 14. 

[evanratt]

I can say that for my use, what I would like to see would be the changes undone/redone at the location they were originally made. My use scenario is this:
1. Make an edit
2. Undo that edit
3. Navigate elsewhere in the file, to look at something
4. Change my mind, decide I want the edit I had originally made.
In the current implementation, once I navigate elsewhere in step 3 to check something else, I can no longer change my mind and redo my original edit.

It doesn't seem natural to me to expect redo to ever redo an operation somewhere other than the original location; if I were looking to use redo to repeat an action in this way, I would be inclined to record and execute a temporary macro.

[jbhurst]

I think that this improved redo idea has merit, and I believe there may be other actions that inappropriately lose undo/redo in SlickEdit (can't recall them right now).

However, I have always been one of the users that appreciates the ability to undo cursor movement. I use this all the time. Please don't break it! :-)

John Hurst
Wellington, New Zealand

[chrisant]

If we do that, how should undo/redo work? Would it undo/redo the changes at the location they were made or at the current cursor location? If we undo/redo at the original location, doesn't that imply a cursor movement? It seems like undo should undo the change at the original location, but redo would make the same change at the new location. Does that sound right?

Can you describe a series of edits and how you would like this to work. I'm sorry if I sound thick, but I want to make sure I precisely understand the behaviors you want so I can file the change and get it right. Obviously, we're missing an important behavior and we must not think it's terribly obvious or we would have added it by version 14. 

Ah, I get your question, that had never occurred to me.
I would expect both Undo and Redo to always undo/redo the change in its original location, and move the cursor to whereever it was as of that change.

Overall I am very happy with the SlickEdit Undo model:  I have def_undo_with_cursor set to 0, and I found that I actually really like that the cursor movement is in the undo stack.

The trouble comes with the symmetry in the Redo model:  if I press Undo and then for example hit End or scroll to see the end of a line (or any other cursor movement) then that cursor movement discards the content redo stack.

I guess that what I'm intuitively expecting is some kind of a partial differentiation between content redo and cursor redo after I've hit Undo, but only until I make a content change.

Here is an example:
1.  Type "hello" press Enter
2.  Type "big" press Enter
3.  Type "world" press Enter
4.  Press Undo ("world" disappears cursor moves to after the Enter from step 2)
5.  Press Up twice (cursor is now on "hello")
6a.  If I press Undo, I want the cursor to go back to where it was after step 4
6b.  Or if I press Redo, I really expect "world" to reappear and the cursor to go to where it was after step 3
6c.  Or if I type something, then I expect the redo stack to get cleared -- but not until I actually make a content change.

Does that make sense?  My reasoning is that content is much more important than cursor movement, and it seems undesirable to discard the more important content redo stack just because I did some kind of cursor movement.

I should soften my original statement -- it's not that SlickEdit has no Redo feature, it's just that my fingers insist on making cursor movements and the Redo stack is almost always empty by the time I decide I need to Redo.

[shenguhan]

I think the best way is to add a Goto Last/Next Edit Location function, separate cursor movement records from Redo/Undo functions.

[Graeme]

I've tried 3 other editors and they all do what chrisant has described - as soon as you change content, the redo history is cleared and not before.  Microsoft Word also does that but it has an additional feature which is that when there's nothing to redo, the redo command/shortcut changes into "repeat last change".

I still use undo cursor quite often to take me back to the place I last made a content change (despite having xretrace), so I hope that capability doesn't disappear.

Graeme

[myk]

I posted something about this a couple of years back (http://community.slickedit.com/index.php?topic=2253.0).  Returning to SlickEdit over 2 years later, I'm sorry to see it still hasn't been addressed.

ScottW, if you want to see the sort of behaviour I'd prefer, look at Kate in KDE/Kubuntu, TextPad or Word or Visual Studio in Windows, or just vim.  I'm actually surprised there's this level of confusion over a pretty common behaviour.  And for the record, I'm not saying there shouldn't be an option to include cursor movements in the undo stack.  (On the occasions where I do want to return to my previous edit point without reverting the edit, I just undo then redo immediately.)

The cursor movement thing would mostly just be a nuisance, except that it completely breaks the redo history, as shenguhan said.  There's another problem with SlickEdit's undo behaviour, but I'll put that in a separate post.

[pdebonte]

myk wrote:
> where I do want to return to my previous edit point without reverting the edit, I just undo then redo immediately.

I do the same, and like everything in a consistent GUI (e.g. MS Windows), I do it instinctively [e.g. how many of you actually read most dialogs before hitting OK or Cancel?].  With SlickEdit, however, my instincts fail so often it is frustrating [and in the case of Ctrl-Arrow, I'd even call it aggravating, but I've remapped those now].  If an application is going to do something counter to every other application out there, I think it had better at least provide an option to follow the standard.

-Pete

P.S. - I see I now have negative Hero points: does that mean I have villain points? Oh well.

[ScottW, VP of Dev]

Hmm, "villain points". I like the sound of that. Maybe if you accumulate enough of them you can achieve Evil Genius status. Then you would be allowed to recruit henchfolk (my proposed alternative to the sexist term, "henchmen").

As for the undo history, change requests have been filed, but I doubt this will be changed any time soon. It's one of those cases where amending the current implementation is unsavory. I think Clark would like to redo our undo mechanism.

[pektusin]

Any progress on that? It is a very serious bug, really annoying. You edit your file a lot, then want to look how it was before the changes, one mouse click - and history is gone! I consider SE as an editor w/o undo/redo and it spoils overall editor impression very much.

[volovyan]

SlickEdit 2011 - almost unable to use because of this issue. Redo history is gone; now I have to save a file after each and every change to not have to type it again should an accidental cursor movement occurred after undo.

[Phil Barila]

Take a look at Tools->Options->Editing->Cursor Movement->"Undo affects cursor movement".  Set to True or False?  Mine is set to False, I haven't tried it set to True.  I think it might be the switch that combines all cursor movements without any edits into one "Undo Cursor Movement" operation, which effectively makes it a "Go back to the site of the last edit".

I think it would be a major improvement if SE would behave like many other apps and divorce cursor movement from content changes. 

On the other hand, I've actually used Ctrl+Z to undo a cursor movement.

What I would really like is a separate "Undo/Redo cursor movement", independent of "Undo/Redo edits".

[volovyan]

I tried setting it to True, doesn't help.
Here is the problem: you type something (e.g. hello world) on a line, then undo until only "hello" is here. Then move cursor. No more Redo. You have to type "world" manually once again. Imagine if it is not only just one word "world" and you applied undo several times  - you will lose whatever you had before undos unless you save quite often.