Line Numbers in Text Editor

[Richard Gaskin]

Good stuff, Jeff.  Thanks for posting that.

In the olden days I had to be very careful about attempting to update 
things on scrollBarDrag because the performance hit was often quite 
noticeable, but on modern systems I must say I've been impressed with 
the combination of general system performance and the smart way the 
scrollBarDrag message is sent to support that sort of thing.

Not long ago I needed to draw a series of polygons with certain shapes 
and locations relative to positions of chunks of text in a scrolling 
field.  After some experimentation I was delighted to find out well it 
worked to do that dynamically on the fly, calculating and rendering the 
polygons in response to scrollBarDrag.

But on that project I had one advantage I don't have with a script 
editor:  the field I'm doing my calculations with is read-only, whereas 
a script editor's contents are dynamic.

I also had no choice: in Rev, objects are limited to 32,767 px in 
height, but of course for a field with a lot of content I could (and 
did) easily wind up needing a polygon much taller than that.  This is 
similar to the problem Trevor's DataGrid solves, in which contents that 
would be prohibitively tall can be rendered dynamically if needed.

But since line numbers can be done in advance without difficulty it 
would not have occurred to me to render them dynamically.

How responsive do you find that algo with carriage returns?

If a script editor provides auto-indenting the returnInField message is 
already pretty well loaded with code, which is why I've been reluctant 
to add more to it with things like dynamic line numbers.  Memory size is 
usually minimal with prefab line numbers since they generally take up a 
small fraction of the space of the script itself, and I would be 
reluctant to also page the script in an out of the field in response to 
scrollbarDrag for the complexity it adds and given that the engine's 
field buffering is some of the best in the biz.

But if your experience is favorable it may well be worth exploring that 
in my next revision.

Thanks again for the provocative take on this problem.  One of the great 
things about Rev is the wide variety of ways a given problem can be solved.

--
  Richard Gaskin
  Fourth World
  Rev training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com
  revJournal blog: http://revjournal.com/blog.irv


Jeff Massung wrote:

> I gotta say, my name is Jeff Massung, and I disapprove of that solution. ;-)
>
> I love everyone sharing their ideas, but this is one that's been a solved
> problem, well... for a very long time, and with a little math there's no
> performance issue what-so-ever, and there's no need to keep around a field
> with thousands of numbers in it.
>
> Think of what we know:
>
> * The size of our editor.
> * Where the scrollbar is.
> * The size of the font we're using.
>
>>From this, there's very little we actually need to do. Even with the largest
> monitor on the planet and using the smallest (readable) font, the number of
> average lines visible to any user is well < 100. So, generally speaking, we
> should never need to do much more than count to 100 at any given point in
> time to update our "gutter" area containing line numbers.
>
> So, here's a little script taking from my editor. It assumes that the the
> gutter area is always sized to the same height as the editor, that the line
> height is fixed (read: we're not embedding images or changing the font
> size), and that the editor has line wrapping turned off. With a few tweaks
> it could work just fine with those features on, but for the sake of this
> discussion, we'll leave them off.
>
> on updateGutter
>
>    local tHeight
>
>    local tTextHeight
>
>    local tScroll
>
>    local tFirstRow
>
>    local tRows
>
>
>
>    -- wipe the gutter clean
>
>    put empty into fld "Line Numbers"
>
>
>
>    -- snag what we care about from the editor
>
>    put the vScroll of fld "Editor" into tScroll
>
>    put the effective textHeight of fld "Editor" into tTextHeight
>
>    put the height of fld "Editor" into tHeight
>
>
>
>    -- calculate the first visible line and the total number of visible lines
>
>    put tScroll div tTextHeight into tFirstRow
>
>    put tHeight div tTextHeight into tRows
>
>
>
>    -- fill in the gutter with the line numbers
>
>    repeat with tLine = tFirstRow to tFirstRow + tRows
>
>       put tLine + 1 & cr after fld "Line Numbers"
>
>    end repeat
>
>
>
>    -- scroll the gutter (every so slightly) to match the editor
>
>    set the textSize of fld "Line Numbers" to the textSize of fld "Editor"
>
>    set the textFont of fld "Line Numbers" to the textFont of fld "Editor"
>
>    set the vScroll of fld "Line Numbers" to tScroll mod tTextHeight
> end updateGutter
>
> That's pretty much it. Now we need to know when to update the gutter area.
> We need to update it when:
>
> * on scrollbarDrag (the editor)
> * when the we reset the editor to display something new
> * when we resize the editor (and subsequently the gutter)
>
> HTH,
>