gwern0@gmail.com wrote:

On 2008.04.01 07:13:17 -0600, Justin Bogner scribbled 1.8K characters:

...

gwern0-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:

...

Mon Mar 31 21:34:47 EDT 2008 gwern0-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org * Shell.hs: +getBrowser, getEditor, helper function The helper function asks the shell for the value of a variable, else returns the second argument. getBrowser and getEditor obviously specialize it for two particular possibly queries Mon Mar 31 21:39:47 EDT 2008 gwern0-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org * Search.hs: remove an argument from selectSearch and promptSearch The new getBrowser function allows us to mv the old selectSearch and promptSearch aside as too-general functions, and replace them with new versions, which employ getBrowser to supply one more argument. This allows us to replace the tedious 'selectSearch google "firefox"; selectSearch yahoo "firefox"...' with shorter 'selectSearch google' and so on. One less argument. Also, update the docs. Mon Mar 31 21:50:49 EDT 2008 gwern0-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org * RunOrRaise.hs: FF 3 doesn't use the "Firefox-bin" classname Mon Mar 31 22:17:40 EDT 2008 gwern0-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org * WindowGo.hs: +raiseBrowser, raiseEditor Specialize runOrRaise in the same way as with Actions.Search, for one's browser and one's editors. Mon Mar 31 22:20:12 EDT 2008 gwern0-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org * forgot a haddock for getEditor in Shell.hs Mon Mar 31 22:31:30 EDT 2008 gwern0-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org * improve WindowGo.hs Haddock formatting

As for the changes to RunOrRaise, firefox 3 actually works without resorting to classname (the pid thing works). I was just wary about changing it since firefox 3's not out yet, and that doesn't work with older firefoxes _____ Justin Bogner

I dunno what the pid thing is; classes are kind of fragile, so I'm interested in a better way (though I believe that by title and class is how all the other wms implement run-or-raise).

But are you sure my change doesn't work with older Firefoxes? From reading the docs, I had understand that 'className =? "Firefox-bin" <||> className =? "Firefox"' should work, as it will match any windows that use either the new Firefox 3 classname of 'Firefox', or an older firefox using 'Firefox-bin' as a class.

(Admittedly, I did not test the or'ing with both a new and old Firefox, but I used to use the first matcher and it worked fine, and I use the new matcher now, and it works fine; so the disjunction should follow AFAIK.)

-- gwern explosion dog SASP PPP Sears passwd fulminate Choe WINGS Golani

Your solution works for both, sorry to confuse. The RunOrRaise prompt actually has a trick in it which tries to find a process based on its pid (it gets the pid of the window and running pidof `the app you're trying to run`), and this works for firefox 3, so that version of the function isn't actually needed at all... Any case, it doesn't matter. your patch works fine. _____ Justin Bogner

On 2008.04.03 15:20:22 -0500, Spencer Janssen scribbled 1.8K characters:

I think this $EDITOR business is a bit silly, for several reasons. $EDITOR by default is set to a terminal based program, like vi or nano. This means that the raiseEditor function, for many users (essentially everyone that doesn't use emacs), is totally useless. What is the advantage of raiseEditor over runOrRaise "emacs"?

Also, I'm morally opposed to the default of "emacs" in getEditor, but we can leave religion out of this.

Cheers, Spencer Janssen

Well, my idea of adding another slot in the default config (and a useful binding) was rejected. The state has to live *somewhere*, and Roundy's idea was the only viable one mooted. It's also the more Unixy solution of configuring the default editor. Hence using $EDITOR. Now, I suspect this could be improved. For example, I was unsure whether to default to 'emacs' or 'emacsclient'; the problem with the latter is that sometimes it's invisible, when the buffer pops up in some emacs far far away or maybe pretty inaccessible (a forgotten Emacs in a screen session?), and I was also unsure whether emacsclient would do the right thing if no Emacs was running. Another suggestion I saw is to use VISUAL, since apparently that's also used sometimes (but surely even less than EDITOR - even my extensive config files just define VISUAL=$EDITOR). So I'll send a patch for those two changes. But why have this in general? Because it was a repeated pattern in my config file; because it could be useful to others; because it's an interesting extension of RunOrRaise. And so on. If you don't see the appeal, I'm not sure I can explain it better than that. -- gwern initia POCSAG Corporate SARD PARASAR Chicago I special ^ MKDELTA

allbery:

On Apr 3, 2008, at 17:16 , gwern0@gmail.com wrote:

...

Another suggestion I saw is to use VISUAL, since apparently that's also used sometimes (but surely even less than EDITOR - even my extensive config files just define VISUAL=$EDITOR).

I'm going to be deploying xmonad on Solaris 9. The standard on Solaris is that $VISUAL is an editor like emacs or vi and if not set falls back to $EDITOR, which defaults to /bin/ed. This means Solaris users generally ignore $EDITOR and set $VISUAL.

A link to a binary of xmonad 0.7 for Solaris 9 would be really useful! xmonad's finally getting a lot of packages appearing. E.g. on Debian, there's now bundles for alpha, amd64, i386, ia64, mips, mipsel and sparc :) -- Don

On Thu, Apr 03, 2008 at 05:16:01PM -0400, gwern0@gmail.com wrote:

On 2008.04.03 15:20:22 -0500, Spencer Janssen scribbled 1.8K characters:

...

I think this $EDITOR business is a bit silly, for several reasons. $EDITOR by default is set to a terminal based program, like vi or nano. This means that the raiseEditor function, for many users (essentially everyone that doesn't use emacs), is totally useless. What is the advantage of raiseEditor over runOrRaise "emacs"?

Also, I'm morally opposed to the default of "emacs" in getEditor, but we can leave religion out of this.

Cheers, Spencer Janssen

Well, my idea of adding another slot in the default config (and a useful binding) was rejected.

Your previous proposal was to add browser to the configuration, which we decided against. I'm perfectly okay with the $BROWSER use in the search module and other places.

The state has to live *somewhere*, and Roundy's idea was the only viable one mooted. It's also the more Unixy solution of configuring the default editor. Hence using $EDITOR.

Now, I suspect this could be improved. For example, I was unsure whether to default to 'emacs' or 'emacsclient'; the problem with the latter is that sometimes it's invisible, when the buffer pops up in some emacs far far away or maybe pretty inaccessible (a forgotten Emacs in a screen session?), and I was also unsure whether emacsclient would do the right thing if no Emacs was running.

Another suggestion I saw is to use VISUAL, since apparently that's also used sometimes (but surely even less than EDITOR - even my extensive config files just define VISUAL=$EDITOR).

So I'll send a patch for those two changes.

The problem with $EDITOR is that you're, more than likely, using it wrong. What happens when $EDITOR is set to vi, as it is on most systems by default? The raiseEditor binding will simply not work, because vi is a terminal application and not an X11 application. raiseEditor is pretending to be more general than it really is -- it will only work for emacs users (or for the other rare cases where an X11 editor is set). Because of this, I'm in favor of removing the editor bindings.

But why have this in general? Because it was a repeated pattern in my config file; because it could be useful to others; because it's an interesting extension of RunOrRaise. And so on. If you don't see the appeal, I'm not sure I can explain it better than that.

Do you really use the editor in multiple places in your config? getEditor is only used by raiseEditor in contrib, which isn't flexible enough to have more than one keybinding to it anyway. Cheers, Spencer Janssen