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.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel