This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
[ BUILD # : 200711131200 ] [ JDK VERSION : 1.6.0_02 ] .) Open a java file .) Open a xml file .) Open another java file .) Press ALT-LEFT -> It should switch to the xml file but it switches to the first java file.
Reproducible on Solaris. Very annoying.
This is as designed in the new keybinding profile (the new default one called Netbeans). alt-left/right now navigates through the editor history. If you want to switch tabs please use ctrl-page up/page down. Alternatively you can switch to Netbeans 5.5 keybindings in Tools-Options -> Keymap by changing the active profile.
Well that is exactly the problem, isn't it that alt-left/right does NOT switch through the history correctly. It does ignores NON-java files when switching through the history.
moving opened issues from TM <= 6.1 to TM=Dev
Should be easy..
Is really pgebauer going to fix this? > does NOT switch through the history correctly. It does ignores NON-java files when switching through the history. Well, the problem is that opening a file is not tracked as an action in the navigation history. The IDE only tracks certain actions like ctrl + mouse click, various 'go to' actions, etc. I don't remember the exact list. For example try to open several files by clicking their icons in the projects navigator. All the opened editor windows will have their history navigation buttons disabled. I'm not exactly sure why this was designed this way, but perhaps we should change this and track 'file open' action in the history as well. Ondro, do you have any suggestion?
> perhaps we should change this and track 'file open' action in the history as well. Ondro, do you have any suggestion? Agreed, but let me restate this. Opening a file should be tracked as "navigation point" if focus is set into a new file. If a file is open silently in the background (i'm not sure it is possible in nb), it should not be tracked.
This will be a bit tricky. We could blindly insert a JumpList entry of (new-opened-file:0) but openide/text can set an explicit caret position - see CloneableEditor:509 - setCaret() call which would be a better candidate for the jumplist. Either there should be an API for openide/text to add to jumplist or the initial setDot() will be made always (not only conditionally) and jumplist will remember first setDot() automatically.
*** Issue 115422 has been marked as a duplicate of this issue. ***
For me it's not clear what fix is expected. if user goes through methods hierarchy and this way new files are opened, it's good to have this files in history, but if use opened set of files from a project tree it may be not good to add such files to the history, also it's a question if tab activation should be in history for already opened files etc. There is a way for tabs switching without history. In my opinion the issue is an enhancement request at best but if any objections please comment. reproducible with 6.7m3
The essential point of this issue is that history navigation does not navigate through history (as expected), which is a defect, not enhancement, IMO. > if user opened set of files from a project tree it may be not good to > add such files to the history Yes, this action should be tracked as history navigation point, because it opens a file and sets it in focus. It is a clear "point I have been to" from users' perspective. If you select multiple files and open them by right-click and "Open", only the one which is opened in the editor and "focused" should be inserted into navigation history, though. > also it's a question if tab activation should be in history for already opened files etc. Yes for the same reason .. when users focus their attention on the code in that file, it is a "navigation" point so it should be in the history and users should be able to navigate back to that piece of code.
*** Issue 156595 has been marked as a duplicate of this issue. ***
Set target-milestone of open issue to TBD (was < 7.3, f.e. 6.8), so the issue doesn't get lost.
Set target-milestone of open issue to TBD (was < 7.3, f.e. 6.8), so the issue doesn't get lost. This time the target milestone is really set.
For some people this would be nice improvement, some people could disagree with suggestion. This issue is more than 5 years old and navigation is now connected with jumpto functionality and it could be confusing to change it. We can discuss this when somebody from ui review team will review back and forward implementation. I am returning this back to enhancement.
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss
Still valid in 8.2 dev Product Version: NetBeans IDE Dev (Build 201607100002)