-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug 578871 - use ISchedulableOperation #19
Conversation
please rebuild. |
...factoring/src/org/eclipse/ltk/internal/core/refactoring/UndoableOperation2ChangeAdapter.java
Show resolved
Hide resolved
...factoring/src/org/eclipse/ltk/internal/core/refactoring/UndoableOperation2ChangeAdapter.java
Show resolved
Hide resolved
I think I covered all requested changes but the review is still -1, what do you think is missing? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Jörg: I see there are two commits now.
Ideally that should be one (no need here for multiple commits), with appropriate commit message. I fear, github own "squash and merge" will generate some stupid commit message, so ideally you could locally squash your two commits into one (using proper commit message) & push again.
...factoring/src/org/eclipse/ltk/internal/core/refactoring/UndoableOperation2ChangeAdapter.java
Show resolved
Hide resolved
I have no influence on what you will put in the commit message.: |
That's what we (I believe @iloveeclipse too) are trying to avoid, I suppose. Besides, I think it also makes it easier to review if the changes are in one commit, although I have no personal preference. |
Give the caller of the UndoableOperation2ChangeAdapter.execute a hint that this operation aquires workspace.root as ISchedulingRule. It freezed the eclipse UI as long as any other Thread (for example autobuild) had any lock in the workspace. With the hint a UI can prevent to freeze while waiting for the rule. The original call to ResourcesPlugin.getWorkspace().run(runnable, pm); is equivalent to the call of Workspace.run(IWorkspaceRunnable, IProgressMonitor), which is implemented internally as run((ICoreRunnable) action, defaultRoot, IWorkspace.AVOID_UPDATE, monitor); - means, changing the original code to proposed one is safe and doesn't change any behavior because the executed code it is identical at the end. It only gives a hint about the lock that is used anyway. Workspace.run(IWorkspaceRunnable, IProgressMonitor) was inlined to give a uniform pattern where the lock is aquired.
@jukzi : I've tried to undo method rename wit all patches applied, but none operations I get in Can you provide exact steps to reproduce the original issue described in https://bugs.eclipse.org/bugs/show_bug.cgi?id=578871? |
In eclipse ide in a java editor select a java method name, press ALT+SHIFT+R to rename, edit name, press ENTER. |
I'm doing exact this and still get no UndoableOperation2ChangeAdapter Debugging that I see this eclipse-platform/eclipse.platform.ui#18 was not complete, see my debugger screenshot that explains why: |
Then we can let TriggeredOperations forward the ISchedulableOperation. |
Would you provide a PR? Reminder for myself: draft commit message here (assuming no other changes needed)
|
|
to prevent UI freeze during UNDO
needs
eclipse-platform/eclipse.platform.runtime#30