Line Numbers in Text Editor

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Line Numbers in Text Editor

Justin Sloan
I am planning to implement line numbers in a proprietary text editor
that I wrote for in-house use.  Problem is, I don't know how I am
going to implement it. I thought about using a parallel text field,
but there has to be an easier way.  Any of you genius devs have any
ideas?
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: Line Numbers in Text Editor

Jeffrey Massung
I used a parallel field in my Cryogen editor (http://massj.tumblr.com for
video + screenshot). Worked out perfectly, and now that I've done it that
way once, I actually wouldn't want to do it any other way in the future.

Jeff M.

On Thu, Jun 24, 2010 at 6:01 AM, Justin Sloan <[hidden email]>wrote:

> I am planning to implement line numbers in a proprietary text editor
> that I wrote for in-house use.  Problem is, I don't know how I am
> going to implement it. I thought about using a parallel text field,
> but there has to be an easier way.  Any of you genius devs have any
> ideas?
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: Line Numbers in Text Editor

Justin Sloan
I went with using a parallel field to add line numbers and it is
working well. However, rev only counts the line numbers based on the
delimeter. So if word warp is turned on you end up with more lines
then there are actual line numbers.

Does anyone know of a way to count all the lines, even the lines that
are wrapped and not separated by the delimeter?

 - Justin



On Thu, Jun 24, 2010 at 5:44 PM, Jeff Massung <[hidden email]> wrote:

> I used a parallel field in my Cryogen editor (http://massj.tumblr.com for
> video + screenshot). Worked out perfectly, and now that I've done it that
> way once, I actually wouldn't want to do it any other way in the future.
>
> Jeff M.
>
> On Thu, Jun 24, 2010 at 6:01 AM, Justin Sloan <[hidden email]>wrote:
>
>> I am planning to implement line numbers in a proprietary text editor
>> that I wrote for in-house use.  Problem is, I don't know how I am
>> going to implement it. I thought about using a parallel text field,
>> but there has to be an easier way.  Any of you genius devs have any
>> ideas?
>> _______________________________________________
>> use-revolution mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: Line Numbers in Text Editor

BNig
Justin,

look at the formattedText property of a text field. It gives you the the text of a field and inserts returns where the line wraps otherwise. This way you have a line count of the field which matches what you see and not the number of returns.

put the formattedText of field "myWrappingField" into temp
put the number of lines of temp

regards
Bernd
Reply | Threaded
Open this post in threaded view
|

Re: Line Numbers in Text Editor

Klaus on-rev
Hi Justin,

Am 25.06.2010 um 10:49 schrieb BNig:

>
> Justin,
>
> look at the formattedText property of a text field. It gives you the the
> text of a field and inserts returns where the line wraps otherwise. This way
> you have a line count of the field which matches what you see and not the
> number of returns.
>
> put the formattedText of field "myWrappingField" into temp
> put the number of lines of temp

or, if you are in a hurry:
...
put the num of lines of the formattedtext of fld "Bernd's WrappingField"
...

;-)

> regards
> Bernd

Best

Klaus

--
Klaus Major
http://www.major-k.de
[hidden email]

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: Line Numbers in Text Editor

Alex Tweedly
In reply to this post by Justin Sloan
The straightforward answer is using formattedText ..... but the deeper
question is what line numbering you want for the lines when there is
line-wrapping happening. For instance, if it is something like a source
code editor, then the line numbers (IMHO) should be independent of the
size of window currenty in use.

For example,  if I have the following text

  1   My first line
  2 this is a very long line of text that is going to be wrapped in a
moment when I make the window narrow.
  3 third line.

Then when the window becomes narrow, do I *want*

  1   My first line
  2  this is a very long line of text that is going to be wrapped
  3  in a moment when I make the window narrow.
  4  third line.

or do I want something like

  1   My first line
  2   this is a very long line of text that is going to be wrapped
  2a  in a moment when I make the window narrow.
  3   third line.

It really depends on whether you are numbering the lines of the window
or the lines of the underlying text (or source code, or whatever); quite
often, I suspect, it should be the latter. And in that case I don't know
of any quick or easy way to figure out how the numbering should be done :-(

-- Alex.



On 25/06/2010 08:25, Justin Sloan wrote:

> I went with using a parallel field to add line numbers and it is
> working well. However, rev only counts the line numbers based on the
> delimeter. So if word warp is turned on you end up with more lines
> then there are actual line numbers.
>
> Does anyone know of a way to count all the lines, even the lines that
> are wrapped and not separated by the delimeter?
>
>   - Justin
>
>
>
> On Thu, Jun 24, 2010 at 5:44 PM, Jeff Massung<[hidden email]>  wrote:
>    
>> I used a parallel field in my Cryogen editor (http://massj.tumblr.com for
>> video + screenshot). Worked out perfectly, and now that I've done it that
>> way once, I actually wouldn't want to do it any other way in the future.
>>
>> Jeff M.
>>
>> On Thu, Jun 24, 2010 at 6:01 AM, Justin Sloan<[hidden email]>wrote:
>>
>>      
>>> I am planning to implement line numbers in a proprietary text editor
>>> that I wrote for in-house use.  Problem is, I don't know how I am
>>> going to implement it. I thought about using a parallel text field,
>>> but there has to be an easier way.  Any of you genius devs have any
>>> ideas?
>>> _______________________________________________
>>> use-revolution mailing list
>>> [hidden email]
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>>
>>>        
>> _______________________________________________
>> use-revolution mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>
>>      
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>    

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: Line Numbers in Text Editor

pmbrig
On Jun 25, 2010, at 7:37 PM, Alex Tweedly wrote:

> The straightforward answer is using formattedText ..... but the  
> deeper question is what line numbering you want for the lines when  
> there is line-wrapping happening. For instance, if it is something  
> like a source code editor, then the line numbers (IMHO) should be  
> independent of the size of window currenty in use.
>
> For example,  if I have the following text
>
> 1   My first line
> 2 this is a very long line of text that is going to be wrapped in a  
> moment when I make the window narrow.
> 3 third line.
>
> Then when the window becomes narrow, do I *want*
>
> 1   My first line
> 2  this is a very long line of text that is going to be wrapped
> 3  in a moment when I make the window narrow.
> 4  third line.
>
> or do I want something like
>
> 1   My first line
> 2   this is a very long line of text that is going to be wrapped
> 2a  in a moment when I make the window narrow.
> 3   third line.
>
> It really depends on whether you are numbering the lines of the  
> window or the lines of the underlying text (or source code, or  
> whatever); quite often, I suspect, it should be the latter. And in  
> that case I don't know of any quick or easy way to figure out how  
> the numbering should be done :-(
>
> -- Alex.

In the latter case, the easiest way to approach the problem is to  
place the line numbers into the field itself with a tab delimiter.  
It's easy to get something like:

> 1   My first line
> 2   this is a very long line of text that is going to be wrapped
> in a moment when I make the window narrow. <--------
> 3   third line.

(If you need the "2a" option, not so easy.)

Then script around the problem of fetching text from the field by  
something like:

    function getlinetext lineNbrStart, lineNbrEnd
       set the itemdelimiter to tab
       repeat with n = lineNbrStart to lineNbrEnd
          put (item 2 of line n of fld "text") & cr after textList
       end repeat
       return char 1 to -2 of textList
    end getlinetext

This doesn't avoid messiness in what happens when the user selects  
text in the field, but could be useful in some contexts, eg, a list  
field. The Rev IDE script editor uses two fields and doesn't try to  
sort out line wrapping -- the script field is dontwrap = true.

If the rumors about a major revamping of the field object are true,  
maybe we can have built-in functions that give both the clickLine and  
the "formattedClickLine" -- ie, the line marked by the arrow in the  
example above would be clickline = 2, formattedclickline = 3

-- Peter

Peter M. Brigham
[hidden email]
http://home.comcast.net/~pmbrig


_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: Line Numbers in Text Editor

BNig
In reply to this post by Alex Tweedly
Hi Alex,
I gave it a try:

as revlet
http://berndniggemann.on-rev.com/textLineNumbers/
as zipped stack
http://berndniggemann.on-rev.com/textLineNumberStack/

is a proof of principle, seems to work though. Sometimes a little awkward :)

regards
Bernd


Alex Tweedly wrote
The straightforward answer is using formattedText ..... but the deeper
question is what line numbering you want for the lines when there is
line-wrapping happening. For instance, if it is something like a source
code editor, then the line numbers (IMHO) should be independent of the
size of window currenty in use.

For example,  if I have the following text

  1   My first line
  2 this is a very long line of text that is going to be wrapped in a
moment when I make the window narrow.
  3 third line.

Then when the window becomes narrow, do I *want*

  1   My first line
  2  this is a very long line of text that is going to be wrapped
  3  in a moment when I make the window narrow.
  4  third line.

or do I want something like

  1   My first line
  2   this is a very long line of text that is going to be wrapped
  2a  in a moment when I make the window narrow.
  3   third line.

It really depends on whether you are numbering the lines of the window
or the lines of the underlying text (or source code, or whatever); quite
often, I suspect, it should be the latter. And in that case I don't know
of any quick or easy way to figure out how the numbering should be done :-(

-- Alex.



On 25/06/2010 08:25, Justin Sloan wrote:
> I went with using a parallel field to add line numbers and it is
> working well. However, rev only counts the line numbers based on the
> delimeter. So if word warp is turned on you end up with more lines
> then there are actual line numbers.
>
> Does anyone know of a way to count all the lines, even the lines that
> are wrapped and not separated by the delimeter?
>
>   - Justin
>
>
>
> On Thu, Jun 24, 2010 at 5:44 PM, Jeff Massung<massung@gmail.com>  wrote:
>    
>> I used a parallel field in my Cryogen editor (http://massj.tumblr.com for
>> video + screenshot). Worked out perfectly, and now that I've done it that
>> way once, I actually wouldn't want to do it any other way in the future.
>>
>> Jeff M.
>>
>> On Thu, Jun 24, 2010 at 6:01 AM, Justin Sloan<justin.sloan@us.army.mil>wrote:
>>
>>      
>>> I am planning to implement line numbers in a proprietary text editor
>>> that I wrote for in-house use.  Problem is, I don't know how I am
>>> going to implement it. I thought about using a parallel text field,
>>> but there has to be an easier way.  Any of you genius devs have any
>>> ideas?
Reply | Threaded
Open this post in threaded view
|

Re: Line Numbers in Text Editor

Richard Gaskin
In reply to this post by Justin Sloan
Justin Sloan wrote:
 > I am planning to implement line numbers in a proprietary text editor
 > that I wrote for in-house use.  Problem is, I don't know how I am
 > going to implement it. I thought about using a parallel text field,
 > but there has to be an easier way.  Any of you genius devs have any
 > ideas?

I forked the MC IDE's script editor many years ago to add, among other
things, line numbers.  It was at the time the only script editor for Rev
which had line numbers, and having implemented this "advanced
technology" <g> I can share with you a couple tips I learned:

The line numbers are displayed in a separate field to the left of the
editor field, kept in synch with scrollbardrag handlers in each.  Being
a script editor I also have another field in between them for marking
breakpoints, but you probably won't need that for other types of editing.

I chose a separate field for the line numbers because it seemed a more
with-the-grain approach than attempting to put anything in the editor
field except for the script itself.  In Rev, a script is just a block of
text, so my mandate for my editor was to maintain as close a
relationship as possible between what you see and what the engine
expects.  So the script is dumped into a field, with no caches or other
intermediaries to complicate the scripter's relationship with the
engine. WYGIWE - what you got is what exists. ;)  I have a McCabe algo
for Rev (see note on RevCloud below) so I'm sensitive to the impact of
complexity in a code base.

At first I went the route most other text editors use, in which the line
number field is populated dynamically to show only the lines present in
the editor field.  But I found that when I got beyond a few thousand
lines the time it takes the engine to render the line number field
became a performance drag on my typing.  So I went with having
pre-populated numbers, which isn't so bad since you can still see how
many lines you have in your script by just scrolling to the end and look
at the last line number across from the last line of script.

But even pre-populating the line number field was not without some
challenge, since putting in 10,000 lines of numbers would not be
sufficient for some scripts, and added a lot of bulk to the editor stack
file.

So the final solution I went with was leaving the field blank when the
stack is saved, and populating it on preOpenStack with the number of
lines of the script + 5000.  Since this is a one-time performance hit
when the stack opens, the impact on performance isn't nearly as
noticeable as it was when I was appending that list with each carriage
return (has anyone younger than 40 even seen an actual typewriter
carriage? Odd nomenclature in the 21st century, but I digress).

This keeps the stack file small enough to be extremely portable (I'm
migrating a lot of tools to cloud storage - look for RevCloud coming
soon to RevNet this summer; think devolution on serious steroids and
focused on collaborative workflows), and it's unlikely that a person
will type more than 5000 lines during a given session with the editor open.

But what if they paste more than 5k lines?  I've trapped for that in the
Paste item and add another block of lines numbers beyond the number
already in the field + the number in the clipboard, so we stay a few
thousand lines ahead of the scripter.

HTH -

--
  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
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: Line Numbers in Text Editor

Stephen Barncard-4
RevCloud?? wha?

ok Richard, you've opened the door.... now you must tell us more...
( I didn't want that to rhyme.)

On 26 June 2010 09:23, Richard Gaskin <[hidden email]> wrote:

> ...
> This keeps the stack file small enough to be extremely portable (I'm
> migrating a lot of tools to cloud storage - look for *RevCloud* coming
> soon to RevNet this summer; think devolution on serious steroids and focused
> on collaborative workflows), and it's unlikely that a person will type more
> than 5000 lines during a given session with the editor open.
>
> --
-------------------------
Stephen Barncard
San Francisco
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: Line Numbers in Text Editor

Justin Sloan-2
In reply to this post by Richard Gaskin
Richard,

Fantastic primer on handling line numbers in Rev! Thank you!  It's amazing how something seemingly so simple can have such a huge impact.

That is what I love about programming, the elegance of creative solutions.


 - Justin


On Jun 26, 2010, at 7:23 PM, Richard Gaskin wrote:

> Justin Sloan wrote:
> > I am planning to implement line numbers in a proprietary text editor
> > that I wrote for in-house use.  Problem is, I don't know how I am
> > going to implement it. I thought about using a parallel text field,
> > but there has to be an easier way.  Any of you genius devs have any
> > ideas?
>
> I forked the MC IDE's script editor many years ago to add, among other things, line numbers.  It was at the time the only script editor for Rev which had line numbers, and having implemented this "advanced technology" <g> I can share with you a couple tips I learned:
>
> The line numbers are displayed in a separate field to the left of the editor field, kept in synch with scrollbardrag handlers in each.  Being a script editor I also have another field in between them for marking breakpoints, but you probably won't need that for other types of editing.
>
> I chose a separate field for the line numbers because it seemed a more with-the-grain approach than attempting to put anything in the editor field except for the script itself.  In Rev, a script is just a block of text, so my mandate for my editor was to maintain as close a relationship as possible between what you see and what the engine expects.  So the script is dumped into a field, with no caches or other intermediaries to complicate the scripter's relationship with the engine. WYGIWE - what you got is what exists. ;)  I have a McCabe algo for Rev (see note on RevCloud below) so I'm sensitive to the impact of complexity in a code base.
>
> At first I went the route most other text editors use, in which the line number field is populated dynamically to show only the lines present in the editor field.  But I found that when I got beyond a few thousand lines the time it takes the engine to render the line number field became a performance drag on my typing.  So I went with having pre-populated numbers, which isn't so bad since you can still see how many lines you have in your script by just scrolling to the end and look at the last line number across from the last line of script.
>
> But even pre-populating the line number field was not without some challenge, since putting in 10,000 lines of numbers would not be sufficient for some scripts, and added a lot of bulk to the editor stack file.
>
> So the final solution I went with was leaving the field blank when the stack is saved, and populating it on preOpenStack with the number of lines of the script + 5000.  Since this is a one-time performance hit when the stack opens, the impact on performance isn't nearly as noticeable as it was when I was appending that list with each carriage return (has anyone younger than 40 even seen an actual typewriter carriage? Odd nomenclature in the 21st century, but I digress).
>
> This keeps the stack file small enough to be extremely portable (I'm migrating a lot of tools to cloud storage - look for RevCloud coming soon to RevNet this summer; think devolution on serious steroids and focused on collaborative workflows), and it's unlikely that a person will type more than 5000 lines during a given session with the editor open.
>
> But what if they paste more than 5k lines?  I've trapped for that in the Paste item and add another block of lines numbers beyond the number already in the field + the number in the clipboard, so we stay a few thousand lines ahead of the scripter.
>
> HTH -
>
> --
> 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
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: Line Numbers in Text Editor

Jeffrey Massung
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,

Jeff M.
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: Line Numbers in Text Editor

Richard Gaskin
In reply to this post by Justin Sloan
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,
>


_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution