2009/1/27 Nick Treleaven
<nick.treleaven@btinternet.com>
On Mon, 26 Jan 2009 20:52:18 +0100
> >I assumed it might be parsing the setting indicators for each build
> >error. Or the build parsing, not sure. If the first, we could stop
> >highlighting errors after the first 50 or so.
>
> Ah, yeah. That(build error indicators) is more probable to be the cause
> for the slowness. However, I don't think there is much need to limit
> this, if users are bothered by this, they can simply disable the
> highlighting in the prefs dialog.
Well, *if* this is the cause, I think it would be best to limit the
errors. Error indicators are useful up to a point, but who is really
going to look at each error for >50, >100, >200 errors? If there are a
lot, they're likely caused by the same problem.
I agree with Nick, I always click on the error to go to the offending source line, but after fixing the first few errors I tend to re-compile to see if I actually fixed them and how many of the rest are consequential errors. So limiting how many are highlighted (or even how many are displayed if the treeview is the problem) may be a solution for slow machines and speeding up the turnaround fits well with my workflow.
Cheers
Lex