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.
Issue: A build output scrolls to the last error, instead of the first error. Participant immediately scrolled to beginning to see first error. Analysis: UI Bug Recommendation(s): This seems to be an ongoing tug of war -should the output scroll or stay fixed at the top. The results here indicate that for compiler errors the first error is more important than the last (especially since one syntax error can create a string of error following it).
probably needs to be reassigned
dumping this out to general issues... not sure who would fix this (it may not be a projects issue?)
This issue is unrelated to projects. Removing projects keyword and reassigning for evaluation. (As described in http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss the current work on projects prototype has been stopped.)
I don't see clear statement form UI guys. After it's clear what to fix and how to fix it will be probably core issue. Until that reassigning to ui.
Adding to OutputTabTerm rewrite umbrella issue and adding Ivan to cc. Ivan, any suggestions for a quick fix?
I wish all tings were this easy. Term has a property scrollOnOutput() that you can tweak.
Okay. Now the question is how to know when the output is compiler output. I suppose I could just see if a Java exception has been recognized, and if so assume scrolling isn't wanted (although it may have scrolled by the time the exception happens, so then what). Not truly helpful, since I want to get that exception recognition code out of OutputTabTerm anyway... It would be preferable to have some kind of definition of expected behavior passed to getIO() (so, some kind of API change) that describes the use case so an appropriate behavior can be selected.
Compiler output doesn't output Java exceptions to be recognized. You might get no errors and you still want to not to scroll. You're right that some setting needs to be propagated through the IO client. The models I know of are: t) unix tty control a'la termio(7I) and stty(1). We would create a similar mechanism for netbeans IO and ocnvert the requests to calls to Term. a) escape sequences passed through the output stream. extend the ANSI sequences that Term recognizes. One other long-time desire has been to pass some information at startup-time to gover what kind of OW is tobe used. So for example plain NB and/or internal execution can use a "simple" termulator, while external execution and "native" environment can use the fancier Term. Model (t) has the advantage that switching of the underlying termulator is easier. Model (a) has the advantage that you don't need to create public API, although the sequences are a form of API. But this issue shouldn't be solved by itself. We need a more global look at thisd. For example I'd like to yank out all the exception recognition code out of OW and replace it with a pluggable filter.
IMO, I'd rather have an API that describes how the output window should behave - different applications are going to have different requirements. The pluggable filter thing also should be something provided when an app requests the IO device (either that or processes that want to do hyperlink-style stuff should html-ize their output and we should use a component appropriate to that). Either way, most of OutputTabTerm needs to go away (issue 28297). My gut feeling is that we probably won't get to addressing this stuff until post 4.0 (whenever that is) - in general the output window works, so there's more pressing stuff that's really badly broken (TreeTableView, for instance). But it should be addressed.
I think the HIE standpoint is clear: If the error is shown in the output window, it should scroll at the beginning of error output.
Well, given that that is what the new output window does, marking as fixed.
This issue was solved long time ago. Because nobody has reopened it neither added comments, we are verifying/closing it now. If you are still able to reproduce the problem, please reopen. Thanks in advance.