feedback needed: javadoc errors highlihting

Hi, All,

We are about to make the change that we are in doubt will suit all users.
The errors in javadoc are made able to be moved under warning category. The
thing that is potential to cause confusion is the highlighting of unresolved
references in javadoc.
Since those are warnings, we'd better not to use red color for those
highlihtings if they are warnings, but since those are unresolved
references, red is preferrable. The question to you is:
will it be OK if unresolved refs will be red in the editor, but in error
stripe yellow color will be shown?

Eugene.


21 comments

That sounds okay but I wonder if there's a better solution. I'll think
about it.

Eugene Vigdorchik (JetBrains) wrote:

Hi, All,

We are about to make the change that we are in doubt will suit all users.
The errors in javadoc are made able to be moved under warning category. The
thing that is potential to cause confusion is the highlighting of unresolved
references in javadoc.
Since those are warnings, we'd better not to use red color for those
highlihtings if they are warnings, but since those are unresolved
references, red is preferrable. The question to you is:
will it be OK if unresolved refs will be red in the editor, but in error
stripe yellow color will be shown?

Eugene.

0

Um.. why don't you just break it out into two categories, one for error severity and one for warning severity by default?

You already have "JavaDoc errors" and "Unknown javadoc tags" so just breakup "JavaDoc errors" to "Javadoc warnings" and "Javadoc unresolved references."

0

Yeah, this was done.
What I'm talking about is the possible difference in colors in error stripe
and in the editor. We are going to have red highlights in the editor but
yellow marks in the error stripe. Probably it is just OK to you, I was just
feeling this change in UI needs to be somehow discussed:)

Eugene.

"Alex" <no_mail@jetbrains.com> wrote in message
news:7590757.1132685801483.JavaMail.javamailuser@localhost...

Um.. why don't you just break it out into two categories, one for error

severity and one for warning severity by default?
>

You already have "JavaDoc errors" and "Unknown javadoc tags" so just

breakup "JavaDoc errors" to "Javadoc warnings" and "Javadoc unresolved
references."


0

Eugene Vigdorchik (JetBrains) wrote:

What I'm talking about is the possible difference in colors in error stripe


On that note, is anything going to be changed in terms of having more
colors available for warnings in the editor?

As it is, there are a few errors and warnings I can configure separately
in colors/fonts: Invalid escape codes, unknown symbols, deprecated
symbols, unused symbols, unmatched braces, bad characters, and so on.
But for the hundreds of inspections that are available, I can only set
the level to "warning" or "error".

I thought about this a while while writing this post, and came to the
conclusion that what I want is most likely two orthogonal settings for
each warning:

1) The severity level. Here, I'd love to have a "notice" level, which
could be used for things that work just fine and don't need immediate
attention but should eventually be changed -- for example, using a plain
for loop where a foreach loop could be used; this is perfectly fine but
I'd like to convert it eventually so I want some sort of indication
here. Then the "warning" severity could be reserved for things I feel
indicate potential bugs or constructs that are sufficiently confusing
that they ought to be fixed soon/right now, and "error" for things that
are absolutely forbidden.

This would also determine the color of the error square (perhaps
blue/yellow/red).

2) The markup in the editor, in the actual text. By default, warnings
would be yellow and errors would have red underlines, or something like
that. But I'd like to be able to configure specific types of markup for
specific kinds of errors, just like I can for unknown symbols and so on.
For example, I might want to mark naming standard violations in a
certain way, or violations of complexity metrics, or maybe I want a
special markup for constructs that indicate performance problems.

Of course this would lead to some problems when there are multiple
errors/warnings at the same location... but that problem is already
present, only at a smaller scale: If an unused symbol violates a naming
standard, what is the resulting markup? In any case, I'd at least love
to see the 'notice' severity level, even if separate editor markup isn't
implemented.

Any comments or thoughts about this? Have I missed something obvious?

0

I really think we need another inspection level, e.g. "info".
I feel it would be very confusing to have different colors in the editor
and in the gutter.
Many inspections could by default be moved to "info" level.
Then I could take "warnings" more seriously and it would be fine to show
"unresolved references" as yellow warning only.

Eugene Vigdorchik (JetBrains) wrote:

Yeah, this was done.
What I'm talking about is the possible difference in colors in error stripe
and in the editor. We are going to have red highlights in the editor but
yellow marks in the error stripe. Probably it is just OK to you, I was just
feeling this change in UI needs to be somehow discussed:)

Eugene.

"Alex" <no_mail@jetbrains.com> wrote in message
news:7590757.1132685801483.JavaMail.javamailuser@localhost...

>> Um.. why don't you just break it out into two categories, one for error

severity and one for warning severity by default?

>> You already have "JavaDoc errors" and "Unknown javadoc tags" so just

breakup "JavaDoc errors" to "Javadoc warnings" and "Javadoc unresolved
references."

0

Eugene, what about highlighting the unresolved reference and the sidebar
in dark red?

Eugene Vigdorchik (JetBrains) wrote:

Hi, All,

We are about to make the change that we are in doubt will suit all users.
The errors in javadoc are made able to be moved under warning category. The
thing that is potential to cause confusion is the highlighting of unresolved
references in javadoc.
Since those are warnings, we'd better not to use red color for those
highlihtings if they are warnings, but since those are unresolved
references, red is preferrable. The question to you is:
will it be OK if unresolved refs will be red in the editor, but in error
stripe yellow color will be shown?

Eugene.

0

I wouldn't do that. If it is red in the editor, then it should have a red error stripe.

You could add this as an optional decorations like "error - editor, warning - stripe", but I wouldn't make it the default because it is confusing.

0

Works for me. I always change them to yellow anyways. Red is for stuff
that will not compile.

Eugene Vigdorchik (JetBrains) wrote:

Hi, All,

>

We are about to make the change that we are in doubt will suit all users.
The errors in javadoc are made able to be moved under warning category. The
thing that is potential to cause confusion is the highlighting of unresolved
references in javadoc.
Since those are warnings, we'd better not to use red color for those
highlihtings if they are warnings, but since those are unresolved
references, red is preferrable. The question to you is:
will it be OK if unresolved refs will be red in the editor, but in error
stripe yellow color will be shown?

>

Eugene.

>
>

0

Eugene Vigdorchik (JetBrains) wrote:

Yeah, this was done.
What I'm talking about is the possible difference in colors in error stripe
and in the editor. We are going to have red highlights in the editor but
yellow marks in the error stripe. Probably it is just OK to you, I was just
feeling this change in UI needs to be somehow discussed:)


I don't think it's a good idea to have inconsistent editor/error stripe coloring. Not much
to win except confusion.

My 2c

Sascha

0

Red highlighting in the editor and yellow marks in the warning I don't like at all. However currently there already are some warnings displayed red in the editor and yellow in the error stripe. Like the "Numeric Overflow in expression" warning on the following code:

Perhaps something can be changed there too?

Bas

0

Also, currently greyed out (unused) and stricken out (deprecated) code is marked
yellow too. Maybe it's not so unusual for javadoc references to be (dark) red
and erroor stripe to be yellow.

Bas Leijdekkers wrote:

Red highlighting in the editor and yellow marks in the warning I don't like at all. However currently there already are some warnings displayed red in the editor and yellow in the error stripe. Like the "Numeric Overflow in expression" warning on the following code:

 class NumericOverflow {
> 	{
> 		int i = 1/0;
> 		int j = -1/0;
> 		double d = 1.0/0.0;
> 		double e = -1.0/0.0;
> 		double f = 1.0/-0.0;
> 	}
> }
> ]]>

Perhaps something can be changed there too?

Bas

0

This reminded me that I had customized my Error Stripe Mark for Unused symbol to be a grey line and Deprecated symbol to be a black line to match the decoration in the editor pane.

Before I had done this, there were a number of times when I would see yellow stripes in the gutter for the code visbile in the editor pane, and I would search around looking for what was highlighted in yellow. In took me a few seconds to realize that it was the Unused Symbols which were greyed out.

I like how the editor styles the Unused symbol and Deprecated symbol, so I adjusted the error stripe to match so it is consistent. (See attached screenshot)

I would recommend Jetbrains do this for all of the errors and warnings.



Attachment(s):
4049_unused_symbol_stripe_mark.png
0

Oh yeah, I forgot I have that I have unused and deprecated code marked
with a yellow underline too.

Bas

Keith Lea wrote:

Also, currently greyed out (unused) and stricken out (deprecated) code is marked
yellow too. Maybe it's not so unusual for javadoc references to be (dark) red
and erroor stripe to be yellow.

Bas Leijdekkers wrote:

>> Red highlighting in the editor and yellow marks in the warning I don't like at all. However currently there already are some warnings displayed red in the editor and yellow in the error stripe. Like the "Numeric Overflow in expression" warning on the following code:
>>

> class NumericOverflow {
>> 	{
>> 		int i = 1/0;
>> 		int j = -1/0;
>> 		double d = 1.0/0.0;
>> 		double e = -1.0/0.0;
>> 		double f = 1.0/-0.0;
>> 	}
>> }
>> ]]>

>> Perhaps something can be changed there too?
>>
>> Bas

0

-1 from me for different colours in sidebar and the editor.

Can't you just use the user's preference to colour it? So if the user
wants to see unresolved JavaDoc as error it is red and underlined, red
in the sidebar; if he wants to see it as a warning it becomes
yellow-highlighted in the editor and yellow in the sidebar.

That would match perfectly the behaviour of other inspections.
R

0

Eugene Vigdorchik (JetBrains) wrote:

Yeah, this was done.
What I'm talking about is the possible difference in colors in error stripe
and in the editor. We are going to have red highlights in the editor but
yellow marks in the error stripe. Probably it is just OK to you, I was just
feeling this change in UI needs to be somehow discussed:)


BTW, the old tracker request
http://www.intellij.net/tracker/idea/viewSCR?publicId=36820 (which is
really a duplicate of a request of mine) doesn't appear to have been
copied over to JIRA even though it has plenty of votes.

Any chance of getting something like this in Demetra?

Regards,
Jens

0

Eugene Vigdorchik (JetBrains) wrote:

will it be OK if unresolved refs will be red in the editor, but in error
stripe yellow color will be shown?


It feels odd. If there is an error stripe in the editor, I expect a
error stripe (i.e., red) in the margin, and vice-versa. I can choose to
ignore the yellow stripes in the margin, because they indicate 'this is
probably not a very good idea', rather than something fatal.

How about the way you handle this the way you do in jsp pages: links to
unknown/unresolvable resources (images, links) are hilighted with yellow
background, and have a yellow error stripe in the margin,

Regards,
Edwin

0

-1

Sounds confusing to me! Personally I'd be happy with yellow markings in both the editor and in the error stripe. You need to have consistency between the editor and the error stripe, otherwise there's the potential for more of these wooly areas to creep in and the whole colour-coding scheme will become useless.

As someone else mentioned, most of the time I only really look at red stripes and I'd prefer them to only point out compilation issues.

0

I'd rather the gutter and the highlight were the same (or user-specified).

I would prefer to see the red gutter stripe reserved for critical errors ('won't compile' or 'won't run').

To be honest, I think the whole gutter concept needs revamping. It's a great idea, but its now trying to do too much with too little. Some of our legacy source is so full of warnings that the gutter is a mass of yellow and we can't see bookmarks, etc. If we could quickly switch between different groups of gutter indications, it might help...

Perhaps we need a greater variety of indicator categories (e.g. Critical Error, Error, Warning, Information, Hint, etc., perhaps make them user-selectable or user-definable), and more space to display them.

I've been thinking that multiple gutters - or a filtered gutter - might be one way to go. Provide the option to show a certain subset of indicators, or perhaps allow two gutters side by side. Or you could have a runtime/debug gutter (breakpoints, bookmarks, execution point, etc), and an editing gutter (errors, warnings, bookmarks, hints, todo, etc). Clearly there is likely to be some overlap (e.g. bookmarks), but when there is too much information to display in a single gutter, some kind of task-specific display switching could be useful - Eclipse goes a little too far with this for my taste, but I think there is merit in the idea - if it can be made user friendly and customisable.

0

Dave Lorde wrote:

I'd rather the gutter and the highlight were the same (or user-specified).

I would prefer to see the red gutter stripe reserved for critical errors ('won't compile' or 'won't run').

To be honest, I think the whole gutter concept needs revamping. It's a great idea, but its now trying to do too much with too little. Some of our legacy source is so full of warnings that the gutter is a mass of yellow and we can't see bookmarks, etc. If we could quickly switch between different groups of gutter indications, it might help...

Perhaps we need a greater variety of indicator categories (e.g. Critical Error, Error, Warning, Information, Hint, etc., perhaps make them user-selectable or user-definable), and more space to display them.

I've been thinking that multiple gutters - or a filtered gutter - might be one way to go. Provide the option to show a certain subset of indicators, or perhaps allow two gutters side by side. Or you could have a runtime/debug gutter (breakpoints, bookmarks, execution point, etc), and an editing gutter (errors, warnings, bookmarks, hints, todo, etc). Clearly there is likely to be some overlap (e.g. bookmarks), but when there is too much information to display in a single gutter, some kind of task-specific display switching could be useful - Eclipse goes a little too far with this for my taste, but I think there is merit in the idea - if it can be made user friendly and customisable.

+1

0

I submitted a possible solution into Jira back in May. It never went anywhere.

http://www.jetbrains.net/jira/browse/IDEA-2208

I'm not even that sold on this one idea, but I think something needs to be
done. It's just too easy to lose track of a bookmark/todo/highlighted item.

Tobin


0

Please sign in to leave a comment.