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.
Let's say I introduce an error in my source file. (Why do I have to trigger tasklist updates by Ctrl-S? I'd like it to refresh the items for the -current- file in the tasklist by the background editor scan). Now I want to navigate to that error --> F12 (Navigate | Next Error). It doesn't work - it's disabled! I know there is/was a way to make non-output windows tie into this - I did it in the suggestions module a long time ago. If you scan the tasklist sources for jumpNext you should find it. I'm marking this as a bug rather than an enhancement because it's a usability bug; I don't see how I can really use the tasklist as part of interactive editing without this.
next/previous error actions get activated when the task list window gets activated - i'll check how this works in output window and fix it.
i did a bit of digging and found out that output window handles next/prev error actions the same way as the new task list window. the only exception is that the output window activates itself when the compilation is finished. this updates the global action map so the navigation actions are enabled. switching to the task list window activates actions for next/prev task navigation. imo, this is in accordance with the window system/global actions rules. perhaps i could activate the task list window at least once when the first task appears in it to enable the navigation actions. but some users might find that annoying...
jano, any opinion on this?
Next/Previous error should work when there's an error in the source code. If a source code is underlined by red color, it should be possible to get to the error using the Next/Previous error actions. I don't think it should be related to the task list window. Even if it's closed the actions should work.
if next/previous error action will be bound to underlined errors in opened editor then how is this supposed to work when output or task windows try to activate their own next/previous actions when focused?? (cc'ing jtulach as the alleged author of actions framework)
The actions jumpNext/jumpPrev are always handled by the last activated TopComponent that provides them. If user goes to Output Window and then to editor, explorer then F11 will be handled by Output Window, if the user visits Show Usages (which also provides F11) then the actions will be handled by Show Usages, until user visits another window that can handle jumpNext/jumpPrev. If you want some window to start to handle jumpNext/jumpPrev without receiving the user focus, then there is a way. I think it is enough to call tc.requestVisible().
> The actions jumpNext/jumpPrev are always handled by the last activated TopComponent that provides them. that's the problem, if editor window will behave the same way then any 'jump next/prev' action from task list/usages/output window will activate the editor which will remap these actions to its own...
Indeed, editor window cannot define jumpNext/jumpPrev.
No point in postponing this issue to "future". And with tasklist becoming visible by default in 6.5 this issue either has to be resolved now or closed WONTFIX forever. Can you summarize what are potential fixes? If any.
There seems to be a different set of errors the IDE can compute : (1) errors in project computed by background scanning (2) errors in project computed by Build Project action Most of them indicate errors in source files the user needs to fix. The fact where those errors are shown (Output, Task List, Editor) and how they were computed isn't important IMO. It should work like this: There's a single list of errors in the project (no matter how it was computed). The user hits the Next Error action. The editor jumps to the place of error. If an output window is visible, then the error is highlighted in Output window as well. If the Task list is visible, the error task is highlighted. In other words, the list of errors shouldn't be tight to any focused window. The errors are in user's project. With next/prev error actions the user wants to jump between them, primarily to the place where he can fix them, which is the editor in majority of cases. If an error shows up only in Output window, then it should be brought to front and highlighted. The proper ordering of errors to jump through may be tricky.
Current state seems reasonable. When user runs a project with errors Output window is focused automatically, next/prev error action highlights related content in Output and jumps to the place of error (according to Output error list). When Tasklist window is active, next/prev error action is driven by Tasklist error list. I'm not sure how did it behave when it was reported, but this seems reasonable -> WONTFIX
(In reply to comment #11) > Current state seems reasonable. Not according to the argument given in comment #10. The general UI for navigating through errors (or warnings) in the IDE is not very comfortable. Whether we can actually implement the proposed UI is another question. The Next/Previous Error actions are also bound by various other windows in the bottom sliding mode (Find Usages, Search Results, Refactoring Preview) where the items do not necessarily correspond to errors or warnings (though they may). If the user has opened a list of items in one of these windows and uses Ctrl-PERIOD to cycle through them, it would be surprising to come to the end and suddenly start cycling through items from another window which may not even be of interest any more; or, worse, for Ctrl-PERIOD to jump back and forth between editor lines based on items from different windows according to some collated IDE-wide list. Another point to consider is that there is no KB shortcut that I know of which allows you to cycle through annotations (such as warnings) in the current editor window. There is a "Next Error in Editor" action but it appears to be unbound by default.
(In reply to Jesse Glick from comment
(In reply to Jesse Glick from comment #12) > ... do not necessarily correspond to errors or warnings (though they > may). I agree with Jesse. I think a name like 'Reveal Next Item in Editor' is a more sensible name for the existing Ctrl-Period action. Only on certain occasions are the items errors/warnings (please see the attached screencast) If 'Next Error' (Ctrl-.) gets to be renamed, then 'Next Error in Editor' could be renamed to 'Next Error/Warning' and we definitely need a shortcut for it. What would a new user think that Next Error means reading the following entry in the Shortcuts card? Ctrl-Period/Comma -- Next/previous usage/compile error I always thought it should be the next issue in the current editor (until I discovered Next Error in Editor several years later)
Created attachment 143475 [details] screencast showing various items navigated through with Ctrl-PERIOD In this particular case only a few are errors or warnings. Many are leget items like search result elements, todo items etc.