Community
Participate
Working Groups
Build ID: M20070921-1145 Steps To Reproduce: Open an editor for a file by selecting it in the navigator view. Copy it. Paste it. The selected item is now the parent of the pasted file, and the active editor is the original file. Why this should be fixed: Every time I duplicate a file, I start editing what I think is the duplicate only to find out later that I actually edited the original. This happens because I assume that the file I just pasted is the one that is opened in the active editor. Many of my coworkers have done this same thing. It seems logical that when someone copy and pastes a file that they will want to work with the duplicate afterwards. So it would make sense to open the duplicate when the paste operation completes. If this seems like something some people will not like, then a user preference to turn on this behavior would be really nice.
An interesting comment. Note that the file isn't selected either. So on the one hand we're consistent. On the other, the lack of selection has tricked me in a similar way to what you describe, and I too have edited the wrong file by accident. However, we generally don't automatically open editors as a side effect of some operation. Tod, any thoughts? I'm interested in the idea of changing the behaviour as described. I'd like to avoid a preference for it though.
We certainly don't want to add a preference for a small behavioural difference like this. Our policy has always been to minimize unneccessary clicks and I think this could create them. My usual pattern is to copy, rename and then open so this would create an extra click for me. Also changing the selected editor is a loss of context which we also attempt to avoid. My feeling is that the current behaviour is the way to go.
Why would this cause an extra click? Currently: Different folder copy: copy, paste into a different folder. Then select the file, right click rename (or use shortcut key) Then double click open. Same folder copy: copy, paste into the new folder paste automatically brings up rename dialog. then double click open the file. In my suggestion the only change should be that you would not need to double click to open the file. So you should be saving clicks. Can you be more specific about the negatives of the loss of context. Or is there a UI guidelines document I can read? I think my expectations come from using the "save as" action in other applications. Other applications don't show a view of the file system. So to make a duplicate of a file, you do "save as". At that point you are editing the new file. Sometimes they have a "save a copy as" which acts more like the current copy, paste code in eclipse. I just found I could use the file->"save as" action to do the same thing in eclipse. When I do this the new file is opened after saving. There is a similar ui in the launcher dialog. In that case there is a "duplicate" action which does all these steps and then opens the new launcher. In that case though there are no tabs, so it is easy to synchronize.
The extra work is the effect of the rename. When I rename a file there are freequently a lot of updates that have to happen an in place editor as a result (a java file is a good example of that). We don't have a documented list of what constitutes loss of context but the loose definition is that if something changes in what you are looking at that is not obviously a result of your actions your context has been lost. A good example would be switching perspectives without asking (which we generally do not do).
So then following the perspective switch approach. There could be a dialog which asks if the user wants to open the pasted file, and a check box to remember the decision. Of course this would imply a new preference which is un popular. I think the loss of context in this case is somewhat a grey area. The "not obviously a result of your actions" part is subjective. When doing a file->"save as" operation the new editor is opened. That is a single operation on the active editor. In that case there is precedence in other applications. So the change of editor is expected. In the copy, paste operation there isn't much precedence, so it is not clear what a user expects. I've seen some users like me expect it to open the pasted file. It would be interesting to create an interactive test and see how many people expect it one way or the other.
On WinXP and Vista, if I copy/paste a file in the explorer/desktop, the result isn't selected. So in that regard I agree with Tod. However, I have made the same mistake that Scott mentions of editing the wrong file so I feel the pain. I'll add though that we on the platform UI team hardly hit this because its very infrequent to copy/edit in Java+CVS. I don't think I've ever made (or to the same frequency) the same error in WinXP so there's something different going on in Eclipse. I'm going to leave this bug open for consideration although the solution persently isn't clear to me. (In reply to comment #5) > So then following the perspective switch approach. There could be a dialog > which asks if the user wants to open the pasted file, and a check box to > remember the decision. Of course this would imply a new preference which is un > popular. It's also not quite the same case. The option of remembering the choice is there because generally speaking, you tend to use Debug perspective or not, CVS perspective or not, etc. But in this case its not so clear to me that its an always or never choice, it may depend more on what you're doing. > It would be interesting to create an interactive test and see how many people > expect it one way or the other. In particular this is the type of thing that is ripe for a usability study. Unfortunately we have no funding for them but seems a great community contribution.
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
