Error list shows "dirty" icon.

[CyrusNajmabadi]

This is on Update1 RC. Not sure what that dirty * is supposed to mean.

Also, seeing (Features (Features\Features)) is pretty darn weird.

[CyrusNajmabadi]

Also down here:

[davkean]

Saw a customer report of this as well.

[dpoeschl]

* triggers my "I need to hit ctrl+s to make the * go away" reflex.

[davkean]

Apparently this is by design according to @srivatsn to indicate that the contents of the Error List is incomplete. This is the wrong use of this - * means "not saved" in VS, not "incomplete".

[CyrusNajmabadi]

Er... I can't imagine that being an appropriate use of * @srivatsn . How about just have some text in the title that says that results are still being computed?

Also, we've never needed this before in the history of VS (despite errors being computed in the background for languages like VB), so I'm skeptical this is needed now.

[DzonnyDZ]

I left VS open for several hours not working with it and the asterisk (*) was still shown. I din't believe that the background analysis is so inefficient.

[srivatsn]

Adding @markw-t to see the feedback about the asterisk. @DzonnyDZ, my understanding is that there was a bug about the * not going away but that it was fixed recently.

[markw-t]

There was a bug in this area with the * showing when there was no dirty state; that said in large projects the normal state of being is that a background analyzer is probably running somewhere. The fix to the bug was checked in late in September and should be in Visual Studio 2015 Update 1 RC so I'm surprised if you're still seeing it for cases where no analysis is actually happening. Thanks for the design feedback on use of * - we'll consider using a different icon/symbol when we've had a bit more time for folks to work with it, but I hear your points re this being about "unsaved state" rather than incomplete/stale results.

[markw-t]

BTW: we had "analyzing" in the bar in an early prototype, and nobody liked that too because it changed often enough to be distracting. We need a single character representation I think. Open to better suggestions than * of course :-)

[davkean]

@markw-t Why is it needed at all? As Cyrus mentioned, we've never needed this in the past even though background builds were asynchronous.

[markw-t]

I'll let @srivatsn and @heejaechang speak more to this, but as I understand it the analyzers team has received quite a bit of feedback about not being able to know whether the state of the error list is "trusted"/"final" or not. We did this as in response to that feedback.

[heejaechang]

we didn't need it for C# since we never did full analysis. for VB, I am not sure why they didn't need it. they might never be able to support Roslyn size solution from the beginning or not having user analyzer made it a bit easy for them.

regardless, without it, there is no way for user to know when they can trust error list, so we do need some sort of progress bar.

analyzing whole solution can't be faster than how much build takes (actually it is way slower since we build concurrently, but IDE analysis is designed to be run single thread to reduce allocations and CPU cost) and we do know Roslyn + FxCop analyzers take about 5 mins to finish full solution analysis. so I don't think we can remove some kind of indication for it. especially since user analyzers are third party code, we don't have any control on how performant those are.

question about "", I don't know. "analyzing" was fine as much as "" so I will leave it to people who don't like it.

[markw-t]

Just to add some more historical context: we also tried a progress bar but found it to be too intrusive as analysis was almost always in progress. Hence the attempt to have the minimum-intrusion indication that the state can/cannot be considered complete.

[heejaechang]

I remembered VB experience I had. and that might be the reason they didn't care. so, if I remember correctly, they don't show errors incrementally, so if you make some kind of semantic errors, you don't see any errors and then boom, you get like 500 errors (whatever the cap was) and that's it. since they show/update errors only when they are done analysis per project I believe, and since errors are limited at 500 (or something), they probably didn't need it.

[davkean]

Understood, so you have feedback that you need some indication that work is happening in the background.

Now you have some additional feedback; the indication you are currently using, is confusing with the existing dirty/unsaved paradigm that's been around for as long as I remember (VS2005, maybe?).

Can you go offline with the design team and figure out a either a new indication or look at other examples of this elsewhere in Windows and reuse those?

[markw-t]

Yep. Thanks for the feedback - I'll take this offline with our design folks to find a better indicator. From the point of view of framing that, would replacing * with some other icon/token be enough to address the concerns folks on this thread are raising?

[paul1956]

In VB 2013 limit was around 100, now I have seen 300,000 but they dribble out over minutes. Having an indication is a really good idea just pick another character. It would be really nice to have a per file limit and a way to just get the issues with the one file open in the editor sorting doesn't work well when issues dribble out.

[paul1956]

Can I suggest the Hourglass?

[CyrusNajmabadi]

Does it need to be a character? As @paul1956 mentions, it could just be a glyph. And hourglass is a much better indicator of "something is happening and could take a while"

Out of curiosity, what do the other IDEs do? I can't remember ever seeing something like this in IntelliJ or Eclipse.

[heejaechang]

@paul1956 about "a way to just get the issues with the one file open"

is one of these not what you want?

[heejaechang]

@CyrusNajmabadi not sure how they do. do they support live incremental analysis of full solution?

by the way, how did you get "Features (Features/Features)" ?

[paul1956]

@heejaechang exactly what I want, never noticed that dropdown thanks.