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

[Fred Graute <fjgraute@xxxxxxxxx>]

In message <7080f96344f9bdbba659657981bcf322.squirrel@xxxxxxxxxxxxxxxx>
          pdmiller@xxxxxxxxxxxxxxxxxx wrote:

> > In message <9e101f934850c84dde4fe624dd098aca.squirrel@xxxxxxxxxxxxxxxx>
> >           pdmiller@xxxxxxxxxxxxxxxxxx wrote:
> >
> > 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. [snip reasons]

Understood.

> >> 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.

There is a slight delay before bracket matching kicks in. This to avoid
that moving through the file using the cursor keys causes short freezes
resulting in jerky scrolling.

So, if you enter both brackets at the same time there should be no
freeze as there is no bracket mismatch. You could even set up shortcuts
to do this automatically, for example:

  Shortcuts
    ``{    {\n\@\n}\n
  End

There are already shortcuts for most keywords that use a condition, such
as 'i(' for 'if ()'.

> >> 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.

That's right. Even when there is a match it may take a long time if the
distance is large enough, especially when scanning for the opening
bracket.

> 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.

Yes, that's one of the options I'll be looking into. It might be easier
though - code wise - to use a limit based on number of bytes. Checking
that you've scanned 10,000 bytes is quicker than checking if you've done
5000 lines.

Cheers,
Fred.

-- 
StrongED Developer
http://www.stronged.iconbar.com/

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