Community
Participate
Working Groups
Build Identifier: Sometimes when I'm trying to change a file, the editor blocks and I have to wait for some background job to finish before I can go on typing (for example, if a file is readonly, eclipse runs a VCS command that edits the file and thereby marks it writable). My suggestion is to have an option (repsonsive editor or something) which always allows the user to type in the editor, no matter what else is going on. Reproducible: Always
That's the standard locking mechanism. I don't think we will provide ways to disable that. Moving to Core for comment.
In the particular case that I looked at, it seemed that the problem was caused by AbstractTextEditor.java line 4982: BusyIndicator.showWhile(getSite().getShell().getDisplay(), new Runnable() { /* * @see java.lang.Runnable#run() */ public void run() { validateState(input); } }); The problem with this is that BusyIndicator.showWhile doesn't allow the user to cancel the operation, even if the lock being acquired somewhere under validateState(input) is blocked on a lengthy refresh operation. For the user, there is no indication of progress, no way to cancel, and probably not even the event loop is spun, until the refresh operation releases the lock that validateState is trying to acquire. I think Manuel's suggestion is to not acquire a lock during validateState in a blocking way. I have no idea if that's an option, but if it isn't, I would suggest looking into replacing BusyIndicator.showWhile with something that shows a dialog with the option to cancel if locks cannot be acquired, similar to how it is done in WorkspaceAction. Perhaps Manuel can provide the thread dump from when this happened.
(In reply to comment #2) > In the particular case that I looked at, it seemed that the problem was caused > by AbstractTextEditor.java line 4982: > > BusyIndicator.showWhile(getSite().getShell().getDisplay(), new Runnable() { > /* > * @see java.lang.Runnable#run() > */ > public void run() { > validateState(input); > } > }); > > The problem with this is that BusyIndicator.showWhile doesn't allow the user to > cancel the operation, even if the lock being acquired somewhere under > validateState(input) is blocked on a lengthy refresh operation. For the user, > there is no indication of progress, no way to cancel, and probably not even the > event loop is spun, until the refresh operation releases the lock that > validateState is trying to acquire. That would be a different bug then (or a rename of this one). > I have no idea if that's > an option, but if it isn't, I would suggest looking into replacing > BusyIndicator.showWhile with something that shows a dialog with the option to > cancel if locks cannot be acquired, similar to how it is done in > WorkspaceAction. It depends in which state the editor is when we do the validation but I think it should be possible. As you know, patches are welcome Boris ;-).
(In reply to comment #1) > That's the standard locking mechanism. I don't think we will provide ways to > disable that. > > Moving to Core for comment. No, we are not going to change the core.resources mechanism. Manuel, if you like the Boris' idea from comment 2, we'll move it back to Text for further investigation. Otherwise it is WONTFIX.
More context :) What Boris pointed out in comment 2 was the initial spark to the conversation. That specific problem is in my view just one instance of a more general problem I have with eclipse. I've been using eclipse (mainly C++ development) for about 3 years at Google now. Let me pre-load the rest of this rant with that I love eclipse for a lot of its power features, and I appreciate the hard work everybody here does to make that happen. Now to my problems: the special thing in how we use eclipse at Google is how we access the source code (and other data): we use FUSE modules and network file systems (see http://google-engtools.blogspot.com/2011/06/build-in-cloud-accessing-source-code.html for more details) and we have very large projects. This breaks some general assumptions about I/O latencies, and leads to some problems developers have with eclipse. I've seen multiple people switching from emacs/vi to eclipse and back after a month for exactly those reasons. 1. Eclipse does I/O operations in sequence. This is of course perfectly fine when accessing a local disk, gets slightly annoying when you access NFS and leads to significant multiple orders of magnitude slow down of many operations on network file systems with > 100ms latencies. 2. Eclipse blocks my editing for some I/O operations. The example Boris gave is just one. Every time I want to type something and eclipse doesn't let me is a really bad user experience. I understand that this is not as big a deal if we didn't have network file systems and most operations would be < 100 ms to complete. Giving me the opportunity to abort the operation that blocks my editing does not help, as I actually want that operation to finish - I just want to type some code in the 1-2 minutes it takes to complete instead of switching to reading xkcd. I've talked with eclipse developers about 1) before and was told that changing eclipse to use parallel I/O is a big architectural change and thus not achievable. On the other hand I was told that changing the editor behavior to never block me from editing text, no matter what else was going on, would be a much smaller change. I understand that you probably wouldn't want to switch that behavior on by default, but if you oppose exposing a feature like this as an option, I'd be very interested to understand why.
> On the other hand I was told that changing the editor behavior to never block > me from editing text, no matter what else was going on, would be a much smaller > change. Would you be so kind to name that person? It will be my pleasure to load the work on him :-). I assume we currently talk about textual editors. Does the problem only happen when you start typing while the editor is in saved state (expected) or also in other situations (should not happen)? If the latter, can you give some examples? I think the former should be doable. In the worst case you won't be able to save the file in case validateEdit failed or you would have to wait when saving before the initial validateEdit was finished.
AFAICS all your blocking dialogs allow manual cancellation these days in the current release.
