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