On Tue, 27 Jan 2009 23:03:02 +1100, Lex Trotman elextr@gmail.com wrote:
2009/1/27 Nick Treleaven nick.treleaven@btinternet.com
On Mon, 26 Jan 2009 20:52:18 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
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.
Hmm ok, why not. You are both right, that usually fixing the first few errors solves the other 100 errors as well :). And if not, then there is probably a much bigger problem in the used code, haha.
Regards, Enrico