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

[pdmiller@xxxxxxxxxxxxxxxxxx]

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

Although the topic was originally for StrongED 4.69b5 I've upgraded to
3.69b6 and tested on that version so the comments apply equally to
StrongED 4.69b6.
>
> 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.
>
I've put the same setup I have on the Raspberry Pi and VirtualRPC-AdjustSA
onto my Iyonix and I still get the same result that the freeze occurs
despite all attempts to type in both brackets as fast as possible. Don't
know if itr relevant - I have the keyboard delay set to 10 and repeat to
4.

[snip previous details]

>
> 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.
>
My 49000 file has 3809 {} pairs and 18653 () pairs. I get a consistent
delay of around 7 seconds for the {} cases above and the () case i tried
resulted in a 40 second delay.
>
[snip previous details]

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

v1.08 with <Shift-Select> handles that false positive successfully on my
system too.
>
>> 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.

I did an edit session on my VRPC system to get the freeze then tried it on
 my Iyonix and it also froze. So I decided to do some tests to show that
it is only the opening and closing of multiple views that leads to the
freeze. Starting with no edits I opened several files in StrongED and
opened and closed multiple views on them. With three files, one with two
views and the others with three views, I decided to open the WindowList
which oddly had its extent set to its minimum as for an empty window list,
instead of showing the eight entries for each file/view. So something had
already gone awry. I closed the WindowList then opened and closed more
views on the files - e.g. open five views for one file, open three for
another of the files, then close the five I just opened for the previous
file. Then I reopened the WindowList - at that point the freeze occurred.
I did similar tests on both VRPC and my Iyonix and got the freeze to
occur. The freeze doesn't consistently occur at the same point, but it
does occur having only opened and closed multiple views on files. I kept
the WindowList closed while I opened new views and occasionally opened it
- that causes its extent to be wrong. Leaving the WindowList open while
opening each view didn't cause an incorrect extent. Another factor may be
the size of the files involved. I had better results in getting the freeze
with larger files. I also tried these tests on a clean v4.69b6 install and
still got the freeze.

I think I've got as close as I can to finding a minimal circumstance when
the freeze occurs. I'm not sure if its something in the setup on my
machines that triggers the freeze so frequently, considering no one else
seems to have reported this, but its still annoying that a restart is
required to unfreeze the systems. I have to reestablish all the LoF and
throwback windows I was working with, etc. The frequency of the freeze on
my systems is making multiple views almost unusable at times and so
StrongED alot less usable for me so a fix sometime would be useful.
>
>> 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.

That works now, thanks for the fix.

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

Yes, its not just cursor positioning but also the ability to insert new
data at the cursor position that OLE doesn't do. For that reason I chose
to use external edit in DrWimpC.
>
> 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.
>
Yes. Other editors would need updating to implement the facility.

I was going to ask about the possibility of using one of the bits in the
Message_EditRq flag word to indicate that the leaf name is a Risc Os path
name, but I'm not sure if using the real name is generally required by, or
applicable to, the external edit protocol which seems to encourage the use
of temporary files (or just ram transfer methods) to communicate the edit
data between editor and client.

The use I have in mind for using the real file name is to make the
external edit interface with DrWimpC much neater by integrating DrWimpC's
external edits of C source code with normal edits of the C source file so
that, for example, when the file is compiled any subsequent edits started
from the compiler throwback data can be used by DrWimpC if a user starts
an external edit on the same file from DrWimpC.

Can I suggest an alternative but slightly more complex approach that
doesn't require a new message or a flag and deals with the DrWimpC case I
described -

Make use of symlink files with the external edit mode to specify the real
name of the file to be edited.

The symlink file could already exist or be generated by the client
application for the duration of the external edit, and point to an
existing file. For an external edit request on a symlink file using
Message_EditRq with the name of the symlink file in the leaf name, file
type set to &1c8, the editor could setup an external edit for the file
pointed to by the symlink using the full file name and if it is already
being edited, linking the external edit to the existing normal edit
(that's the key part for the DrWimpC case). For saving the external edit
when the external edit is linked to a real file edit the rules for
external edit change of file name should be applied.

I would leave the handling of new files to the client application to
arrange for a default version to be created that the symlink can point to,
or use the Parent and leaf name as now and switch to symlink when the file
is saved for the first time.

[snip previous details]
>
> Extending external edit; probably not. Extending StrongED; possibly.
>
Ok. I was just asking really. It would simplify the work DrWimpC has to do
at present to get the LoF data. The external edit protocol seemed the
logical place to put the functionality.

[snip last part of message]

Regards,

Pete Miller.




















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