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

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

Reply via email to