[Geany-devel] multiple error message slowness - Re: Update to build support
enrico.troeger at xxxxx
Tue Jan 27 18:50:03 UTC 2009
On Tue, 27 Jan 2009 23:03:02 +1100, Lex Trotman <elextr at gmail.com>
>2009/1/27 Nick Treleaven <nick.treleaven at btinternet.com>
>> On Mon, 26 Jan 2009 20:52:18 +0100
>> Enrico Tröger <enrico.troeger at 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.
Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the Devel