Problem with Script Editor in LC 9.6.2 (rc3)

[Richard Gaskin]

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 <g>:


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 xTalkers. These strengths give us a beautiful engine, and an IDE 
that could probably benefit from some trimming.


xTalk is a funny thing, and it's not easy coming up with a concise rule 
set for what constitutes good with-the-grain savvy of The xTalk Way.

But we know it when we see it. And line numbers that lag behind editor 
field scrolls may be an example where The Zen of The xTalk Way might 
produce a smoother solution.

-- 
Richard Gaskin
Fourth World Systems