Re: [StrongED] StrongED 4.69b5 C mode bracket (mis)match freezing

[pdmiller@xxxxxxxxxxxxxxxxxx]

> In message <9e101f934850c84dde4fe624dd098aca.squirrel@xxxxxxxxxxxxxxxx>
>           pdmiller@xxxxxxxxxxxxxxxxxx wrote:
>
>> With Edit_MatchBrackets On I'm still encountering some short freezes
>> when
>> there is a bracket mismatch, either curly or round.
>
> Thanks for reporting this.
>
>> Admittedly, my C source file is a bit large - only about 49000 lines,
>> but
>> the freeze can be more than ten seconds for a round bracket mismatch
>> when
>> using StrongED 4.69b5 on my VRPC-AdjustSA (RISC OS 6.20) system.
>
> That file quite a bit larger than the largest file I've tested with -
> which was around 200k, 5000-ish lines. Is splitting up an option?
>
Yes but its not straightforward. Its purpose was and partly still is to
contain a set of common functions. It just sort of grew over the years
until I made the decision that reorganising and maintaining a set of files
(and all the resulting header files, updating files that use the common
functions, etc) would be just as big a job as maintaining it as it is. The
only downside till now was that it takes a whole cup of tea to compile it
(or a cup of tea and a cake on the Raspberry Pi).

>> The freezes occur during editing when adding a new left bracket or when
>> moving the caret up or down the document passing through a line with a a
>> mismatched left bracket (with the caret to the right of the bracket).
>
> Perhaps part of the reason why I haven't seen this is that I always
> enter both brackets at once and then move the caret back to write
> whatever needs to go between them. This way there's less risk of
> mismatched brackets. I do the same with string delimiters.
> Maybe that's just me. :-)
>
Of course, but you can't necessarily, easily avoid the situation. For
example, if you start a new function and insert a left curly bracket for
the start of the function body - you'll introduce a curly bracket mismatch
with the caret to the right of it and so invoke the bracket matching and
get the consequent mini freeze for the large file. The same will apply for
round brackets when starting (e.g.) a condition. The only way to avoid
that happening seems to be to insert the closing bracket before inserting
the opening bracket It's a bit fiddly though to have to do that every
time.

>> I am surmising here so you can correct me humanely, but it seems to me
>> that the bracket match routine isn't stopping when it reaches the
>> first line that is outside the visible window area (so there won't be a
>> visible bracket to highlight), but just keeps on searching until it
>> reaches the end of the document.
>
> Correct. The code isn't just for highlighting brackets but also to go to
> the matching bracket (Ctrl-B) and for selecting everything enclosed
> (Ctrl-Shift-B). For this reason it cannot stop once outside the visible
> area.
>
Yes. I thought that would be the case. So the conclusion is the obvious
one that matching brackets in an excessively large file will take a long
time when there is no match.

> I have some ideas on making things faster such as bracket highlighting
> being limited to what's visible only. This would however mean that you
> won't be able to see if a bracket is mismatched or not when the matching
> bracket is off screen.
>
> I'll do some testing with 4.70a1 and if it's reasonable will back port
> it to 4.69 but there's a chance you'll have to wait for 4.70a1 to get
> this fixed - if at all.
>

Ok. I've set Edit_MatchBrackets to Off in the !StrED_cfg UserPrefs C mode
choices file for now. Perhaps at most all that would be needed is an
option to limit the bracket highlighting to a number of lines
(Default=5000?) before stopping.


Regards,

Pete Miller.





-- 
To unsubscribe send a mail to StrongED+unsubscribe@xxxxxxxxxxxxxx