Community
Participate
Working Groups
Build id: I20090522-1710 When opening a file that is open in compare editor, compare editor should be activated and appropriate part of it should get focus. Right now when opening a file that got focus in compare editor user gets a proper behaviour - compare editor is activated. When the file is opened in compare editor but doesn't have focus a separate editor is opened for it. This is confusing for users and far from being consisted. See bug 277693 for a similar problem in text compare.
I don't agree. Opening (or double-click) should activate the editor which is marked in the Open With command. Currently it behaves different for the active Java Compare editor because this was the only way to make the Java navigation features work inside the Java compare editor.
Open Type is confusing users too, see bug 276848.
as i already said in bug 276848 the current behavior is just weird, The compare window should just be the compare window. It shouldnt get activated or anything when i do want to open the java file in its editor. With Open Type i dont have a choice in what editor it opens, I expect that open type opens the editor in its type editor. Not that the compare editor of the same file gets activated. Its not really getting activated, it is even worse because it is already activated, only then the compare window will block the opening of a java editor. It will not do this if the compare window is not the active window. But ask your self the question. If the active editor is the compare window. Which i see in front of me. And i do open type or click on a java file through the navigator/package explorer why should it completely do nothing? Because that is the end result nothing happens, I dont ask for that.. I explicitely want to open the java file in its own editor because i want to have a better/larger overview and everything is correct for that editor like (popup)menu's. Besides that the compare window just takes to much space for easy code overview.
*** Bug 278236 has been marked as a duplicate of this bug. ***
For people that want to quickly switch from the compare editor we'll enhance the context menu > Open (With) actions, so that one can quickly go to the same position in the "real" editor (see bug 267171).
please reconsider this, everybody i know hate this behavior, yes i know i can do open with but that is using the mouse en a few clicks before i get to it. Can anybody here convince me of one thing that could explain this behavior to me that is decided on: Why is it if i do Open Type and i type in the Name of the class that i want to open and i press ok that there are 2 behaviors: 1> if the active (compare) editor is showing that type, nothing happens it just goes activates the editor (which is already in front of me!) 2> if the active editor is the compare editor, but there is an compare editor with that type open!, it still does open it in a new java editor! I can't figure out this. Ask your self, why would i open the open type dialog and type the name of the active (compare) editor to open it??? It is the active editor so why would i do that?? Thats something i already have in front of me. Wouldnt i just do that because i want to open it in something else?? If it was the opposite 1> if the active (compare) editor is that type, it does open it in a new java editor. 2> if the active editor is not that type,it just goes to the open editor, and this could be a compare window. That would make a bit more sense..
If you have a type open and you use 'Open Type' to open that same type it also just does nothing i.e. it doesn't open a second editor to show it. Even if the current type is open in a Text (or whatever) Editor it won't open a Java editor - instead it stays in that editor. Again you can call that weird behavior, but that's how it works since Eclipse 1.0. Our goal is to let the Java Compare editor have almost the same support as the real Java editor. Hence there should only be very few reasons to open the Java editor (e.g. to get 'Mark Occurrences' or better real estate). Please open bugs if you have other major trigger points to switch. >yes i know i can >do open with but that is using the mouse en a few clicks before i get to it. You can use 'context menu' > 'Open' / 'Open With' or use the keyboard. That is much faster than going via 'Open Type' where you have to enter the type again and with the fix for bug 267171 you will get even better behavior than using 'Open Type' because it goes exactly to the same selection that you have in the compare editor.
But that compare window thing only works like this from eclipse 3.5 or 3.4, 3.3 definitely didn't have this behavior. Also it is not really consistent. Because i know the work around for this and that is use Open Resource. For example if you have a java file in a compare window as the active editor. And then you open that again through open resource, it does open (by default) the java editor! There i could say it should jump to the best matched editor (if you dont say explicitly open with->java editor) and that would be the compare window. Open type is really something that should open stuff in the java/class editor all the time. Because thats what open type (open java type in its java editor) says to me. So i would like that the default behavior of open type dialog was the same behavior of what you get when you do open resource and then open with->java editor... Problem with open resource is that it is so cluttered for opening java file. Many things i dont want to see in that list. What i could do is open a new feature request for the open type dialog so that it gets the same features as the open resource dialog. That you really can say in that dialog which editor it should use to open it with.. This would also help some other issues where i have 2 kinds of class file editors, 1 that decompiles and the other (the eclipse default) that uses source attachments. Sometimes i want the decompiler and other times the eclipse default (if i know it is source)
also using the compare window for all java things is just not handy. Compare window takes up a lot of space the typing area is very small. Also when you clicked on a method Y to see the compare results of that method. And then you think ok i want to go to method X (that didnt have a change) to edit something and you open the quick outline to open method X. Nothing happens. Because the only thing you see in the editor is the method not the complete file. So let the compare window be the compare window and yes that you can have do quick edits there, have code completion and so on is very nice. But dont say that it is a replacement for the normal editor. It just isnt.
*** Bug 338277 has been marked as a duplicate of this bug. ***
I completely agree with Johan here and can't believe that anyone would want to do real work in a compare editor other than fixing up a line or two. Space-wise, the editable area is only about 30% of what a real editor gives you. Double-clicking on a file in the Package Explorer and having the compare editor selected rather than a real editor is completely unexpected and undesired behaviour for me. If you really feel that this is the behaviour that the majority of users desire, can we at least add a preference so users like Johan and myself can customize this action?
> Double-clicking on a file in the Package Explorer and having the compare > editor > selected rather than a real editor is completely unexpected and undesired > behaviour for me. If you really feel that this is the behaviour that the > majority of users desire, This behavior is now in for almost two years and you have never felt or seen an issue so far with it (or at least you didn't report it ;-). Is it really one in a common workflow? Also, since then we only got three bugs regarding this change.
i reported this or another bug way way back, I am still annoyed by this feature, and why can't it just be a preference? How many times i not do open with> now throughout a few days of usage.... And that are many unneeded mouse clicks and wasted time for me. the compare window will never be a full blown editor.. the real estate that you loose by that is just to big, not to mention that in the laptop world we loose more and more pixels so eclipse is "harder" to use.. (there are almost no 1920x1200 screens left in this world all go to 1920x1080 so that 10% loss which is the hardest noticeable in eclipse...)
The reason this bug surfaced for me was the recent call by the Eclipse PMC to use Eclipse 4.1 builds and some bugs in the 4.1 builds preventing me from working in my normal mode and performing my usual tasks. It is unfortunate that it takes more than 3 bug reports to constitute a real bug or to be indicative that users might want different/customizable behaviour.
*** Bug 307121 has been marked as a duplicate of this bug. ***
There has been a lot of discussion in this bug report, however, I think the current behavior does not make sense: 1. The compare editor does *NOT* have the same behavior as the regular compare editor. Behavior might come close, but there are differences. For example, recently closed Bug 500061, and save hooks (auto-layout) are not executed. 2. The compare editor is *ONLY* re-used when it is the current active editor and *ONLY* if it is a Java file, in all other cases a new editor is opened. This is far from consistent and far from intuitive. I expect that nobody is complaining because triggering this behavior will hardly occur. I only had the w.t.f. moment today after using Eclipse for year now.
(In reply to Rolf Theunissen from comment #16) > There has been a lot of discussion in this bug report, however, I think the > current behavior does not make sense: After all these years I tend to agree with you. *** This bug has been marked as a duplicate of bug 277693 ***
