But what about "normal" operation? E.g. I use "of-system" to declare and assert that the file is loaded through a correct system. Only a special variable works there as there is no condition at all.
Why would a file be loaded through the wrong system? Is it something likely to happen? How often do you write systems with overlapping files?
That said, if that's a concern you have, e.g. while cleaning up a big hairy non-incremental build like the one we used to have for QRes at ITA, instead of a dynamic check with a dynamic variable, why don't you instead try a static analysis of your system files? See asdf/contrib/detect-multiply-used-files.lisp for how to do just that.
Finally, going forward, if you use package-inferred-system, you will be able to easily depend on single files from other systems without introducing bad dependencies that prevent an incremental build.
What edit-file does? It can call external editor, wait while user finishes the editing and then retry operation. But in SLIME and Lispworks my code does just some other thing: asynchronous message is sent to IDE so that file is opened in the IDE. The editing is done in another thread and maybe in anoter process (as with SLIME/EMACS). Debugger with all restarts is still available, so user can choose any restart. When user decides what to do, he can invoke the restart he wants.
It's your responsibility to have the edit-file function either synchronize on some buffer commit (C-x # for emacsclient), or just return immediately, at which point the loop kicks in and you're back at the same menu, but with an editor window opened.
After sending a message a control is returned to handler function. What is the reasonable action of that function? IMO the only reasonable action is to resignal the condition. This is unnecessary blinking, or unnecessary output: user just starting to edit, and resignaling does not supply user with any new useful information.
This is the difference between restart and "debugger command". Restart either fixes the problem or resignals condition (maybe some new one). Debugger command (e.g. "show source" or "eval in frame") does another thing: it just evaluates some code in current context and then returns to the debugger without restarting.
OK, I can see that this is a limit with the restart interface, unless you can somehow integrate the "waiting for the editor to be done" with your debugger's interface.
My extension can be kept separated, but it defines some around method and thus can interfere with other extensions which could also define the same method. This is not very good.
This might still be better than patching the source. And if such conflict DOES occur, it will be time to add a hook for what will *then* be a commonly used extension point.
Also maybe I can use some wrapper function to asdf::oos instead of patching asdf, but it will not work in the cases where load-system is called implicitly, e.g. from ql:quickload.
oos is a deprecated API, and not one to define wrappers for. Maybe you meant operate.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org As the Chinese say, 1001 words is worth more than a picture. — John McCarthy