Ronning out of Undo

[PhilOfPerth]

While the Undo is extremely useful for recovering from a faux-pas (and that's quite frequent for me), there doesn't seem to be
 an indication when you've used up all your Undo's. When this involved back-tracking over a number of  changes, you may reach 
the limit, and no changes are made. This can be hard to see with a long programme, as  changes may not be obvious in the IDE.
Is there, or can there be, a "Limit of Undo" message?

[TerryRitchie]

While the Undo is extremely useful for recovering from a faux-pas (and that's quite frequent for me), there doesn't seem to be
 an indication when you've used up all your Undo's. When this involved back-tracking over a number of  changes, you may reach 
the limit, and no changes are made. This can be hard to see with a long programme, as  changes may not be obvious in the IDE.
Is there, or can there be, a "Limit of Undo" message?

For now you could increase the history buffer to 2000MB (2GB) so you'll probably never reach the limit.

Options menu -> Backup/Undo...

I use a paint program that describes what you want. When I reach the limit of the buffer it pops up a message stating that no further undo actions can be recorded.

[SMcNeill]

It's almost impossible to say how many Undo you can do.

QB64PE basically makes a copy of your program with every change you make, and that's the undo file.

For example, let's type a program together:

PRINT "Hello World"

Now, what does that undo file look like?
PRINT
PRINT "Hello
PRINT "Hello World"
....

Basically, it's a copy of your program saved over and over and over, as you make each change.  In this case, that's 3 entries in that undo file.  Not a large file and nowhere near any undo limit...

But say that file was 1000 lines long.   It'd save those 1000 lines *WITH EVERY CHANGE TO YOUR CODE*, so when you hit UNDO, it'd revert back to what your program was 1 change ago.

So if your program was using all short lines like:

DO
    PRINT
    x = x + 1
    y = y  + 1
and so on...

That's not going to use a lot of memory to store that program in the undo buffer.

But if the program was more complex:

DO
   _UPRINTSTRINT(xpos, ypos), "This is a longer string of stuff", 47.2, other_flag_maybe
   x_upper_limit_for_my_graphics =  x_upper_limit_for_my_graphics + 1
   y_upper_limit_for_my_graphics =  y_upper_limit_for_my_graphics + 1
and so on...

That's obviously going to create a much larger BAS file, and as such, it's going to use a LOT more of the undo buffer with each save of the file.

---

So how do you know when you've hit the limit??

It all depends on the size of your program.

The default undo buffer is 100MB in size.  If your program is 1MB in size, then you can basically save 100 copies of it in memory -- 100 undos.   IF your program is 100kb in size, then you can basically save 1000 copies of it in memory.

Your limit is based off the size of your program, and how many copies of it you can cram into it's total size.  (Default 100MB.)

---

If that 100MB isn't large enough (and it's usually not for my personal needs), then I suggest changing that size to something you find more suitable.  I tend to change mine to 1000MB, whenever I grab a fresh version of QB64PE for things. 

[SMcNeill]

While the Undo is extremely useful for recovering from a faux-pas (and that's quite frequent for me), there doesn't seem to be
 an indication when you've used up all your Undo's. When this involved back-tracking over a number of  changes, you may reach 
the limit, and no changes are made. This can be hard to see with a long programme, as  changes may not be obvious in the IDE.
Is there, or can there be, a "Limit of Undo" message?

For now you could increase the history buffer to 2000MB (2GB) so you'll probably never reach the limit.

Options menu -> Backup/Undo...

I use a paint program that describes what you want. When I reach the limit of the buffer it pops up a message stating that no further undo actions can be recorded.

The main problem here is that the way we do things, we never actually run out of undos.

For a quick example of how we tend to do things, it's basically like this:

Code: (Select All)

Do

    a$ = Input$(1)

    l$ = Right$(l$ + a$, 10)

    Cls

    Print l$

Loop Until a$ = Chr$(13)

Start typing.  1234567890   <-- up until this point, you can back up one character at a time and undo your typing.

Type some more.  ABCD     <-- now your string looks like "567890ABCD"...   you can now back up one character at a time, and undo the last 10 things you typed.

At no point do you actually run out of undos, as they tend to overwrite the older undos.

And as for how many undos you have??  

That's all depends on how large your program is, and how much information you added in any particular change, and how large the limit is.

In other words, it's hard to say. 

Did you type "PRINT" as the last change, or did you CTRL-V and paste in 1000 lines of code??   The size of those changes are going to be variable, depending on your actions, so it's hard to say, "OH!  This one is the one that broke the camel's back!"

[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.

[SMcNeill]

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.

[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.

[PhilOfPerth]

Then can't the Undo function compare the before and after versions, and report if no changes were made?

[SMcNeill]

Then can't the Undo function compare the before and after versions, and report if no changes were made?

If the program doesn't change, then the undo isn't going to change.   If no changes are made, there's not going to be a "before and after" to report on.

PRINT "foo"

Type that in, and you have 2 basic undo points:
PRINT
PRINT "foo"

Unless that PRINT "foo" changes, that undo file isn't going to change either, as it's only going to log when you make a change.  Everytime you undo, a change is going to happen. 

[PhilOfPerth]

Then can't the Undo function compare the before and after versions, and report if no changes were made?

If the program doesn't change, then the undo isn't going to change.   If no changes are made, there's not going to be a "before and after" to report on.

PRINT "foo"

Type that in, and you have 2 basic undo points:
PRINT
PRINT "foo"

Unless that PRINT "foo" changes, that undo file isn't going to change either, as it's only going to log when you make a change.  Everytime you undo, a change is going to happen. 

Ok, thanks. Just a thought...