I find it pretty retarded that the whole 'redo' history is wiped clean just for doing a ctrl+c after some undos or after a save. Every editor I have ever used behaves as it should be and remember the undo/redo history even after saves or editing in between.

I find this a very limiting and confusing and it had cost me lots of time already having to code parts again after losing my undo history.

I hope this gets resolved in future versions

I do not agree with you on this. Give any other editor a try and you'll see that REDO log is cleared on Ctrl-C (Paste) command as well as on any other key that changes the editor content, except UNDO.
UNDO itself is remembered and is not cleared on that.

Ctrl-C is Copy, not Paste, and the OP is correct that it does not clear the undo stack in other applications. This follows with your amendment about changing the editor content, since a Copy does not change the content.

I have to point out, though, that neither does moving the insertion point change thee editor content, but that, too, clears the undo stack in PhpED. I seem to recall you saying that this behavior would change in a future update. I, for one, can hardly wait... I've lost enough code to this already! (Though nowadays, I've gotten into the sad habit of copying the current code state to a new, empty file prior to undo excursions. This protects me in case I happen to click or press an arrow key at the wrong time, and it lets me back up, copy some code from a past state, and return to where I left off. But I really shouldn't have to do this.)

Right, handling for REDO will be changed. Regarding UNDO, I tried Ctrl-C (Copy) in PhpED and in the other editors and UNDO was not cleared in neither of them. In other words, concerning UNDO stack PhpED works fine. I do not think there is any problem. As of REDO, it's list is cleared when cursor is moved because currently all cursor movement operations are the operations stored in UNDO/REDO lists and therefore they are changing the lists, hence the REDO must be cleared after cursor is moved the same way as it's cleared when the text is edited. To illustrate how it works, let's consider the following operations were done and stored in the UNDO list: A->B->C->D. Now we UNDO C and D, therefore A and B will remain available in UNDO and D and C will be moved to REDO. If at this point we run operation E, the editor has no way to REDO C because C is supposed to be applied after B, not after E or you'll get absolutely wrong content. So the C and D must be removed.

Right. But since simple cursor movement doesn't change the content (it just changes the state of the editor itself), it shouldn't be put on the undo stack. This is especially important given that it makes some very common, very useful undo-related operations impossible and can easily cause code loss for those not familiar with the behavior (or even those who are-- *cough*like me*cough*--when they're just so used to the normal behavior that they forget now and then how PhpED works).

I agree. This should be about changed content only, and not cursor movements. Or am I missing some benefit of tracking the cursor movements too?

I don't see how this can be marked as resolved, but anyway..

I often use TopStyle Pro and UltraEdit and ctrl+c and cursor movements definitely DO NOT clear the undo history. TopStyle even allows undos after saving, as does UltraEdit if I recall correctly. Hell, even PSPad does it.

The trend now is to maintain the undo stack not only across saves, but across closes/reopens of the document and the application itself. It's part of the larger trend of generalized software (such as web browsers) maintaining state between sessions.

bobwilliams said:

It does change the UNDO list and this fact alone makes it imposisble to keep REDO after cursor is moved.

But it is how the lists are done.

No. It can never cause any code loss.
Also, it does not affect UNDO in any way. What affected is REDO.

Spaceman said:

Probably you don't see difference between fixed and resolved. Latter one means that either the problem is acknowledged and won't be fixed in current version or this is not a problem at all.

Probably you do not see difference between REDO and UNDO.
In PhpED ctrl+c and cursor movements definitely DO NOT clear the UNDO history at all.


PhpED keeps undo after saving too.

First of all, don't focus so much on implementation details. From a user perspective, undo and redo use a single list--or at least, that's how they *should* behave. Even at the implementation level, though, most software that I've seen or written has implemented undo/redo with a single event stack - but again, impelmentation details are irrelevant.

As to my comment above, I realize that the undo stack is changed by cursor movements as implemented in PhpED. That's what everyone wants fixed. Cursor movements have zero effect on the content of the file--they only affect the state of the editor working on the file--and therefore should not in any way affect undo/redo.



So change it. You make changes in the IDE all the time; why not this one? I have no idea whether it's a big change or a small change, but certainly, it's within the realm of possibility to make modifications to the source code to correct what, IMHO, is a very serious bug. The bigger the change, the longer it will take, but simply stating the obvious (that's "how lists are done") about the IDE's current behavior, and using it to justify its continuing on that way, doesn't help us at all.



Yes. You're completely wrong on this Dmitri. By having an undo/redo behavior that is different from every other editor out there, the behavior is unpredictable. The undo/redo feature itself won't literlly take consume your code, but its completely non-standard behavior will cause the human relying on it to follow a sequence of steps that causes code loss.

For example, just look at some of the threads where peole have pleaded for you to fix this while telling you that it's causing them to lose code:

should-undo-show-cursor-movements-t2538.html?highlight=undo behavior behaviour
an-issue-with-redo-t3413.html?highlight=undo

Another another way in which undo is broken:

selection-after-undo-t2894.html?highlight=undo



Huh? Undo and redo are by definition intrinsicly tied together. A user expects that the two commands will always perform exactly the opposite function of each other - no more, no less. If undo changes something, redo should precisely revert the change, and vice versa. So if some mis-feature affects one, it certainly affects the other.

But you're simply diverting the thread with this. The point is, the undo behavior in PhpED is very broken by the fact that mere cursor movements are tracked in undo/redo, and that fact is both extremely annoying and can cause data loss.



Again, from a user perspective, undo and redo use a single stack of command events. If you do something that affects your ability to perform either undo or redo, then that command stack has been affected. How you have implemented undo in code is irrelevant; you need to look at this from a user's perspective.

Please reconsider fixing this!

Going to have to echo bob on the above, tracking the history of cursor movements is of no benefit to me, quite the opposite, it can get very confusing when you try to undo, especially when you are reviewing others peoples code and click throughout the file,

Please reconsider fixing

Dear bobwilliams,

Again, I insist that UNDO is available and you can roll back your code safely. No code loss! And no problmes can ever be caused by the fact that REDO is cleared on the cursor movement.



These posts have no relation, absolutely.
They all are about very different issue caused by implemetation problems in the editor when "Keep trailing spaces" is off and/or "Optimal fill" is on.
Just do not change these two settings and you will never get any problems with UNDO. But it has no relation with REDO availablity after cursor movements that we are discussing in this topic.
Please give a try and make sure you can replicate the "potential" problems you're talking about before post