Re: Problem with Script Editor in LC 9.6.2 (rc3)

[HENRY LOWE via use-livecode]

Thanks you Lagi, Tore and others.

Looks like this is specific to Mac OS Big Sur.

I have submitted a bug report:

https://quality.livecode.com/show_bug.cgi?id=23139 


Henry

> On Mar 25, 2021, at 4:11 PM, Lagi Pittas via use-livecode 
>  wrote:
> 
> HI Henry,
> 
> Tried it on windows LC 9.6.2 RC2 and it works fine.
> 
> I still have the problem of very laggy text editor  for a machine with 16G
> of Ram and SSD,
> 
>  there is no scrolling problem on a greater than 5000 line script
> 
> so it looks like it's  big Turd this time ;-)
> 
> Lagi
> 
> On Thu, 25 Mar 2021 at 21:09, HENRY LOWE via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> On further investigation this appears to be a problem with any LC
>> scrolling text field, not just the Script Editor.
>> 
>> Please try the following and let me know what you observe:
>> 
>> 1. Create a new stack (e.g. 1024 x 768)
>> 
>> 2. Add a scrolling text field and resize the field to fill the card.
>> 
>> 3. Paste enough text (multiple pastes of the same text will do) into the
>> field so that the vertical scroll bar is activated.
>> 
>> 4. Place in run mode. Click before the first text character in the field
>> 
>> 5. Drag-Select text downwards (hold mouse button down while dragging down
>> over text) towards the bottom of the field until the field begins to
>> auto-scroll
>> 
>> 6. Let go of the mouse - the field continues to autoscroll until it
>> reaches the end of the text
>> 
>> 7. LC is unresponsive during this automatic scrolling
>> 
>> 8. On the Mac the Activity Monitor app shows LC consuming 100% of CPU
>> 
>> 9. This continues for 1-2 minutes then LC unfreezes.
>> 
>> In a large script I am “locked out” of LC for 10-15 mins as the field
>> autoscrolls down.
>> 
>> This may be Mac Big Sur specific, so hopefully someone can test it on that
>> platform.
>> 
>> Looks like a bug to me.
>> 
>> Henry
>> 
>>> On Mar 25, 2021, at 11:05 AM, Sean Cole (Pi) via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>> 
>>> RichardG,
>>> That was a very long way of not answering the question. Very insightful
>>> regarding the DG though. :)
>>> It also went a long way of assuming the skill levels of the audience.
>> Some
>>> of us are not limited to xTalk level. I understand C++ and why Trevor
>>> likely coded the DG using such.
>>> 
>>> My question, just to reestablish, was what on Earth could possibly
>>> complicate the scrolling of the line-numbers in sync with the main
>> 'field'?
>>> Very occasionally the numbers freeze altogether until a click in the
>> editor
>>> which is an interesting aside and only partly related to the question. I
>>> never notice a lag between the two areas. 32-bit I feel is neither here
>> nor
>>> there in relation to the syncing or imperceivable lag, especially for the
>>> SE.
>>> 
>>> Looking on github reveals that the majority of the code for the SE are
>>> indeed, as suspected, written in livecodescript (xTalk ;)) by BHall
>> mostly,
>>> rather than CPP. And, as suspected, really quite simple and unconvoluted
>> as
>>> they can get. Barely anything to become difficult in fixing for Henry's
>>> listed issue. revsecommoneditorbehavior.livecodescript holds the key,
>> lines
>>> 2658-2721 most likely.
>>> 
>>> Sean
>>> 
>>> 
>>> On Thu, 25 Mar 2021 at 16:47, Richard Gaskin via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
>>> 
 Sean Cole wrote:
 
> On Wed, 24 Mar 2021 at 21:45, Richard Gaskin wrote:
> 
>> I believe it may be related to the complicated way the line
>> number field is kept in sync.
> 
> Quick question. Why would the line number field be complicated? I
> can’t imagine anything that would necessitate making it complicated.
> Numbers and break points. That’s all it handles, right?
 
 
 It's easy to describe anything in terms that make it sound simple, but
 whether a task is *actually* simple depends on many things.
 
 It's equally an oversimplification to arbitrarily divide the world into
 two types of programmers, xTalkers and C coders, but that won't stop me
 from indulging in it here :
 
 
 If we look at text editors made by C coders, they generally only render
 the line numbers visible on screen given the current scroll position.
 But they do everything with lower-level/computer-oriented thinking, with
 lineto and moveto and stringAt (yes, the Inside Macintosh references
 there show my age, but you know what I mean), so for them these types of
 calculations are second-nature and not considered tedious at all, it's
 just how things are done.
 
 xTalkers, by virtue of choosing a language that is not only high-level
 but among the very few that directly incorporate GUI controls as
 inherent language elements, think differently. To us we put text into a
 field and set the scroll as we like and let the engine figure out the

Re: Problem with Script Editor in LC 9.6.2 (rc3)

[Lagi Pittas via use-livecode]

HI Henry,

Tried it on windows LC 9.6.2 RC2 and it works fine.

I still have the problem of very laggy text editor  for a machine with 16G
of Ram and SSD,

  there is no scrolling problem on a greater than 5000 line script

so it looks like it's  big Turd this time ;-)

Lagi

On Thu, 25 Mar 2021 at 21:09, HENRY LOWE via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On further investigation this appears to be a problem with any LC
> scrolling text field, not just the Script Editor.
>
> Please try the following and let me know what you observe:
>
> 1. Create a new stack (e.g. 1024 x 768)
>
> 2. Add a scrolling text field and resize the field to fill the card.
>
> 3. Paste enough text (multiple pastes of the same text will do) into the
> field so that the vertical scroll bar is activated.
>
> 4. Place in run mode. Click before the first text character in the field
>
> 5. Drag-Select text downwards (hold mouse button down while dragging down
> over text) towards the bottom of the field until the field begins to
> auto-scroll
>
> 6. Let go of the mouse - the field continues to autoscroll until it
> reaches the end of the text
>
> 7. LC is unresponsive during this automatic scrolling
>
> 8. On the Mac the Activity Monitor app shows LC consuming 100% of CPU
>
> 9. This continues for 1-2 minutes then LC unfreezes.
>
> In a large script I am “locked out” of LC for 10-15 mins as the field
> autoscrolls down.
>
> This may be Mac Big Sur specific, so hopefully someone can test it on that
> platform.
>
> Looks like a bug to me.
>
> Henry
>
> > On Mar 25, 2021, at 11:05 AM, Sean Cole (Pi) via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > RichardG,
> > That was a very long way of not answering the question. Very insightful
> > regarding the DG though. :)
> > It also went a long way of assuming the skill levels of the audience.
> Some
> > of us are not limited to xTalk level. I understand C++ and why Trevor
> > likely coded the DG using such.
> >
> > My question, just to reestablish, was what on Earth could possibly
> > complicate the scrolling of the line-numbers in sync with the main
> 'field'?
> > Very occasionally the numbers freeze altogether until a click in the
> editor
> > which is an interesting aside and only partly related to the question. I
> > never notice a lag between the two areas. 32-bit I feel is neither here
> nor
> > there in relation to the syncing or imperceivable lag, especially for the
> > SE.
> >
> > Looking on github reveals that the majority of the code for the SE are
> > indeed, as suspected, written in livecodescript (xTalk ;)) by BHall
> mostly,
> > rather than CPP. And, as suspected, really quite simple and unconvoluted
> as
> > they can get. Barely anything to become difficult in fixing for Henry's
> > listed issue. revsecommoneditorbehavior.livecodescript holds the key,
> lines
> > 2658-2721 most likely.
> >
> > Sean
> >
> >
> > On Thu, 25 Mar 2021 at 16:47, Richard Gaskin via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> >> Sean Cole wrote:
> >>
> >>> On Wed, 24 Mar 2021 at 21:45, Richard Gaskin wrote:
> >>>
>  I believe it may be related to the complicated way the line
>  number field is kept in sync.
> >>>
> >>> Quick question. Why would the line number field be complicated? I
> >>> can’t imagine anything that would necessitate making it complicated.
> >>> Numbers and break points. That’s all it handles, right?
> >>
> >>
> >> It's easy to describe anything in terms that make it sound simple, but
> >> whether a task is *actually* simple depends on many things.
> >>
> >> It's equally an oversimplification to arbitrarily divide the world into
> >> two types of programmers, xTalkers and C coders, but that won't stop me
> >> from indulging in it here :
> >>
> >>
> >> If we look at text editors made by C coders, they generally only render
> >> the line numbers visible on screen given the current scroll position.
> >> But they do everything with lower-level/computer-oriented thinking, with
> >> lineto and moveto and stringAt (yes, the Inside Macintosh references
> >> there show my age, but you know what I mean), so for them these types of
> >> calculations are second-nature and not considered tedious at all, it's
> >> just how things are done.
> >>
> >> xTalkers, by virtue of choosing a language that is not only high-level
> >> but among the very few that directly incorporate GUI controls as
> >> inherent language elements, think differently. To us we put text into a
> >> field and set the scroll as we like and let the engine figure out the
> >> details.
> >>
> >>
> >> Which is "best" is a topic that can be hotly debated, and was here on
> >> this list several years ago in a thread on making text editors in LC.
> >>
> >> One of the participants in that thread was Jeff Massung, who'd made a
> >> very nice Erlang editor in LC. In his view, IIRC, it was wasteful to ask
> >> the engine to render thousands of lines of line numbers if the script
> 

Re: Problem with Script Editor in LC 9.6.2 (rc3)

[Tore Nilsen via use-livecode]

I have followed your recipe and I can confirm that this is a problem also with 
ordinary scrolling fields in LC 9.6.2 (rc3). It does not seem to be a problem 
in LC 9.6.2 (rc1).

Best regards
Tore Nilsen

> 25. mar. 2021 kl. 22:07 skrev HENRY LOWE via use-livecode 
> :
> 
> On further investigation this appears to be a problem with any LC scrolling 
> text field, not just the Script Editor.
> 
> Please try the following and let me know what you observe:
> 
> 1. Create a new stack (e.g. 1024 x 768)
> 
> 2. Add a scrolling text field and resize the field to fill the card.
> 
> 3. Paste enough text (multiple pastes of the same text will do) into the 
> field so that the vertical scroll bar is activated.
> 
> 4. Place in run mode. Click before the first text character in the field
> 
> 5. Drag-Select text downwards (hold mouse button down while dragging down 
> over text) towards the bottom of the field until the field begins to 
> auto-scroll
> 
> 6. Let go of the mouse - the field continues to autoscroll until it reaches 
> the end of the text
> 
> 7. LC is unresponsive during this automatic scrolling
> 
> 8. On the Mac the Activity Monitor app shows LC consuming 100% of CPU
> 
> 9. This continues for 1-2 minutes then LC unfreezes.
> 
> In a large script I am “locked out” of LC for 10-15 mins as the field 
> autoscrolls down.
> 
> This may be Mac Big Sur specific, so hopefully someone can test it on that 
> platform.
> 
> Looks like a bug to me.
> 
> Henry
> 
>> On Mar 25, 2021, at 11:05 AM, Sean Cole (Pi) via use-livecode 
>>  wrote:
>> 
>> RichardG,
>> That was a very long way of not answering the question. Very insightful
>> regarding the DG though. :)
>> It also went a long way of assuming the skill levels of the audience. Some
>> of us are not limited to xTalk level. I understand C++ and why Trevor
>> likely coded the DG using such.
>> 
>> My question, just to reestablish, was what on Earth could possibly
>> complicate the scrolling of the line-numbers in sync with the main 'field'?
>> Very occasionally the numbers freeze altogether until a click in the editor
>> which is an interesting aside and only partly related to the question. I
>> never notice a lag between the two areas. 32-bit I feel is neither here nor
>> there in relation to the syncing or imperceivable lag, especially for the
>> SE.
>> 
>> Looking on github reveals that the majority of the code for the SE are
>> indeed, as suspected, written in livecodescript (xTalk ;)) by BHall mostly,
>> rather than CPP. And, as suspected, really quite simple and unconvoluted as
>> they can get. Barely anything to become difficult in fixing for Henry's
>> listed issue. revsecommoneditorbehavior.livecodescript holds the key, lines
>> 2658-2721 most likely.
>> 
>> Sean
>> 
>> 
>> On Thu, 25 Mar 2021 at 16:47, Richard Gaskin via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
>>> Sean Cole wrote:
>>> 
 On Wed, 24 Mar 2021 at 21:45, Richard Gaskin wrote:
 
> I believe it may be related to the complicated way the line
> number field is kept in sync.
 
 Quick question. Why would the line number field be complicated? I
 can’t imagine anything that would necessitate making it complicated.
 Numbers and break points. That’s all it handles, right?
>>> 
>>> 
>>> It's easy to describe anything in terms that make it sound simple, but
>>> whether a task is *actually* simple depends on many things.
>>> 
>>> It's equally an oversimplification to arbitrarily divide the world into
>>> two types of programmers, xTalkers and C coders, but that won't stop me
>>> from indulging in it here :
>>> 
>>> 
>>> If we look at text editors made by C coders, they generally only render
>>> the line numbers visible on screen given the current scroll position.
>>> But they do everything with lower-level/computer-oriented thinking, with
>>> lineto and moveto and stringAt (yes, the Inside Macintosh references
>>> there show my age, but you know what I mean), so for them these types of
>>> calculations are second-nature and not considered tedious at all, it's
>>> just how things are done.
>>> 
>>> xTalkers, by virtue of choosing a language that is not only high-level
>>> but among the very few that directly incorporate GUI controls as
>>> inherent language elements, think differently. To us we put text into a
>>> field and set the scroll as we like and let the engine figure out the
>>> details.
>>> 
>>> 
>>> Which is "best" is a topic that can be hotly debated, and was here on
>>> this list several years ago in a thread on making text editors in LC.
>>> 
>>> One of the participants in that thread was Jeff Massung, who'd made a
>>> very nice Erlang editor in LC. In his view, IIRC, it was wasteful to ask
>>> the engine to render thousands of lines of line numbers if the script
>>> being displayed was much shorter.  He felt that the "right" approach
>>> would be to do as C programmers do, to dynamically calculate which line
>>> numbers should be visible 

Re: Problem with Script Editor in LC 9.6.2 (rc3)

[HENRY LOWE via use-livecode]

On further investigation this appears to be a problem with any LC scrolling 
text field, not just the Script Editor.

Please try the following and let me know what you observe:

1. Create a new stack (e.g. 1024 x 768)

2. Add a scrolling text field and resize the field to fill the card.

3. Paste enough text (multiple pastes of the same text will do) into the field 
so that the vertical scroll bar is activated.

4. Place in run mode. Click before the first text character in the field

5. Drag-Select text downwards (hold mouse button down while dragging down over 
text) towards the bottom of the field until the field begins to auto-scroll

6. Let go of the mouse - the field continues to autoscroll until it reaches the 
end of the text

7. LC is unresponsive during this automatic scrolling

8. On the Mac the Activity Monitor app shows LC consuming 100% of CPU

9. This continues for 1-2 minutes then LC unfreezes.

In a large script I am “locked out” of LC for 10-15 mins as the field 
autoscrolls down.

This may be Mac Big Sur specific, so hopefully someone can test it on that 
platform.

Looks like a bug to me.

Henry

> On Mar 25, 2021, at 11:05 AM, Sean Cole (Pi) via use-livecode 
>  wrote:
> 
> RichardG,
> That was a very long way of not answering the question. Very insightful
> regarding the DG though. :)
> It also went a long way of assuming the skill levels of the audience. Some
> of us are not limited to xTalk level. I understand C++ and why Trevor
> likely coded the DG using such.
> 
> My question, just to reestablish, was what on Earth could possibly
> complicate the scrolling of the line-numbers in sync with the main 'field'?
> Very occasionally the numbers freeze altogether until a click in the editor
> which is an interesting aside and only partly related to the question. I
> never notice a lag between the two areas. 32-bit I feel is neither here nor
> there in relation to the syncing or imperceivable lag, especially for the
> SE.
> 
> Looking on github reveals that the majority of the code for the SE are
> indeed, as suspected, written in livecodescript (xTalk ;)) by BHall mostly,
> rather than CPP. And, as suspected, really quite simple and unconvoluted as
> they can get. Barely anything to become difficult in fixing for Henry's
> listed issue. revsecommoneditorbehavior.livecodescript holds the key, lines
> 2658-2721 most likely.
> 
> Sean
> 
> 
> On Thu, 25 Mar 2021 at 16:47, Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> Sean Cole wrote:
>> 
>>> On Wed, 24 Mar 2021 at 21:45, Richard Gaskin wrote:
>>> 
 I believe it may be related to the complicated way the line
 number field is kept in sync.
>>> 
>>> Quick question. Why would the line number field be complicated? I
>>> can’t imagine anything that would necessitate making it complicated.
>>> Numbers and break points. That’s all it handles, right?
>> 
>> 
>> It's easy to describe anything in terms that make it sound simple, but
>> whether a task is *actually* simple depends on many things.
>> 
>> It's equally an oversimplification to arbitrarily divide the world into
>> two types of programmers, xTalkers and C coders, but that won't stop me
>> from indulging in it here :
>> 
>> 
>> If we look at text editors made by C coders, they generally only render
>> the line numbers visible on screen given the current scroll position.
>> But they do everything with lower-level/computer-oriented thinking, with
>> lineto and moveto and stringAt (yes, the Inside Macintosh references
>> there show my age, but you know what I mean), so for them these types of
>> calculations are second-nature and not considered tedious at all, it's
>> just how things are done.
>> 
>> xTalkers, by virtue of choosing a language that is not only high-level
>> but among the very few that directly incorporate GUI controls as
>> inherent language elements, think differently. To us we put text into a
>> field and set the scroll as we like and let the engine figure out the
>> details.
>> 
>> 
>> Which is "best" is a topic that can be hotly debated, and was here on
>> this list several years ago in a thread on making text editors in LC.
>> 
>> One of the participants in that thread was Jeff Massung, who'd made a
>> very nice Erlang editor in LC. In his view, IIRC, it was wasteful to ask
>> the engine to render thousands of lines of line numbers if the script
>> being displayed was much shorter.  He felt that the "right" approach
>> would be to do as C programmers do, to dynamically calculate which line
>> numbers should be visible and dynamically populate the line number list
>> with only those on each scrollBarDrag.
>> 
>> Others, including myself, felt that using xTalk objects as xTalkers are
>> accustomed to using them was not a mistake at all, but actually quite
>> with-the-grain for xTalk work. Even if we're asking the engine to work
>> harder, we're doing it only once up front, relying on the engine's good
>> buffering to make scrolling 

Re: Problem with Script Editor in LC 9.6.2 (rc3)

[Richard Gaskin via use-livecode]

Sean Cole wrote:

> RichardG,

Feel free to use simply "Richard" if you like.


> That was a very long way of not answering the question. Very
> insightful regarding the DG though. :)
> It also went a long way of assuming the skill levels of the audience.
> Some of us are not limited to xTalk level.

Where I wrote that it's "an oversimplification to arbitrarily divide the 
world into two types of programmers, xTalkers and C coders", what I 
meant to say is that it's an oversimplification to arbitrarily divide 
the world into two types of programmers, xTalkers and C coders.


Sorry I was unable to make that clearer.


> I understand C++ and why Trevor likely coded the DG using such.

My writing was even worse than I'd thought. Having once hired Trevor to 
write some C++ for a project many years ago, I'm well aware of the 
breadth of his skillset.


What I had attempted to illustrate there had nothing to do with coding 
styles, but with a merely pragmatic tradeoff necessary for certain uses 
of LC group objects.




> My question, just to reestablish, was what on Earth could possibly
> complicate the scrolling of the line-numbers in sync with the main
> 'field'?

Gave it my best shot.

TL/DL:

1. I don't specifically know what the LC SE is doing there.

2. I don't generally believe it makes sense to describe anything as 
simple until we take the time, however much patience that requires, to 
understand the goals of the design.




> Very occasionally the numbers freeze altogether until a click in
> the editor which is an interesting aside and only partly related
> to the question. I never notice a lag between the two areas.

That lag you just described awaiting the click?  That. That's one of the 
observable lags I'm referring to.




> 32-bit I feel is neither here nor there in relation to the syncing
> or imperceivable lag, especially for the SE.

Agreed, which is why I wrote "the 32-bit coordinate space only applies 
to controls, not the contents within text fields".


Coordinate space was only relevant in exploring why the DG uses dynamic 
scroll updates, contrasting the DGs architectural decisions with those 
used to populate line number fields, where such a choice is not 
necessary but may reflect styles of habit.



> Looking on github reveals that the majority of the code for the SE are
> indeed, as suspected, written in livecodescript (xTalk ;)) by BHall
> mostly, rather than CPP. And, as suspected, really quite simple and
> unconvoluted as they can get. Barely anything to become difficult in
> fixing for Henry's listed issue.
> revsecommoneditorbehavior.livecodescript holds the key, lines
> 2658-2721 most likely.

Looks like you've found your answer.

--
Richard Gaskin
Fourth World Systems


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Problem with Script Editor in LC 9.6.2 (rc3)

[Sean Cole (Pi) via use-livecode]

RichardG,
That was a very long way of not answering the question. Very insightful
regarding the DG though. :)
It also went a long way of assuming the skill levels of the audience. Some
of us are not limited to xTalk level. I understand C++ and why Trevor
likely coded the DG using such.

My question, just to reestablish, was what on Earth could possibly
complicate the scrolling of the line-numbers in sync with the main 'field'?
Very occasionally the numbers freeze altogether until a click in the editor
which is an interesting aside and only partly related to the question. I
never notice a lag between the two areas. 32-bit I feel is neither here nor
there in relation to the syncing or imperceivable lag, especially for the
SE.

Looking on github reveals that the majority of the code for the SE are
indeed, as suspected, written in livecodescript (xTalk ;)) by BHall mostly,
rather than CPP. And, as suspected, really quite simple and unconvoluted as
they can get. Barely anything to become difficult in fixing for Henry's
listed issue. revsecommoneditorbehavior.livecodescript holds the key, lines
2658-2721 most likely.

Sean


On Thu, 25 Mar 2021 at 16:47, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Sean Cole wrote:
>
>  > On Wed, 24 Mar 2021 at 21:45, Richard Gaskin wrote:
>  >
>  >>  I believe it may be related to the complicated way the line
>  >> number field is kept in sync.
>  >
>  > Quick question. Why would the line number field be complicated? I
>  > can’t imagine anything that would necessitate making it complicated.
>  > Numbers and break points. That’s all it handles, right?
>
>
> It's easy to describe anything in terms that make it sound simple, but
> whether a task is *actually* simple depends on many things.
>
> It's equally an oversimplification to arbitrarily divide the world into
> two types of programmers, xTalkers and C coders, but that won't stop me
> from indulging in it here :
>
>
> If we look at text editors made by C coders, they generally only render
> the line numbers visible on screen given the current scroll position.
> But they do everything with lower-level/computer-oriented thinking, with
> lineto and moveto and stringAt (yes, the Inside Macintosh references
> there show my age, but you know what I mean), so for them these types of
> calculations are second-nature and not considered tedious at all, it's
> just how things are done.
>
> xTalkers, by virtue of choosing a language that is not only high-level
> but among the very few that directly incorporate GUI controls as
> inherent language elements, think differently. To us we put text into a
> field and set the scroll as we like and let the engine figure out the
> details.
>
>
> Which is "best" is a topic that can be hotly debated, and was here on
> this list several years ago in a thread on making text editors in LC.
>
> One of the participants in that thread was Jeff Massung, who'd made a
> very nice Erlang editor in LC. In his view, IIRC, it was wasteful to ask
> the engine to render thousands of lines of line numbers if the script
> being displayed was much shorter.  He felt that the "right" approach
> would be to do as C programmers do, to dynamically calculate which line
> numbers should be visible and dynamically populate the line number list
> with only those on each scrollBarDrag.
>
> Others, including myself, felt that using xTalk objects as xTalkers are
> accustomed to using them was not a mistake at all, but actually quite
> with-the-grain for xTalk work. Even if we're asking the engine to work
> harder, we're doing it only once up front, relying on the engine's good
> buffering to make scrolling throughout the rest of the session simpler.
>
>
> It's worth noting that the excellent DataGrid relies on
> dynamically-calculated scrolling, but even more worthy to note WHY:
>
> It's not because scrolling the DG is made any faster (observably it isn't).
>
> It's because the performance impact of dynamically-calculated scrolling
> is a NECESSARY tradeoff to cover the sometimes-large number of records
> it's asked to display.  LC uses 32-bit coordinate addressing, which is
> more than adequate for most things we render since it gives us about 30
> feet of drawing space, far bigger than any monitor. But if you try to
> place tens of thousands of groups nested within a scrolling group,
> you'll quickly discover what happens when you exceed 32-bit coordinate
> space. :)
>
> So Trevor did the tedious work of providing a profoundly flexible
> DataGrid, where for the relatively low cost of a modest performance hit
> during scrolls we can effortlessly display even vast numbers of records,
> by only actually rendering those on screen at any given time.
>
> But the 32-bit coordinate space only applies to controls, not the
> contents within text fields, so
>
>
> Back to the LC Script Editor, truth be told it's been so long since I
> donned my pith helmet to dive into its code jungle that I'm not in a
> 

Re: Problem with Script Editor in LC 9.6.2 (rc3)

[Richard Gaskin via use-livecode]

Sean Cole wrote:

> On Wed, 24 Mar 2021 at 21:45, Richard Gaskin wrote:
>
>>  I believe it may be related to the complicated way the line
>> number field is kept in sync.
>
> Quick question. Why would the line number field be complicated? I
> can’t imagine anything that would necessitate making it complicated.
> Numbers and break points. That’s all it handles, right?


It's easy to describe anything in terms that make it sound simple, but 
whether a task is *actually* simple depends on many things.


It's equally an oversimplification to arbitrarily divide the world into 
two types of programmers, xTalkers and C coders, but that won't stop me 
from indulging in it here :



If we look at text editors made by C coders, they generally only render 
the line numbers visible on screen given the current scroll position. 
But they do everything with lower-level/computer-oriented thinking, with 
lineto and moveto and stringAt (yes, the Inside Macintosh references 
there show my age, but you know what I mean), so for them these types of 
calculations are second-nature and not considered tedious at all, it's 
just how things are done.


xTalkers, by virtue of choosing a language that is not only high-level 
but among the very few that directly incorporate GUI controls as 
inherent language elements, think differently. To us we put text into a 
field and set the scroll as we like and let the engine figure out the 
details.



Which is "best" is a topic that can be hotly debated, and was here on 
this list several years ago in a thread on making text editors in LC.


One of the participants in that thread was Jeff Massung, who'd made a 
very nice Erlang editor in LC. In his view, IIRC, it was wasteful to ask 
the engine to render thousands of lines of line numbers if the script 
being displayed was much shorter.  He felt that the "right" approach 
would be to do as C programmers do, to dynamically calculate which line 
numbers should be visible and dynamically populate the line number list 
with only those on each scrollBarDrag.


Others, including myself, felt that using xTalk objects as xTalkers are 
accustomed to using them was not a mistake at all, but actually quite 
with-the-grain for xTalk work. Even if we're asking the engine to work 
harder, we're doing it only once up front, relying on the engine's good 
buffering to make scrolling throughout the rest of the session simpler.



It's worth noting that the excellent DataGrid relies on 
dynamically-calculated scrolling, but even more worthy to note WHY:


It's not because scrolling the DG is made any faster (observably it isn't).

It's because the performance impact of dynamically-calculated scrolling 
is a NECESSARY tradeoff to cover the sometimes-large number of records 
it's asked to display.  LC uses 32-bit coordinate addressing, which is 
more than adequate for most things we render since it gives us about 30 
feet of drawing space, far bigger than any monitor. But if you try to 
place tens of thousands of groups nested within a scrolling group, 
you'll quickly discover what happens when you exceed 32-bit coordinate 
space. :)


So Trevor did the tedious work of providing a profoundly flexible 
DataGrid, where for the relatively low cost of a modest performance hit 
during scrolls we can effortlessly display even vast numbers of records, 
by only actually rendering those on screen at any given time.


But the 32-bit coordinate space only applies to controls, not the 
contents within text fields, so



Back to the LC Script Editor, truth be told it's been so long since I 
donned my pith helmet to dive into its code jungle that I'm not in a 
position to speak authoritatively on how it's constructed.


But we can observe (sadly, without much effort) a lag between scrolling 
the script field and the subsequent update of the line number list.  In 
some cases, depending on platform and script length, this lag is more 
easily seen than on others.


This suggests that there's a lot more going on with the SE's line number 
update than just setting its scroll to match the editor field's.


Indeed, given the variance of the lag it would seem it's not updated 
directly at all, but perhaps via "send".



It wouldn't be appropriate to say the LC implementation is necessarily 
"wrong" or even "bad".  It's a deeply complicated layout with a lot of 
updates to manage, and given the vast scope of its design ambitions it's 
hard to say what one "should" do there.


But it is safe to observe that it was written by people who cut their 
teeth on languages more lower-level than xTalk. Aside from Monte and 
Kevin, I don't know of anyone there who shipped a product using an xTalk 
before being hired to make an xTalk.


Obviously, that's exactly what we want in an engine team, C++ engineers 
who live and breathe deep computer science.


But from time to time it does lend itself toward designs and 
implementations that look like the work of native C coders rather than 
native 

Re: Problem with Script Editor in LC 9.6.2 (rc3)

[Sean Cole (Pi) via use-livecode]

I have definitely experienced this in Windows, not Mac. But I had assumed
it was an anomaly from running it in Parallels. I’ve had it for a number of
versions back now. It only happens occasionally and, as you say, only for
large scripts where it has the most impact. I tend to walk away, make a
coffee, come back and it will have stopped and I can scroll using a
different method. The scroll wheel works ok. It’s mostly noticeable when
clicking the scroll area (not the bar itself) to page jump or using the
line up/down buttons.

I hope this helps in your reporting.

Sean

On Wed, 24 Mar 2021 at 22:34, HENRY LOWE via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Thanks Matthias. I am not using any 3rd party text tools or plug-ins.
>
> If anyone else can confirm this issue I will submit a bug report.
>
> Henry

-- 
Pi Digital
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Problem with Script Editor in LC 9.6.2 (rc3)

[Sean Cole (Pi) via use-livecode]

Quick question. Why would the line number field be complicated? I can’t
imagine anything that would necessitate making it complicated. Numbers and
break points. That’s all it handles, right?

On Wed, 24 Mar 2021 at 21:45, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

>  I believe it may be related to
> the complicated way the line number field is kept in sync.
>
-- 
Pi Digital
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Problem with Script Editor in LC 9.6.2 (rc3)

[Bob Sneidar via use-livecode]

Are you sure you do not have a mouseUp handler somewhere in a frontScript? 

Bob S


> On Mar 24, 2021, at 2:58 PM, HENRY LOWE via use-livecode 
>  wrote:
> 
> Thanks Richard. I turned off the line number option and the problem still 
> occurs. I can reproduce this with any script that extend beyond the bottom of 
> the script editor pane. 
> 
> Select the first line of a script and then (holding the mouse button down) 
> continue dragging down to select additional lines until you are reach the 
> last visible line. Continue to drag down to get the script editor to 
> autoscroll and the scrolling now continues automatically until the entire 
> script is selected. Cannot stop the scroll until the entire script is 
> selected.
> 
> Looks like a new bug to me.
> 
> Henry
> 
>> On Mar 24, 2021, at 2:45 PM, Richard Gaskin via use-livecode 
>>  wrote:
>> 
>> Henry Lowe wrote:
>> 
>>> If I select text in the LC Script Editor and then drag down to select
>>> additional text (e.g. I want to select an entire handler), the editor
>>> starts to autoscroll and does not stop until it reaches the end of the
>>> script text. Nothing I do stops the scrolling and text selection. I am
>>> locked out of LC, which is unresponsive. Activity Monitor shows that
>>> LC is using 100% of the CPU while in this ‘autoscrolling’ state. Once
>>> the scroll reaches the end of the text in the editor pane, I get
>>> control of LC again.
>>> 
>>> This is only happening with a very large script 5900 lines of text
>>> (238K). I am in the progress of breaking this script up into a series
>>> of smaller scripts.
>>> 
>>> I suspect that this issue is related to the large amount of text in
>>> the script but have not seen this before with this script until I
>>> updated to LC 9.6.2 (rc3).
>>> 
>>> Can anyone confirm this issue?
>> 
>> I have seen similar issues on Ubuntu.  I believe it may be related to the 
>> complicated way the line number field is kept in sync.
>> 
>> The only workaround I've tested is writing my own script editor, thankfully 
>> subsidized by a generous soul who commissioned it.  It's not yet ready for 
>> prime time, though, so I have no immediate solution for LC SE users.
>> 
>> 
>>> Also, is there an upper limit to the size of a LC script?
>> 
>> There should not be, at least within reasonable memory limits.
>> 
>> And if there were, it shouldn't be anywhere near as short as 5900 lines. 
>> I've been stress-testing my with 20k-line scripts.
>> 
>> The LC field object is quite good.  Any script editor using it should be 
>> quite good too.
>> 
>> -- 
>> Richard Gaskin
>> Fourth World Systems
>> Software Design and Development for the Desktop, Mobile, and the Web
>> 
>> ambassa...@fourthworld.comhttp://www.FourthWorld.com
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Problem with Script Editor in LC 9.6.2 (rc3)

[Bob Sneidar via use-livecode]

Same LC version but not Big Sur. I was able to scroll properly while selecting 
text. 

Bob S


> On Mar 24, 2021, at 2:05 PM, HENRY LOWE via use-livecode 
>  wrote:
> 
> Since updating to LC 9.6.2 (rc3) on a 2019 iMac running Mac OS Big Sur 11.2.3 
> I have been experiencing the following intermittent issue:
> 
> If I select text in the LC Script Editor and then drag down to select 
> additional text (e.g. I want to select an entire handler), the editor starts 
> to autoscroll and does not stop until it reaches the end of the script text. 
> Nothing I do stops the scrolling and text selection. I am locked out of LC, 
> which is unresponsive. Activity Monitor shows that LC is using 100% of the 
> CPU while in this ‘autoscrolling’ state. Once the scroll reaches the end of 
> the text in the editor pane, I get control of LC again. 
> 
> This is only happening with a very large script 5900 lines of text (238K). I 
> am in the progress of breaking this script up into a series of smaller 
> scripts.
> 
> I suspect that this issue is related to the large amount of text in the 
> script but have not seen this before with this script until I updated to LC 
> 9.6.2 (rc3).
> 
> Can anyone confirm this issue?
> 
> Also, is there an upper limit to the size of a LC script?
> 
> Thanks,
> 
> Henry
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Problem with Script Editor in LC 9.6.2 (rc3)

[HENRY LOWE via use-livecode]

Thanks Matthias. I am not using any 3rd party text tools or plug-ins.

If anyone else can confirm this issue I will submit a bug report.

Henry

> On Mar 24, 2021, at 3:17 PM, matthias rebbe via use-livecode 
>  wrote:
> 
> Henry,
> 
> i had a similar problem already with previous LC releases. In my case a 3rd 
> party tool called Popclip was the culprit.
> Popclip is automatically activated as soon as some text is selected. So when 
> i selected text in the editor some strange things happened, for example the 
> whole text was selected and so on.
> Fortunately Popclip allows to exclude apps from being monitored by it, so i 
> just had to add Livecode to the list of apps that should be excluded from 
> PopClip actions.
> 
> 
> Regards,
> 
> 
> -
> Matthias Rebbe
> Life Is Too Short For Boring Code
> 
>> Am 24.03.2021 um 22:58 schrieb HENRY LOWE via use-livecode 
>> :
>> 
>> Thanks Richard. I turned off the line number option and the problem still 
>> occurs. I can reproduce this with any script that extend beyond the bottom 
>> of the script editor pane. 
>> 
>> Select the first line of a script and then (holding the mouse button down) 
>> continue dragging down to select additional lines until you are reach the 
>> last visible line. Continue to drag down to get the script editor to 
>> autoscroll and the scrolling now continues automatically until the entire 
>> script is selected. Cannot stop the scroll until the entire script is 
>> selected.
>> 
>> Looks like a new bug to me.
>> 
>> Henry
>> 
>>> On Mar 24, 2021, at 2:45 PM, Richard Gaskin via use-livecode 
>>>  wrote:
>>> 
>>> Henry Lowe wrote:
>>> 
 If I select text in the LC Script Editor and then drag down to select
 additional text (e.g. I want to select an entire handler), the editor
 starts to autoscroll and does not stop until it reaches the end of the
 script text. Nothing I do stops the scrolling and text selection. I am
 locked out of LC, which is unresponsive. Activity Monitor shows that
 LC is using 100% of the CPU while in this ‘autoscrolling’ state. Once
 the scroll reaches the end of the text in the editor pane, I get
 control of LC again.
 
 This is only happening with a very large script 5900 lines of text
 (238K). I am in the progress of breaking this script up into a series
 of smaller scripts.
 
 I suspect that this issue is related to the large amount of text in
 the script but have not seen this before with this script until I
 updated to LC 9.6.2 (rc3).
 
 Can anyone confirm this issue?
>>> 
>>> I have seen similar issues on Ubuntu.  I believe it may be related to the 
>>> complicated way the line number field is kept in sync.
>>> 
>>> The only workaround I've tested is writing my own script editor, thankfully 
>>> subsidized by a generous soul who commissioned it.  It's not yet ready for 
>>> prime time, though, so I have no immediate solution for LC SE users.
>>> 
>>> 
 Also, is there an upper limit to the size of a LC script?
>>> 
>>> There should not be, at least within reasonable memory limits.
>>> 
>>> And if there were, it shouldn't be anywhere near as short as 5900 lines. 
>>> I've been stress-testing my with 20k-line scripts.
>>> 
>>> The LC field object is quite good.  Any script editor using it should be 
>>> quite good too.
>>> 
>>> -- 
>>> Richard Gaskin
>>> Fourth World Systems
>>> Software Design and Development for the Desktop, Mobile, and the Web
>>> 
>>> ambassa...@fourthworld.comhttp://www.FourthWorld.com
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Problem with Script Editor in LC 9.6.2 (rc3)

[matthias rebbe via use-livecode]

Henry,

i had a similar problem already with previous LC releases. In my case a 3rd 
party tool called Popclip was the culprit.
Popclip is automatically activated as soon as some text is selected. So when i 
selected text in the editor some strange things happened, for example the whole 
text was selected and so on.
Fortunately Popclip allows to exclude apps from being monitored by it, so i 
just had to add Livecode to the list of apps that should be excluded from 
PopClip actions.


Regards,


-
Matthias Rebbe
Life Is Too Short For Boring Code

> Am 24.03.2021 um 22:58 schrieb HENRY LOWE via use-livecode 
> :
> 
> Thanks Richard. I turned off the line number option and the problem still 
> occurs. I can reproduce this with any script that extend beyond the bottom of 
> the script editor pane. 
> 
> Select the first line of a script and then (holding the mouse button down) 
> continue dragging down to select additional lines until you are reach the 
> last visible line. Continue to drag down to get the script editor to 
> autoscroll and the scrolling now continues automatically until the entire 
> script is selected. Cannot stop the scroll until the entire script is 
> selected.
> 
> Looks like a new bug to me.
> 
> Henry
> 
>> On Mar 24, 2021, at 2:45 PM, Richard Gaskin via use-livecode 
>>  wrote:
>> 
>> Henry Lowe wrote:
>> 
>>> If I select text in the LC Script Editor and then drag down to select
>>> additional text (e.g. I want to select an entire handler), the editor
>>> starts to autoscroll and does not stop until it reaches the end of the
>>> script text. Nothing I do stops the scrolling and text selection. I am
>>> locked out of LC, which is unresponsive. Activity Monitor shows that
>>> LC is using 100% of the CPU while in this ‘autoscrolling’ state. Once
>>> the scroll reaches the end of the text in the editor pane, I get
>>> control of LC again.
>>> 
>>> This is only happening with a very large script 5900 lines of text
>>> (238K). I am in the progress of breaking this script up into a series
>>> of smaller scripts.
>>> 
>>> I suspect that this issue is related to the large amount of text in
>>> the script but have not seen this before with this script until I
>>> updated to LC 9.6.2 (rc3).
>>> 
>>> Can anyone confirm this issue?
>> 
>> I have seen similar issues on Ubuntu.  I believe it may be related to the 
>> complicated way the line number field is kept in sync.
>> 
>> The only workaround I've tested is writing my own script editor, thankfully 
>> subsidized by a generous soul who commissioned it.  It's not yet ready for 
>> prime time, though, so I have no immediate solution for LC SE users.
>> 
>> 
>>> Also, is there an upper limit to the size of a LC script?
>> 
>> There should not be, at least within reasonable memory limits.
>> 
>> And if there were, it shouldn't be anywhere near as short as 5900 lines. 
>> I've been stress-testing my with 20k-line scripts.
>> 
>> The LC field object is quite good.  Any script editor using it should be 
>> quite good too.
>> 
>> -- 
>> Richard Gaskin
>> Fourth World Systems
>> Software Design and Development for the Desktop, Mobile, and the Web
>> 
>> ambassa...@fourthworld.comhttp://www.FourthWorld.com
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Problem with Script Editor in LC 9.6.2 (rc3)

[HENRY LOWE via use-livecode]

Thanks Richard. I turned off the line number option and the problem still 
occurs. I can reproduce this with any script that extend beyond the bottom of 
the script editor pane. 

Select the first line of a script and then (holding the mouse button down) 
continue dragging down to select additional lines until you are reach the last 
visible line. Continue to drag down to get the script editor to autoscroll and 
the scrolling now continues automatically until the entire script is selected. 
Cannot stop the scroll until the entire script is selected.

Looks like a new bug to me.

Henry

> On Mar 24, 2021, at 2:45 PM, Richard Gaskin via use-livecode 
>  wrote:
> 
> Henry Lowe wrote:
> 
> > If I select text in the LC Script Editor and then drag down to select
> > additional text (e.g. I want to select an entire handler), the editor
> > starts to autoscroll and does not stop until it reaches the end of the
> > script text. Nothing I do stops the scrolling and text selection. I am
> > locked out of LC, which is unresponsive. Activity Monitor shows that
> > LC is using 100% of the CPU while in this ‘autoscrolling’ state. Once
> > the scroll reaches the end of the text in the editor pane, I get
> > control of LC again.
> >
> > This is only happening with a very large script 5900 lines of text
> > (238K). I am in the progress of breaking this script up into a series
> > of smaller scripts.
> >
> > I suspect that this issue is related to the large amount of text in
> > the script but have not seen this before with this script until I
> > updated to LC 9.6.2 (rc3).
> >
> > Can anyone confirm this issue?
> 
> I have seen similar issues on Ubuntu.  I believe it may be related to the 
> complicated way the line number field is kept in sync.
> 
> The only workaround I've tested is writing my own script editor, thankfully 
> subsidized by a generous soul who commissioned it.  It's not yet ready for 
> prime time, though, so I have no immediate solution for LC SE users.
> 
> 
> > Also, is there an upper limit to the size of a LC script?
> 
> There should not be, at least within reasonable memory limits.
> 
> And if there were, it shouldn't be anywhere near as short as 5900 lines. I've 
> been stress-testing my with 20k-line scripts.
> 
> The LC field object is quite good.  Any script editor using it should be 
> quite good too.
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Problem with Script Editor in LC 9.6.2 (rc3)

[Richard Gaskin via use-livecode]

Henry Lowe wrote:

> If I select text in the LC Script Editor and then drag down to select
> additional text (e.g. I want to select an entire handler), the editor
> starts to autoscroll and does not stop until it reaches the end of the
> script text. Nothing I do stops the scrolling and text selection. I am
> locked out of LC, which is unresponsive. Activity Monitor shows that
> LC is using 100% of the CPU while in this ‘autoscrolling’ state. Once
> the scroll reaches the end of the text in the editor pane, I get
> control of LC again.
>
> This is only happening with a very large script 5900 lines of text
> (238K). I am in the progress of breaking this script up into a series
> of smaller scripts.
>
> I suspect that this issue is related to the large amount of text in
> the script but have not seen this before with this script until I
> updated to LC 9.6.2 (rc3).
>
> Can anyone confirm this issue?

I have seen similar issues on Ubuntu.  I believe it may be related to 
the complicated way the line number field is kept in sync.


The only workaround I've tested is writing my own script editor, 
thankfully subsidized by a generous soul who commissioned it.  It's not 
yet ready for prime time, though, so I have no immediate solution for LC 
SE users.



> Also, is there an upper limit to the size of a LC script?

There should not be, at least within reasonable memory limits.

And if there were, it shouldn't be anywhere near as short as 5900 lines. 
I've been stress-testing my with 20k-line scripts.


The LC field object is quite good.  Any script editor using it should be 
quite good too.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Problem with Script Editor in LC 9.6.2 (rc3)

[HENRY LOWE via use-livecode]

Since updating to LC 9.6.2 (rc3) on a 2019 iMac running Mac OS Big Sur 11.2.3 I 
have been experiencing the following intermittent issue:

If I select text in the LC Script Editor and then drag down to select 
additional text (e.g. I want to select an entire handler), the editor starts to 
autoscroll and does not stop until it reaches the end of the script text. 
Nothing I do stops the scrolling and text selection. I am locked out of LC, 
which is unresponsive. Activity Monitor shows that LC is using 100% of the CPU 
while in this ‘autoscrolling’ state. Once the scroll reaches the end of the 
text in the editor pane, I get control of LC again. 

This is only happening with a very large script 5900 lines of text (238K). I am 
in the progress of breaking this script up into a series of smaller scripts.

I suspect that this issue is related to the large amount of text in the script 
but have not seen this before with this script until I updated to LC 9.6.2 
(rc3).

Can anyone confirm this issue?

Also, is there an upper limit to the size of a LC script?

Thanks,

Henry
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode