Problem with Script Editor in LC 9.6.2 (rc3)

[Sean Cole (Pi)]

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 at 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 <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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>