Ronning out of Undo

[TerryRitchie]

Oh, wow, I didn't know that's how the undo buffer works, but it makes perfect sense once you think about it.

Is that why when I get to around 3000 lines and more of code things start progressively getting slower for me? If that's the case can a menu entry be added to turn off the buffer? I rarely ever use the Undo/Redo functions and restoring from a backup after a crash has saved my bacon maybe once in the last few years.

Or perhaps have an option to turn auto buffer saves off and instead use a "snapshot" hot key to manually save a copy of the code when requested.

Or (sorry, ideas floating in my head) the option to set up a timed snapshot, say once per minute or once every 5 minutes. My paint program operates that way, it takes a snapshot every 5 minutes and then I can revert back through those 5 minute snapshots.

The problem you're talking about is one that I plan on trying to work on someday(tm). 

Basically the issue is that our whole program is stored in a single string variable inside qb64.bas.  (idet$ -- IDE Text$)

So when you add a line to a program, it basically does this:

idet$ = LEFT$(idet$, before_your_insert_position) + your_insert$ + MID$(idet$, after_your_insert_position)

And, if you remember my demo about adding strings the other day and how slow that gets with larger strings -- that's what you're talking about.
Basically it's: idet$ = 1500 lines of code + your new line of code + 1500 lines of code.... to form the new 3001 line program.

And that's a lot of memory to be shuffling about left and right and adding together and such --- and it basically performs this shuffling, adding, ect **WITH EVERY MOUSECLICK OR KEYPRESS**!!

And that's got to get optimized at some point in time.  The issue is just how often idet$ is used, how many changes would be needed, how much old stuff might break, and who has the time to sit down and sort it all out to change it to something more reasonable for us.

Gotcha, looking forward to what you come up with.