[Geany-devel] multiple error message slowness - Re: Update to build support

Enrico Tröger enrico.troeger at xxxxx
Wed Jan 28 15:25:48 UTC 2009

On Wed, 28 Jan 2009 14:15:41 +0100, Frank Lanitz <frank at frank.uvena.de>

>On Tue, 27 Jan 2009 19:50:03 +0100
>Enrico Tröger <enrico.troeger at uvena.de> wrote:
>> On Tue, 27 Jan 2009 23:03:02 +1100, Lex Trotman <elextr at gmail.com>
>> wrote:
>> >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:
>> >>
>> >> 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.
>Such an option should be optional with default value 0 for no limit

Do we really need to add an option for this?
In the meantime, I'm convinced it should be ok to just limit the error
indicators to 50 or 100.


Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20090128/850227d0/attachment.pgp>

More information about the Devel mailing list