For those you looking for an exciting topic to discuss over Friday night dinner with your friends, here's an important philosophical question with a trivia component:

The philosophical question: should the VUE >SAVE operation recycle the .BAK file? In other words if you use >SAVE multiple times during an editing session and then finish, should the .BAK file contain the version of the original file prior to the editing session? Or just prior to the more recent >SAVE ?

The trivia component: what did the original AlphaVUE do?

A particularly persnickety old AMOS / new A-Shell user has raised the question, saying that we have it wrong. And I don't have access to an AMOS machine to check what it used to do.

But the original question is more important: what should it do? Or do we need yet another INI.VUE option?

After a very long evening with family and friends going around in circles causing lots of alcohol be consumed it was a close call, but create the .Bak on VUEing the file and SAVE does not effected it , I think, as we got side tracked with DSKANA and DSKPAK future ashell feature what they should do…

What are you talking about here?

I know Jorge VUEs existence is hard to remember sometimes

Wow! Plato and Socrates have nothing on you two!

Where's Herman when you need him...

Ok i have been bit by this "feature" multiple times. In fact if you somehow step on the existing .bak file it wouldn't even let you >Save the current open one! And there have been countless times that after making a few changes to a program i realized i just wanted to rollback to the original version only to have the most recent .bak which is also flawed. Now before anyone starts shooting arrows yes i do archive the original original before undertaking surgery, but in a quick working/debug environment it would be nice to a have some grandfathered copies to restart from. So what does that mean? Would it make sense to allow for 9? then overwrite, such as ba1...ba9? What does APN do in this case?

APN (and similar environments) it’s more undo an action, press Ctrl + Z. (Even dozens of times to keep going back), and redo an undone action,Ctrl + Y. Etc
(Else it’s go back to the original before any of the undertaken surgery was made)

Right, and in fact, the undo feature typically transcends SAVE operations, i.e. even if you saved the file, you can still undo those changes as long as the original editing session is still alive. What that doesn't cover is "Finisher's Remorse" (sounds like a blockbuster movie title) where you finish the editing session and then realize you don't want either the pre-editing BAK copy, or the post-editing saved copy, but something in between.

I am a bit confused by your comments, Frank. As far as I can tell, VUE's SAVE and FINISH operations continue to work even if you delete the BAK file while the editing session is active. Also, up until the new SAVEBAK option was added in 7.0.1756.3, multiple SAVEs did not replace the original BAK file. So regardless of what happened during the session, when you exited you'd have the pre-session BAK file to go back to. Now, you have the option of updating the BAK file on each SAVE for those who prefer that.

It didn't occur to me to implement a series of BAK, BA1, BA2, ... files. That sounds like a sure way to fill up your disk with old copies! But to be fair, I essentially do the same thing when editing programs to be run on customer LInux systems. I created a pair of DO files, SRCPULL and SRCPUSH, the former to first grab the file from the Linux server back to my Windows APN environment. When I'm done, I SRCPUSH it back (which archives the previous file, using an N-generation sequence (xx1, xx2, ...), with the backup copies moved to another device to keep the current directory less cluttered. That allows me to do what you are alluding to, i.e. to back umpteen generations to find a change I want to back out. But the 'real' way to do that is with a source code version management utility, like Git, Mercurial, Subversion, etc. I use APN TortoiseGit for in-house ASB development, the main downside of which they don't directly integrate with each other. At the last Conference, a sharp new developer (Matt) demonstrated a Visual Studio Code that he had taught to understand ASB, and it does have the ability to integrate with Git for more seamless version/change tracking. But while VUE is nice for limited editing tasks, adding modern developer features like change tracking to it seems a bit like adding a headrest to a bed of nails!

In all fairness that was an old amos quirk. If you accidentally "vue'd" the same program at the same time it would wipe out the .bak thus not allowing you to save the current version. (after cursing, and losing changes a few times i realized i could just copy the entire contents of the file and unyank to a temp filename... good times!)

I wasn't aware of a new SAVEBAK option, though not sure I have much need for it. As far as the grandfathered .bak versions, i wasn't considering requesting such a feature.. i have been using vue for so long I am more than aware of how to manage versions, etc. I don't really see the need for bloated utilities... this is not that hard. Unless you have teams of coders all working from different locations its not rocket science.