Community
Participate
Working Groups
The entire concept of an IDE is that you edit files, and save things. Sometimes you do things with those saved and edited files, (like compile them or run them or deploy them or debug them) but those things you do should NEVER stop you from doing the basic edit and save functionality. The same is also true of navigation and search. You should always be able to search for text and you should always be able to perform simple file based navigation. Basically the IDE should NEVER block the user from editing and saving files. Code completion and other "enhancements" to simple text editing should degrade gracefully if "things" are happening, but the IDE should NEVER stop the user from typing in their thoughts and persisting them. I'm tired of reading about things like this on www.ihateeclipse.com, stackoverflow and other forums. Surely eclipse can be adjusted so that simple file manipulation editing and saving is completely isolated from the rest of whatever else is happening. That other stuff can block or queue up or whatever, but editing and saving ought not to EVER block.
I know about the save problem - it is captured by bug 329657. However, I've never seen it while typing into the Text or Java editor. Can you provide steps that allow us to reproduce a blocking UI while typing?
Sure, select "build automatically", select "build (if required) before launching", set a "workspace save interval" (with any "validator" triggered on save), set a "clearcase refresh polling interval", also "maven" I think can do this. In addition things currently block editing such as starting or stopping a server, or any of a myriad of other thigns that take time, all of those will prevent a user from clicking on a file and typing, and many of which when starting in the background grey out the screen and prevent the user who just realized somthing is wrong or who wants to make a quick change, from typing.
(In reply to comment #2) > Sure, select "build automatically", select "build (if required) before > launching", set a "workspace save interval" (with any "validator" triggered > on save), set a "clearcase refresh polling interval", also "maven" I think > can do this. In addition things currently block editing such as starting or > stopping a server, or any of a myriad of other thigns that take time, all of > those will prevent a user from clicking on a file and typing, and many of > which when starting in the background grey out the screen and prevent the > user who just realized somthing is wrong or who wants to make a quick > change, from typing. Looks like I misunderstood. You're not running into a lock while typing, but, some actions block the UI while running and you can't continue typing in the meantime? Correct?
It can happen if plug-ins (ClearCase, Maven,...) take a too coarse grained lock. Those problems need to be fixed there.
No, this does NOT need to be fixed in the individual components. A fix should NOT reply on fixing those components. As part of defensive coding the eclipse UI must prevent other components from interfering with the UI. This can't be solved by replying on every thrid party program and implementor doing their jobs properly. I am reopening this bug.
No, this does NOT need to be fixed in the individual components. A fix should NOT rely on fixing those components. As part of defensive coding the eclipse UI must prevent other components from interfering with the UI. This can't be solved by replying on every thrid party program and implementor doing their jobs properly. I am reopening this bug.
Sorry, the editor just needs the lock on its single file. We won't invest to change this. Using uppercase or posting the same thing twice won't change this.
(In reply to comment #7) > Sorry, the editor just needs the lock on its single file. Just to clarify: the lock is only taken on save and for that case we have bug 329657. If some other component locks the UI, then there is really nothing the editor can do. However, if there is a case where the UI goes into a lock due to typing, then that would be a bug in the editor that we have to investigate.
Sorry, did not mean to double post, but you should really reconsider your response. The IDE should defend itself from being locked in this one specific case, were the user wants to type changes in.
