On 2008-04-03 21:49:51 gwern0@gmail.com wrote:
No, it doesn't. I thought about it and:
#You could penalize every user like myself using a sensible editor which can handle the CLI *and* X (shocking) with a bogus terminal, which is silly # You could try doing a runOrRaise on every editor, pause _n_ seconds, and then do a raiseMaybe (term ++ " -e " ++ editor). I don't need to explain why this is bad. # You could somehow try to make spawn smarter - spawn is, so far as I know, dumb. If a program exits immediately because there's no shell to run in because the user is in X, that's all the same to spawn. ## Of course, you'd then need to rewrite the entire RunOrRaise stack and stuff, since spawn isn't threaded through as a modifiable parameter. # You could try something with exceptions. No idea what - the obvious thing would be if spawn could throw exceptions when the program exist. But spawn is hardwired to use doubleFork which is hardwired to return ExitSuccess. ## You want to make spawn throw exceptions so you could just go 'catch (runOrRaise (getEditor)) (spawn "xterm -e " ++ getEditor)'? Good luck making that and updating everything and getting it into the core.
So basically, I don't see any clean solution. If you have an unusual case, just use 'runOrRaise (unusualCase)', or set the environment variables to a script or anything. The primitives are exposed for a reason; 80/20 you know.
Of course, if anyone does know a clean solution, that'd be good. I am not in principle against handling that sort of case well (although perhaps we can agree that hooking into GNOME and KDE configuration databases to discover the default browser and editor would be going too far :).
I think you've just explained why your patch is a bad idea... Much better to let the user set this stuff up so it works. It's not exactly hard. /J