Re: librecad
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.
Reply to: