On Sat, 8 Dec 2018, at 18:59, Gene Heskett wrote: > ... but the lack of a plainly marked, multiple step undo gets > me into a dead end box that results in a quit w/o save every time.
I had a similar problem with a music-typesetting package under Windows. I guess a versioning file system (as discussed here fairly recently) would help, but I don't have one. Eventually I solved it with a script which examines a set of files (I specify a pattern for those) in the folder I'm working in. When it starts and every few seconds (eg 10 secs) afterwards, it looks at the files whose name matches that pattern. For every file it finds for which there is not a corresponding backup copy, it makes one. A backup copy of a file has (svd@yyyymmdd-hhmmss) appended to its extensionless leafname, where the date & time correspond to the time the backed-up file was last saved (not the time that this script saved the backup). So as soon as the script starts it makes a copy of each matching file (assuming none of those had prior backup copies) then whenever such a file changes and is written to disk again, another backup is made. So eg Some song or other.pqr could yield: Some song or other (svd@20120716-184500).pqr Some song or other (svd@20120716-190723).pqr etc I experimented with the monitor delay, and found (on a modern PC) when not using a filename pattern that matched huge numbers of files, that there was no performance hit at all whether I looked at the files every second or two or a good deal less often. I made the script pop-up a message box though when it had successfully made a copy, and got into the habit of waiting for that confirmation every time I'd just saved a file. Rather than writing the script, what took longest to do was getting used to remembering to save the file(s) I was working on so often. I used to keep detailed notes about I was doing to the musical score, as well, and stored the incrementally changing backup filenames in the notes so it was easy to go back to previous points. Not only was this useful for undoing my mistakes, it proved useful for finding bugs in the typesetter AND being able to send the author of that test files and 'what to do to recreate the problem' notes. It was quite often a day or two after I made some change to a file that I found repercussions of that change, so notes (to help me find the key files) were really important. The script itself would run until stopped. I controlled that by having each script generate a carefully-named flagfile and as soon as that was deleted the corresponding script would stop. I could have multiple instances of the script running at once, and both the flagfiles and the typesetter (or whatever else) files were kept in folders visible from other machines/userids (all me though). So flagfiles had in them - a representation of the monitored filename pattern - the monitor time interval - the machine name - the userid name - the time the script started - the pid under it was running The pid was there so that when writing and testing the script I could tell which was which in taskmanager, which saw them all as the same thing - an instance of the script language's interpreter being run. The script is written in ooREXX; anyone who wants it can have a copy. I expect somethig similar could be written in loads of other langages, but it's the one I know best. -- Jeremy Nicoll - my opinions are my own.