On 2008.04.03 19:09:42 -0400, "Brandon S. Allbery KF8NH" scribbled 0.9K characters:

On Apr 3, 2008, at 18:57 , Brandon S. Allbery KF8NH wrote:

...

On Apr 3, 2008, at 18:41 , gwern0@gmail.com wrote:

...

Thu Apr 3 18:38:12 EDT 2008 gwern0@gmail.com * Shell.hs: getEditor/Browser changes This implements the discussed changes. getEditor now defaults to testing $VISUAL, then $EDITOR. getBrowser tests additional variables, $X-WWW-BROWSER/$WWW-BROWSER.

rushlight:5001 Z$ export X-WWW-BROWSER=vi export: not an identifier: X-WWW-BROWSER

Also, you haven't addressed the question of editors requiring terminal windows, if I read the patch right. At the price of spawning a useless terminal when an X11-aware editor is specified, you can prefix "xterm -e " to the selected editor (or, perhaps better, use the existing terminal preference).

-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com

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 :). -- gwern Blowpipe of NSLEP world diwn Serbian BBC Indigo ISS-ADP SONANGOL

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