This is kind of bonkers but bear with me. For a few editors, and some circumstances within those editors, changes to the view of my files (not the files themselves) goes into the editor's undo/redo stack. This is nice because if I make some view change nested deep in some menus that turns my editor into unusable gobbledygook, I can undo it. It's also not nice because sometimes I wanted that view change, and I want to undo a change to a file without undoing the view change. In fact, sometimes I want to perform an undo to a file and see that undo happening from my now-modified view.

What would be cool is if view changes (changing options, entering/exiting find/replace, moving between editor panels, heck even things like scrolling and moving the text cursor if you're feeling crazy) had their own undo/redo stack, totally separate from the undo/redo stack of a particular file. You could make it so that ctrl-shift-z walks only through changes to a file, ctrl-alt-z walks only through changes in the view, and ctrl-z does whatever is most is intuitive (eg undoing and moving to the site of the undo). I've thought for a while this would be nice feature for an editor to have, and maybe 4coder is early enough in development so that this wouldn't be a nightmare to implement? Lmk what you think.

That's not a bad thought. I've actually got big plans for the undo system in 4coder, I hadn't thought of something like this but it's not 100% unthinkable. A potential issue is that eventually I'm not sure how many settings and menus will be hard baked into 4coder, but even for customizable GUIs I may be able to find a way to make a general purpose undo stack that the customization author can use or not.