Due to the fact that I first tried my copy paste experiment with cut instead of copy I lost some text (its only test setup), because I was not able to undo the whole text.

So, yes I also vote for a multistep undo function. But maybe this is to much workload in the short run. So why not transfer the working method from a textbased programm to a databased one.

In a textbeased programm I only save to file when I see everthing after the current operation went o.k. otherwise I startup again from loading source.

Not possible when the programm ist database based, unless we work on a temp version of the source database. My proposal would only work for single desktop environment of infoqube.

So when startup with infoqube it will make a temp copy of the source database and only when I press <ctrl>+s the temporaly database will be written back to the source db. No problem with modern fast filesystems.When ending with infoqube will question save or not and delete the temp after coping back (or not).

When startup with an existing temp, maybe after crash, infoqube will offer to proced with the temp (→ do nothing extra) or to start up from source. Then the temp will be deleted.

And the workarround for the workarround is to call infoqube from a batch process, which makes a copy from the database before starting up infoqube. This will be the next step for me.