Sublime Forum

Redo: Impossible to see redone changes

#1

I really love Sublime and would love to continue working on building out language support packages for it, but there has been an outstanding bug that makes it unusable for long editing sessions. There appears to be a rather critical bug with how Sublime implements redo. Sublime prevents you from seeing which changes are being played forward/backwards in the undo stack. If you’ve ever wanted to quickly go back to a previous version of the file to recall which changes you’ve made, you’ll have a very hard time because when you press undo/redo and changes are spread out across a large file, there’s no way to see the change that you’re replaying. You can see the before/after states, but you really want to see the actual change being applied (not currently possible with ST3 or ST2).

Here’s the correct behavior (that vim and other editors use):

UNDO: Pops the last change off of the history stack, and moves the moves the cursor to the location where typing of that popped off change began.
REDO: Pushes a change back onto the undo stack, and moves the cursor to the location where the typing of that pushed change began.

This has been brought up before https://forum.sublimetext.com/t/redo-does-not-scroll-to-change-bad-scroll-jump-on-redo/7725/1#p38901 (the bug has existed for quite some time) and I keep hoping that one of the updates will fix this. I would greatly appreciate a fix, as it would make the Sublime editing experience usable enough for extended use. Would it be a relatively straightforward fix?

0 Likes

#2

How does this not irritate everyone who uses sublime?

0 Likes

#3

As much as I agree with your sentiments, I wouldn’t call this a bug since ST’s undo/redo functionality works as designed. What you’re asking for is an enhancement that I favour but it’s on a growing list. I find myself just alternating undo/redo to see what’s happening and though it’s not ideal it works OK for me most of the time.

The old E texteditor had a nice branching undo/redo with history view. A hybrid of that and the vim approach would be awesome; perhaps Jon has something in the pipeline but I’m not holding my breath and it’s not highest on my personal wishlist.

0 Likes

#4

Yes, redo is somewhat broken. I sometimes need to recover changes from other sources, beacuse redo stops working and I’m unable to recover the changed portions. The editor starts writing Y instead of redoing my changes.

0 Likes

#5

Somewhat related :
github.com/SublimeText/Issues/s … ype=Issues

0 Likes

#6

Strange tito. I’ve on a few occasions “undone” way way back through edits, including multicursor ops and s&r, and redone them all back without a problem. But if there are use cases where redo breaks, then that really ought to be fixed.

0 Likes

#7

I cannot find a way to repro this, but basically:
I sometimes want to go back deep in history to see where and when I introduced something… once I discover or find what I’m looking for, I just want to reapply all the changes with /redo/ … well, sometimes I cannot redo. Not usefull information, but well, something that happens from time to time.

0 Likes

#8

[quote=“qgates”]As much as I agree with your sentiments, I wouldn’t call this a bug since ST’s undo/redo functionality works as designed. What you’re asking for is an enhancement that I favour but it’s on a growing list. I find myself just alternating undo/redo to see what’s happening and though it’s not ideal it works OK for me most of the time.

The old E texteditor had a nice branching undo/redo with history view. A hybrid of that and the vim approach would be awesome; perhaps Jon has something in the pipeline but I’m not holding my breath and it’s not highest on my personal wishlist.[/quote]

I don’t think I’ve done a great job explaining exactly what is going on, but it absolutely is a bug. I’m not asking for an improvement to the editor. Currently, it is absolutely impossible to tell which changes you’ve applied to a file by undoing and replaying them (when the changes occur across a large distance in the file). It’s not that it’s hard - it’s impossible. No other editor has this issue. Not even the stock cmd+z, shift+cmd+z that comes with operating system text edit boxes.

0 Likes

#9

Here’s another report from years ago. I don’t see any comment from the developer on the issue. It would be great to fix this interaction. Everything else about sublime feels great.

sublimetext.userecho.com/topic/ … ght-place/

0 Likes

#10

There are other reports and experiences where users describe not being able to comfortably replay history of their editing session:

sublimetext.userecho.com/topic/ … -playback/

I believe these users are having poor experiences because of this bug, but it’s very difficult for people to articulate why their experiences are poor and they may not even realize that this cursor issue is responsible for their inability to track changes.

0 Likes

#11

Is there any word from the developer about this critical bug?

0 Likes

#12

Looks like it’s been years since this was originally reported and I have not seen one acknowledgement from the developer on the matter. Is this the correct place to report bugs? Is there an official support channel somewhere?

0 Likes

#13

Is there any update here. This may be a simple change for the core developer, but it appears impossible to fix via a plugin/extension.

0 Likes

#14

I’m working with ST for a short time. So far I have not had this problem.
I’ve a small backup system that stores my changes every time the file are saved.
It can be configured, that it only make a backup if exists a special character in my time line. In the time line I’ve Date and Time and version number (only main and subversion). It looks so:
– TIME_STAMP 2012-09-17 22:27:28 v 0.3
By default increases the subversion number, any time the file will saved. Special characters behind the version number can change the behaviour.
The backup files will stored in an own folder. For every file will a subfolder created to hold all versions of this file. The filename is added with its version number. In the picture you see the system.

http://www.imgbox.de/users/BugFix/thumbnails/backup_version_t.gif

0 Likes

#15

That doesn’t help at all. Here’s a really easy way to repro.

Open two editors instances. In one have

aaaaaaaaaaaaaaaaaa


… full page of newlines
bbbbbbbbbbbbbbbbb


…full page of newlines
ccccccccccccccccccccc


…full page of newlines

Copy “aaaaa” all the way until the last newline before “bbbb”, then paste it into the second editor instance. Then copy “bbb” all the way until the last newline before “cccc…”, and paste it into the second editor instance and so on.

Then when you’re done, try undoing/redoing the changes. Again, it’s not that it’s difficult to see the changes - it’s impossible - this is a critical bug that makes the editor unusable for serious development (and I say that with regret because I love Sublime apart from this issue).

Also, if you use any of the Vim modes, it will happen very frequently.

0 Likes

#16

So I realized that there’s actually two issues. Redo should leave cursor at the beginning of the redone change, but that’s not as serious as the second issue.

The second issue is that Sublime associates a cursor position with each place in the undo tree. If you undo to a version, then move your cursor, whatever you do - if you undo/redo and end up on that version in the undo tree again at some point, it will force your cursor to where you left it the last time you were at that version. This is the main issue - and the main reason why it’s easy to get in a situation where it is impossible to see what changes have been applied by replaying redo.

I’ve posted it as a separate topic here: Sublime retains cursor position for each undo/redo version

Does anyone know of a way to disable the fact that Sublime retains the cursor position for each place in the undo/redo history?

0 Likes