neither 'u' or ':undo' appear to be working.
I'm using the latest unstable.
I've noticed this issue happening occasionally but I haven't been able to
figure out what causes it. It'll work in some files but not others. When
you run into this problem, eclipse's normal Ctrl+z undo still works so at
least there's a workaround.
so, undo seems to be working in fine in Java files, but not in XML files pretty consistently.
Hi guys, I've managed to reproduce this elusive issue :) What I did to reproduce this was:
After the refactor, then the undo stops working. At first I thought it might be an unnamed clipboard bug, but it's not. It also happens with the default clipboard.
Well done. That definitely reproduces the issue and throws a stack trace:
!MESSAGE could not set mark
Unfortunately, it doesn't help me solve the issue. That method is throwing a stack trace but we catch it and log it. It doesn't look like it should be leaving Vrapper in a bad state. I'll keep playing with it though. At least this gives me a place to focus my efforts. Thanks!
I'm not sure if this is the only way to reproduce the issue. That bothers me because I might be able to fix this specific problem but it wouldn't be a general solution. I'm still no closer to figuring out what's actually going on here.
This specific issue is that refactoring a filename creates and opens a new file for editing without firing any of the partOpened or partActivated events. This means Vrapper is never told to re-create the listeners it had set on the old filename's editor. So I might be able to find a way to forcibly re-apply the listeners during a refactor operation but that solution definitely wouldn't be accessed in any other scenario. I doubt nhajratw was renaming each of his XML files and that's what led him to believe undo was broken for all XML files. There must be some other scenario that exhibits the same behavior.
By the way, I tried avoiding the stack trace and it didn't fix the undo operation. So the stack trace has nothing to do with the root problem. The stack trace was basically telling me that the listener was never defined, which means everything was already in a bad state before this method was invoked.
Yes I agree. It doesn't sound like nhajratw's case. Although, he
doesn't have to rename each of the XML files...probably just one.
Do you think it's a good idea to have Vrapper test whether the
listeners exist, if not, then recreate? Perhaps that's what you're
referring to by "forcibly re-apply the listeners". But rather than
doing it when refactoring, maybe check somewhere more central so that
it may catch other cases as well?
it doesn't seem to be related to renaming for me...
I have a theory. I hit the issue mostly on XML files that start up in some sort of Design view or other structured view. If I have to change tabs from "Design" to "Source" then I typically see the problem. For example, opening up a pom.xml file for Maven doesn't start me out in the XML view immediately so I have to move to the source view. I consistently hit this issue in pom files. I wonder if we fail to setup listeners when the initial view of a file is not a text view.
nhajratw, does this make sense given the behavior you're seeing? Or does your XML editor jump straight into an XML view?
nhajratw, could you try something for me? I have a potential fix but I'm not sure if it's worth checking in yet. This handles the scenario for renaming a file but I'm not sure if it will fix your XML issue. Basically, I re-apply all listeners any time an editor gains focus. I also remove all listeners any time an editor loses focus. This means the listeners will be re-applied when you click into an editor regardless of its name. However, this also means I constantly remove and re-apply listeners as you click through tabs, which may not be ideal.
If your issue is related to losing listeners, I think this should fix your problem. If your issue is not related to listeners, this will do nothing for you and I'll back out the change because I don't want to take the performance hit. That's why I haven't checked in the code yet, I don't want to constantly mess with listeners if it isn't needed.
This code is beyond unstable, it's really-unstable. So I've created a new update site which you can use to pull down the changes and it won't affect anyone else using unstable. Please add this update site to your list and perform an update. Let me know how it goes.
I'll try this sometime this week -- fyi, it's not a problem with xml editor views... Thanks!
I've also found that the search (/) function stops working at the same time as undo. As you type, seemingly random and different (but the correct number of) characters are highlighted until you type enough characters where the "match" fails.
I'm using vrapper within the C++ editor, but I haven't been able to identify the cause.
Quick update on my progress for this annoying defect. I can consistently reproduce it with a pom.xml file for Maven. I don't know if it's the same root cause as when it breaks in a Java file but I haven't found a way to reliably reproduce the issue in Java so I've been sticking to the pom.xml file.
When a file is first opened, Vrapper creates an instance of EclipseHistoryService with an IUndoManager as one of the arguments. When the argument is passed into the constructor, the IUndoManager instance has a fTextViewer and fUndoManager defined. When I perform a change to the pom.xml then hit 'u' to undo, that instance of IUndoManager in EclipseHistoryService now has both fTextViewer and fUndoManager set to null. So the undo call tries to call IUndoManager's undo() method, but since fUndoManager is null, the operation has no effect. I have no idea how or why those arguments suddenly became null.
One more difference. When I open a Java file, the IUndoManager is implemented by a TextViewerUndoManager instance. When I open a pom.xml file, the IUndoManager is implemented by a StructuredTextViewerUndoManager instance. I have no idea if that's relevant.
That's the extent of my knowledge so far. I'm still no closer to finding a fix.
It would appear that the breakage of undo and search that I'm experiencing within the C++ editor are actually related to folding. If I disable folding, I never see this problem.
Well that's interesting. And unexpected. What happens if you enable folding but expand all folds? Do you still see the issue? Or does folding actually have to be disabled to workaround the problem?
I never really use folding, but the default configuration collapses the file header. I enabled folding again but made sure everything was expanded by default. In this configuration I encountered the problem again.
Sadly I have now encountered the issue with folding disabled (possibly after refactoring), but it definitely appears more stable when folding is disabled (it seemed to be happening to every buffer within half an hour of opening). I'll continue experimenting...
Thank you for continuing to experiment. I'm sorry this defect is such a
pain but it's difficult to track down.
Is it possible to do a relation between vrapper undo and Eclipse undo? May be a solution I think.
See my long comment from 6 months ago that starts with "Quick update on my progress". Vrapper is already calling Eclipse's UndoManager directly. The problem is that the instance we were using somehow gets its private properties to turn null so calling undo has no effect. I don't know when or why Eclipse sets some of its private variables to null after I initialize it.
I will try to figure out something about how to solve this problem.
I would absolutely love it if you could figure this one out. Good luck! Let me know if I can help.
I'm also affected by this issue. Hope you can find a fix.
I have problems with this all the time... for me it seems manifest as if the vrapper undo is using a different stack than the eclipse undo. So I often get myself in the situation where doing a vrapper undo undoes more than one edit.
Here is a recent stack trace from my error logs. I hope it helps.
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Framework arguments: -product org.eclipse.epp.package.jee.product
Command-line arguments: -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.jee.product
!ENTRY org.eclipse.text 4 2 2013-05-08 21:08:11.736
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.text".
java.lang.IllegalArgumentException: Index out of bounds
at org.eclipse.swt.internal.gtk.OS._gtk_im_context_filter_keypress(Native Method)
at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method)
at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Oops... I should have mentioned that stack was generated using Juno SR2 and vrapper v0.31.20130421
Attempt to fix #86. I'm hoping someone can verify this for me.
Thanks for the stack trace. I'm not sure if it's the same issue everyone else was seeing but it was simple enough to avoid. After the undo happened we were trying to update the cursor position to the stickyColumn. In your stack trace that was throwing an IllegalArgumentException, I'm assuming because the desired column no longer existed after the undo. So, I now catch IllegalArgumentException and fallback to the first column of the line. This might not be the ideal behavior but hopefully the operation will complete now.
Note that I wasn't able to reproduce this stack trace so I'll need you to install the latest unstable build and test it out. I should have the new build (0.31.20130510) up soon.
UPDATE: Done. Unstable update site is updated. Let me know if this didn't work and I'll re-open the issue.
Thanks! Just installed the fix. I'll let you know if the problem recurs next week as I'm using this at work daily.
Just updated after finding this issue and it no longer undoes giant chunks, just small pieces that can be redone with my U. Thanks!