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

[Fred Graute <fjgraute@xxxxxxxxx>]

In message <709c564fa00d977c685f7cbe4bc107c2.squirrel@xxxxxxxxxxxxxxxx>
          pdmiller@xxxxxxxxxxxxxxxxxx wrote:

> > In message <7080f96344f9bdbba659657981bcf322.squirrel@xxxxxxxxxxxxxxxx>
> >           pdmiller@xxxxxxxxxxxxxxxxxx wrote:
> >
> >> > In message
> >> <9e101f934850c84dde4fe624dd098aca.squirrel@xxxxxxxxxxxxxxxx>
> >> >           pdmiller@xxxxxxxxxxxxxxxxxx wrote:
>
> [snip previous details]
>
> > 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.
> >
> By 'at the same time' I assume you mean by some automatic means and not
> typed in at the keyboard because no matter how fast I type I always get
> the freeze occurring on the Raspberry Pi and VirtualRPC-AdjustSA.

On the Iyonix I can type both brackets manually without a freeze. It may
be that in your case StrongED is being returned to faster for some
reason. It uses Wimp_PollIdle with a varying time delay depending on a
number of conditions.

[snip use of shortcuts to insert brackets]

> (I've tried files of size 11000 - 15000 lines as well as the 49000
> lines file and all can have some noticeable delay when a mismatch
> occurs. For interest the file lengths in bytes are about 280000 up to
> 1.2 megabytes for the 49000 line file).

The file I'm testing with has almost 42000 lines (1.4 MB) and, perhaps
more important, 3152 {} pairs and 13840 () pairs. If I create a
mismatched { near the start of the text then there is no noticeable
delay. A mismatched } at the end causes a 14 sec freeze.

A mismatched ( near start results in a 14 seconds delay and 25-ish for a
mismatched ) at the end.

> [snip surmise on use of bracket matching code]

> >> 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.
>
> Yes, I can see that would be the case. My suggestion of a number of lines
> was influenced by a DDE tool I wrote that tracks line numbers while
> scanning a C file so it can output throwback messages referencing the line
> number the message applies to.
>
> It sounds like you've got the bracket matching code as optimised as you
> can and so a delay is inevitable for the large files I'm editing, [..]

There is still room for improvement in the bracket matching code. At the
moment it's using a routine called CommentLevel which checks if a given
offset in the text is inside a comment or not. CommentLevel needs to
scan through the text too so it would be more efficient to scan for
comments in the bracket matching code directly.

Also, CommentLevel only scans forward through the text so doesn't do
well when scanning for opening brackets. See the times above.

> BTW while investigating this I noticed a little anomaly in the StrongED
> List Of Functions in C mode. I have some static declarations at the start
> of a source file as follows

[snip example C source]

> This results in an entry in the StrongED List Of Functions of
> = (drwimpc_file_flags) 0;

Which version of the C mode?

If you have the latest version (v1.08) then try Shift-Select click on
the LoF icon. This will use an advanced search expression for finding
function instead of the ListOfC function that Select click uses. In my
tests so far the expression has performed slightly better than ListOfC,
less false positives.

> I also encountered another problem when editing files that have a multiple
> view, characterised by StrongED freezing (or not returning control to the
> wimp) with the hourglass displayed.

[snip details of how to provoke freeze]

I've managed to get the freeze twice but haven't been able to find any
pattern to it. Until a more reliable way is found to trigger the freeze
it's going to be difficult to pin down the cause.

> On another, more specialised, topic - were External Edit file data type
> extensions ever implemented in a standard way? In particular, is there a
> way to tell StrongED to use an alternative mode for an External Edit
> [..]

Yes, as I've already explained when answering Jeremy, you need to alter
the C ModeWhen file to claim external edits from DrWimpC. It doesn't
work in 4.69b5 but it has been fixed.

> Secondly, it can be useful to link the underlying real file name to an
> external edit session of the file.

That doesn't seem possible as external edit doesn't pass the full path
to the editor. OLE would be better for this but then you lose cursor
positioning.

It might be possible to create a new StrongED_xxx message that starts an
external edit session. The message would be the same as Message_EditRq
but the name at offset +52 would be the full path of the file.
Everything else concerning external edit would remain exactly the same.

Of course this would only work with StrongED, not with other editors.

> Thirdly, I don't suppose there's any chance of introducing a mechanism or
> even extend the external edit protocol to allow editors like StrongED to
> export the List of Functions (with any other useful information such as
> line numbers)into another application?

Extending external edit; probably not. Extending StrongED; possibly.

The way to do this now is manually. Create the LoF then click Menu over
it. Make sure 'Line numbers' is ticked then save the LoF. You'll need to
delete the first line of the saved LoF. If you only want the function
names without the parameters then select 'Match only' in the menu before
saving.

Cheers,
Fred.

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

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