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.

Bug 33605 - change output behavior to not scroll when compiler errors are reported
Summary: change output behavior to not scroll when compiler errors are reported
Alias: None
Product: platform
Classification: Unclassified
Component: Output Window (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P3 blocker (vote)
Assignee: _ tboudreau
Depends on: 28297
  Show dependency tree
Reported: 2003-05-14 13:11 UTC by Chris Ledantec
Modified: 2008-12-22 22:23 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Chris Ledantec 2003-05-14 13:11:23 UTC
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).
Comment 1 Chris Ledantec 2003-05-14 13:11:45 UTC
probably needs to be reassigned
Comment 2 Chris Ledantec 2003-10-20 11:55:29 UTC
dumping this out to general issues... not sure who would fix this (it
may not be a projects issue?)
Comment 3 Vitezslav Stejskal 2003-11-24 15:18:35 UTC
This issue is unrelated to projects. Removing projects keyword and
reassigning for evaluation.

(As described in
the current work on projects prototype has been stopped.)
Comment 4 Milan Kubec 2003-11-28 09:43:30 UTC
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.
Comment 5 _ tboudreau 2003-11-28 14:43:23 UTC
Adding to OutputTabTerm rewrite umbrella issue and adding Ivan to cc.

Ivan, any suggestions for a quick fix?
Comment 6 ivan 2003-12-01 21:09:01 UTC
I wish all tings were this easy.
Term has a property scrollOnOutput() that you can tweak.
Comment 7 _ tboudreau 2003-12-01 23:10:30 UTC
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.
Comment 8 ivan 2003-12-02 00:11:39 UTC
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
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
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
at thisd. For example I'd like to yank out all the exception
code out of OW and replace it with a pluggable filter. 
Comment 9 _ tboudreau 2003-12-02 08:48:31 UTC
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.
Comment 10 jrojcek 2004-06-17 16:00:07 UTC
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.
Comment 11 _ tboudreau 2004-06-17 20:55:10 UTC
Well, given that that is what the new output window does, marking as
Comment 12 Marian Mirilovic 2005-12-20 15:51:47 UTC
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.