SETUNDO - user comments would be helpful.

George,

I had two reasons for the prior comments that prompted this Outreach thread. The first was to suggest a change to the architecture that would hopefully make it more resilient and less vulnerable to bugs. The second was when I thought about my own use of UNDO in profiles.

I must confess, I have no idea what all the UNDO levels are in every profile I have. I'd have to painstakingly go open up every profile and check each one of them. To be honest, I don't think much about undo levels. All I want to do is UNDO when I need to. But, since I am the same person, with the same likelihood of making typing errors - regardless of what file type I happen to be editing at any given moment - the ability to fine-tune the UNDO level based on file type is not a big seller for me. I basically want the max for every file, all the time.

But, I could do that manually, if I really wanted to. It might take me 20 minutes to open up and edit every one of them, but it's not a big deal. So I can fix that myself without any code impact on your part.

What I really want more than altering the UNDO level is a change to the overall UNDO structure and architecture. It has always seemed a very high overhead feature. So, if I have one file with 25 undo levels, SPFLite is going to open up 4 x 25 = 100 temporary undo files. Wow, that's a lot. Then, if every profile has 25 undo levels, it's 100 temp files for every open file. A high overhead, but if you want insurance against editing errors, all insurance comes at a cost.

Now, I know you can't rewrite your whole code, even if doing so had advantages, because it's bridge too far. It's just too hard. But, SPFLite doesn't live in a vacuum. We all have many editing choices. For example, when I really need to edit free-form documentation text, I use NotePad++ which I am quite spoiled by. It's undo feature is always active, needs no special user intervention to enable, and essentially has unlimited levels. And, you can undo/redo down to the keystroke level. They allow that because they in turn use an open-source edit engine and add the UI on top of it themselves.

I am not unreasonable, and I don't expect that from you. But what I find frustrating is, even when UNDO is enabled, it happens too often that I try to UNDO something and can't. Instead, I get that message about 'no more undo levels'. There is a very specific "UNDO boundary" built into the process, and if you catch it at the wrong time where you change something that is not within some kind of "editing interval", you can't undo it. For me, I have to be very careful what I do, because otherwise I can get in that "UNDO limbo" where I change something and can't undo it, and then my only recourse is a CANCEL.

I don't want to rag on you, because I know you've just been through a very long and difficult debugging session on UNDO, and now that it seems to work, I don't want you to think I am anything but appreciative about all the work you've done. But to be honest, UNDO has never really worked what I would call "well". It sort of works, and if you work within its limitations, it is certainly useful. But there have always been problems with it. I just wish it could be done differently.

R

I have about 15 different profiles, each of them has UNDOLEVELS=10. Therefore: "Don't care"

Jo

Robert: I noticed that as well, I'll fix it.

George

The only trick would be managing the transition. Maybe you could keep the existing UI, but any time a profile is added or changed, you would check to see if it was higher than the current global level, and if so, you'd change the global level to reflect the new maximum level.