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

[pdmiller@xxxxxxxxxxxxxxxxxx]

> 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. And,
trying to move through the file using the cursor keys gets stuck on the
line with the mismatched opening curly bracket and I have to wait for the
bracket matching to finish.

> 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 ()'.
>
Yes the curly bracket shortcut is effective. I've tended to steer clear of
shortcuts in the past because of situations that clashed with shortcut
definitions. E.g. I had some functions ending in _w and_s which resulted
in the while and switch statement shortcut texts appearing when I typed
_w( or _s(. Now I've also put a shortcut for ( in the C mode file to
produce () so I get _w() and _s(). Its only the opening { for function
definitions, or the closing top level } that won't be matched with a
corresponding opposite bracket if there is a mismatch so I decided to use
the sequence [{ for the shortcut to use for the opening and closing
function body brackets - defined as

Shortcuts
    [{   \n\n{\n\n\@\n\n\n\n\n\n\n}\n\n
End

I more often get the delay not when inserting new functions or function
calls, etc, but when editing existing function calls or condition
statements where I add new elements to a call or new condition clauses, or
I accidentally delete a closing round bracket with the caret immediately
to the right of the corresponding opening round bracket, that most often
causes the lengthy delay due to the bracket mismatch. (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).

[snip surmise on use of bracket matching code]

>> > 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.
>
True, but you've tested files up to about 5000 lines showing that it would
need a very long function to encounter a delay in practice, at least for
the C mode.

>> 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, so I've
decided that for them I'll use a different approach to bracket match
checking. I'll leave Edit_MatchBrackets Off and pass them through my DDE
tool after editing (or edit and save them through DrWimpC Application
Builder) - both will scan the file for bracket and single/double quote
mismatches and optionally produce a C header file of function prototypes
of the function definitions found in the file.

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

static drwimpc_file_flags sortedsfilelist = (drwimpc_file_flags) 0;

and later

static drwimpc_scandir_accept_fn  scdiraccfn[drwimpc_num_sc_acc_fn] = {

NULL,
drwimpc_is_user_formsrce,
drwimpc_is_user_formhdr,
drwimpc_is_user_srce,
drwimpc_is_user_hdr,
drwimpc_tmplte_file

};

This results in an entry in the StrongED List Of Functions of

= (drwimpc_file_flags) 0;

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. The only remedy is to do a system
restart (I am testing using my VirtualRPC AdjustSA RO 6.20 system so I
have to close it using the windows close window button and restart it).
While this doesn't occur every time, it is repeatable to the extent that
it frequently occurs, sometimes just after beginning an edit session. The
sequence is: start editing a file with a StrongED multiple view - from 2
or more windows, use Display->New View to create a another view for the
file then continue edit actions, e.g. using LoF or creating a new edit
window and eventually the hourglass appears and the wimp is frozen. On
system restart StrongED will have saved any texts being edited at the time
of the problem's occurrence, but leaving them marked as modified in the
Windows List.

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
instead of the standard External Edit mode (e.g. Use C mode for a C source
code text file). The documentation I've seen (External Edit Protocol 1.02)
mentions data type extensions but no list or source of extension types. I
guess that means they were never implemented.

Secondly, it can be useful to link the underlying real file name to an
external edit session of the file. I'm thinking of the case of a C file
edited via external edit, subsequently compiled, producing throwback
messages for the real file name. There is no way to link the throwback
messages to the external edit, so selecting a throwback message from the
throwback window would lead to another edit window opening for the file
alongside the external edit window for the file with the potential to edit
and save the file from both windows and leading to loss of updates of one
or other of the edits.

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?

I realise that these three features could/would affect more than StrongED
and may not be generally useful and so not worth implementing but I may as
well take the opportunity to ask the question and get any feedback on
current thinking regarding them.


Regards,

Pete Miller.







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