Created attachment 5420 [details]
Example of environment for the graphics/marker

Could you please tell me some more information about this problem?
Does it appear this way in all OS's, or is it specifically related to
Linux? Regarding the icon, it's my understanding that a parser error
should be viewed like any other error, with the annotation color
indicating an error, and the correct glyph appearing in the margin.
Long ago, when designing badges and then again when designing
annotation colors, we decided that errors should all be shown in the
same way. (Unless you fix the error you cannot continue anyway.) So
parser errors should perhaps look the same as any other error. Is
there a reason why this is not so?

I don't understand why it should appear differently on Linux than on
Solaris.
Re icons - parser kicks in quite often when the user stops typing and
- although it is quite precise - there may be some things missing and
some misreports (because of not yet finished curly brace, there can be
 well 3 or 4 markers). I don't know whether (1) the default error
color is not too intrusive (2) it is really not useful to have a
difference between parser errors, which are after all only informative
and compiler errors, which are authoritative.

Hi Svata,
No, I don't think it does. I was just focusing on the OS in the bug,
which said Linux instead of "All". Dirk and I downloaded the build and
looked at this and there are several things to note:
1. For some reason, syntax errors get two icons, one in the gutter and
one outside the gutter. This seems wrong.
2. As you say, syntax errors should not look different from compiler
errors, and compiler errors should trump. (Bug #22374)
3. Syntax errors should be indicated by the wavy line underneath the
code. It is a much better solution than showing the syntax error in
the gutter, where the user then has to search the line for the error.

Summary:
We need to fix the double glyph problem.(Hopefully this is being
addressed by bug 22374.)

Syntax errors should be shown in the line, rather than in the gutter.
Then if there is a glyph in the gutter it might be the result of not
being able to compile code because of a syntax error, but there would
be no special marking in the gutter for syntax errors. Those would be
shown by the wavy underline discussed in a separate proposal.
So I don't think we need a new glyph. The existing error glyph should
be used.
best,
b.

Please, look at my past comments on nbui@ in case you missed them.
Proposal to display an underline is nice, but we are *not able* to
underline the offending expression. Until we step aside from
JavaSoft's parser, we know only starting position; underlining to the
end of line seems ridiculous.

You misunderstood me. I don't think that the parser and the compiler
should use the same badge and I after some thinking I am quite firm on
that for the reasons I gave: parser gives optional hints. TRhe
compiler is what the user really cares about. In the case when a
compiler and parser reports the same thing, the compiler is right and
its message should prevail.

Oops, I seem to misread the proposal; OK, we'll try to underline the
whole line (if possible). The comment about glyph in gutter remains valid.

For the records -- at explicit request and decision of the UI, the
parser annotations will use the same graphics as the errors reported
by the compiler.

Reorganization of java component