
So I was recently contemplating my xmonad.hs (http://haskell.org/haskellwiki/Xmonad/Config_archive/Gwern's_Config.hs) and wondering whether my XMonad.Actions.Search and other extensions were yet in their ideal form, and it occurred to me: why do I have to keep writing "firefox"? I even have a shortcut defined, 'ff', which I use at least 8 times. Why am I constantly supplying Firefox as a parameter? Well, the answer is that those functions *need* a browser to use, they can't get away with getting it from somewhere else. There is no somewhere else, as there is no POSIX standard way of letting a user define a preferred browser (yes, I know about Debian's x-www-browser stuff, but that's Debian, and I know about environmental variables, but I don't think there's any standard $BROWSER like there is $HOME or $EDITOR). But of course, I'm not writing "urxvt" all over the place. So why not adopt the same solution? Add another slot, 'browser = "firefox"', and a keybinding. Two straight-forward lines in the core. I'm aware you can make arguments against this, but I don't think any apply to a browser field more than they apply to a terminal field. Firefox might not be installed; well, neither might XTerm - X.org is not always installed with all the trimmings, my Gentoo system certainly didn't. Users might not want to use it at all; many people don't use terminals either, as they prefer GUIs. Maybe users would prefer Konqueror; sure, but that's why you let it be changed easily - or do most people truly prefer that ugly antique Xterm? Perhaps this problem can be obviated with some sort of generic extension state? Perhaps, but I don't see any clear definition of what this change would be, and I don't see any code or even solid proposals. A bird in the hand... Would this be useful? I think so. If you search on the Haskell wiki for the string ""firefox"", you see a number of config hits besides mine, many instances that would be helped by browser in the config (eg http://haskell.org/haskellwiki/Xmonad/Config_archive/Wfarr's_xmonad.hs; note the 'myBrowser' definition). Would it be used by XMC? I think so. The terminal field is already being used by XMonad/Actions/Commands.hs and XMonad/Util/Run.hs, despite the relative reconditeness of the technique. -- gwern edition LLNL embassy aster SDIS Information ISN gun Mena ID

gwern0@gmail.com writes:
So I was recently contemplating my xmonad.hs (http://haskell.org/haskellwiki/Xmonad/Config_archive/Gwern's_Config.hs) and wondering whether my XMonad.Actions.Search and other extensions were yet in their ideal form, and it occurred to me: why do I have to keep writing "firefox"? I even have a shortcut defined, 'ff', which I use at least 8 times.
Why am I constantly supplying Firefox as a parameter? Well, the answer is that those functions *need* a browser to use, they can't get away with getting it from somewhere else. There is no somewhere else, as there is no POSIX standard way of letting a user define a preferred browser (yes, I know about Debian's x-www-browser stuff, but that's Debian, and I know about environmental variables, but I don't think there's any standard $BROWSER like there is $HOME or $EDITOR).
Not from lack of trying, http://catb.org/~esr/BROWSER/. [...]

On Sat, Mar 29, 2008 at 11:45:33PM -0400, gwern0@gmail.com wrote:
Why am I constantly supplying Firefox as a parameter? Well, the answer is that those functions *need* a browser to use, they can't get away with getting it from somewhere else. There is no somewhere else, as there is no POSIX standard way of letting a user define a preferred browser (yes, I know about Debian's x-www-browser stuff, but that's Debian, and I know about environmental variables, but I don't think there's any standard $BROWSER like there is $HOME or $EDITOR).
Why not just use BROWSER even though it isn't commonly defined? Just define a getBrowser = getEnv "BROWSER" `catch` \_ -> return "firefox" and it's still just one line (well, plus an import) to define a default browser in xmonad.hs by calling setEnv in the startupHook (or in main before calling xmonad). And lo, users are now also able to define their browser preferences in a non-xmonad-specific location! I don't like the idea of cluttering up XConfig with this sort of thing. I'd rather see the terminal pref removed (it seems silly for all the same reasons) than another pref (that's only used in contrib) added to the core of xmonad. If you prefer, we could alternately support XMONAD_BROWSER. Note that putting the browser in the environment would also make it immediately runtime-configurable (well, with a few lines of code in contrib). -- David Roundy Department of Physics Oregon State University

* David Roundy
If you prefer, we could alternately support XMONAD_BROWSER. Note that putting the browser in the environment would also make it immediately runtime-configurable (well, with a few lines of code in contrib).
How do you see it? -- Roman I. Cheplyaka (aka Feuerbach @ IRC)

On Mon, Mar 31, 2008 at 06:21:35PM +0300, Roman Cheplyaka wrote:
* David Roundy
[2008-03-31 07:58:52-0700] If you prefer, we could alternately support XMONAD_BROWSER. Note that putting the browser in the environment would also make it immediately runtime-configurable (well, with a few lines of code in contrib).
How do you see it?
I'm not sure what you're asking. You'd just start a terminal and then run echo $BROWSER to see what the value is. -- David Roundy Department of Physics Oregon State University

* David Roundy
On Mon, Mar 31, 2008 at 06:21:35PM +0300, Roman Cheplyaka wrote:
* David Roundy
[2008-03-31 07:58:52-0700] If you prefer, we could alternately support XMONAD_BROWSER. Note that putting the browser in the environment would also make it immediately runtime-configurable (well, with a few lines of code in contrib).
How do you see it?
I'm not sure what you're asking. You'd just start a terminal and then run echo $BROWSER to see what the value is.
Sorry, I was in hurry. I mean, how do you see runtime configuration of some environment variable, like BROWSER? If xmonad is up and running, I see no way to change its environment from outside. Even restarting it (mod-q) doesn't seem to allow this. -- Roman I. Cheplyaka (aka Feuerbach @ IRC)

On Mon, Mar 31, 2008 at 07:51:31PM +0300, Roman Cheplyaka wrote:
* David Roundy
[2008-03-31 09:05:33-0700] On Mon, Mar 31, 2008 at 06:21:35PM +0300, Roman Cheplyaka wrote:
* David Roundy
[2008-03-31 07:58:52-0700] If you prefer, we could alternately support XMONAD_BROWSER. Note that putting the browser in the environment would also make it immediately runtime-configurable (well, with a few lines of code in contrib).
How do you see it?
I'm not sure what you're asking. You'd just start a terminal and then run echo $BROWSER to see what the value is.
Sorry, I was in hurry. I mean, how do you see runtime configuration of some environment variable, like BROWSER? If xmonad is up and running, I see no way to change its environment from outside. Even restarting it (mod-q) doesn't seem to allow this.
We'd just define a little prompt module, and then do something like setEnv "BROWSER" "new value" True This would also solve my problem with connecting a new ssh-agent to xmonad (and thus to new terminals started by xmonad). David

* David Roundy
On Mon, Mar 31, 2008 at 07:51:31PM +0300, Roman Cheplyaka wrote:
* David Roundy
[2008-03-31 09:05:33-0700] On Mon, Mar 31, 2008 at 06:21:35PM +0300, Roman Cheplyaka wrote:
* David Roundy
[2008-03-31 07:58:52-0700] If you prefer, we could alternately support XMONAD_BROWSER. Note that putting the browser in the environment would also make it immediately runtime-configurable (well, with a few lines of code in contrib).
How do you see it?
I'm not sure what you're asking. You'd just start a terminal and then run echo $BROWSER to see what the value is.
Sorry, I was in hurry. I mean, how do you see runtime configuration of some environment variable, like BROWSER? If xmonad is up and running, I see no way to change its environment from outside. Even restarting it (mod-q) doesn't seem to allow this.
We'd just define a little prompt module, and then do something like
setEnv "BROWSER" "new value" True
This would also solve my problem with connecting a new ssh-agent to xmonad (and thus to new terminals started by xmonad).
Ah, that will work. But if we introduce global configuration variable, it's weird to configure it specially for xmonad. I'd propose you to make symlink somewhere in your $PATH (like $HOME/bin/x-www-browser) which would point to your preferred browser. And this solution would allow truly runtime configuration. -- Roman I. Cheplyaka (aka Feuerbach @ IRC)

On Mon, Mar 31, 2008 at 09:24:42PM +0300, Roman Cheplyaka wrote:
* David Roundy
[2008-03-31 11:12:51-0700] On Mon, Mar 31, 2008 at 07:51:31PM +0300, Roman Cheplyaka wrote:
* David Roundy
[2008-03-31 09:05:33-0700] On Mon, Mar 31, 2008 at 06:21:35PM +0300, Roman Cheplyaka wrote:
* David Roundy
[2008-03-31 07:58:52-0700] If you prefer, we could alternately support XMONAD_BROWSER. Note that putting the browser in the environment would also make it immediately runtime-configurable (well, with a few lines of code in contrib).
How do you see it?
I'm not sure what you're asking. You'd just start a terminal and then run echo $BROWSER to see what the value is.
Sorry, I was in hurry. I mean, how do you see runtime configuration of some environment variable, like BROWSER? If xmonad is up and running, I see no way to change its environment from outside. Even restarting it (mod-q) doesn't seem to allow this.
We'd just define a little prompt module, and then do something like
setEnv "BROWSER" "new value" True
This would also solve my problem with connecting a new ssh-agent to xmonad (and thus to new terminals started by xmonad).
Ah, that will work. But if we introduce global configuration variable, it's weird to configure it specially for xmonad.
I never said you had to introduce a global configuration variable for xmonad, I said you could do so if you wanted.
I'd propose you to make symlink somewhere in your $PATH (like $HOME/bin/x-www-browser) which would point to your preferred browser. And this solution would allow truly runtime configuration.
Now that truly is a global solution, that can't be runtime configured in any sort of flexible way (e.g. if you wanted to use two different browsers on different machines that share a home directory). Much nicer to use environment variables, which are per-process, rather than global variables like symlinks. -- David Roundy Department of Physics Oregon State University

On Mon, Mar 31, 2008 at 11:28:21AM -0700, David Roundy wrote:
On Mon, Mar 31, 2008 at 09:24:42PM +0300, Roman Cheplyaka wrote:
* David Roundy
[2008-03-31 11:12:51-0700] On Mon, Mar 31, 2008 at 07:51:31PM +0300, Roman Cheplyaka wrote:
* David Roundy
[2008-03-31 09:05:33-0700] On Mon, Mar 31, 2008 at 06:21:35PM +0300, Roman Cheplyaka wrote:
* David Roundy
[2008-03-31 07:58:52-0700] > If you prefer, we could alternately support XMONAD_BROWSER. Note that > putting the browser in the environment would also make it immediately > runtime-configurable (well, with a few lines of code in contrib). How do you see it?
I'm not sure what you're asking. You'd just start a terminal and then run echo $BROWSER to see what the value is.
Sorry, I was in hurry. I mean, how do you see runtime configuration of some environment variable, like BROWSER? If xmonad is up and running, I see no way to change its environment from outside. Even restarting it (mod-q) doesn't seem to allow this.
We'd just define a little prompt module, and then do something like
setEnv "BROWSER" "new value" True
This would also solve my problem with connecting a new ssh-agent to xmonad (and thus to new terminals started by xmonad).
Ah, that will work. But if we introduce global configuration variable, it's weird to configure it specially for xmonad.
I never said you had to introduce a global configuration variable for xmonad, I said you could do so if you wanted.
I'd propose you to make symlink somewhere in your $PATH (like $HOME/bin/x-www-browser) which would point to your preferred browser. And this solution would allow truly runtime configuration.
Now that truly is a global solution, that can't be runtime configured in any sort of flexible way (e.g. if you wanted to use two different browsers on different machines that share a home directory). Much nicer to use environment variables, which are per-process, rather than global variables like symlinks. -- David Roundy Department of Physics Oregon State University
$HOME/bin/x-www-browser could easily be a script that consults an environment variable and executes that.

On 2008.03.31 09:05:33 -0700, David Roundy
On Mon, Mar 31, 2008 at 06:21:35PM +0300, Roman Cheplyaka wrote:
* David Roundy
[2008-03-31 07:58:52-0700] If you prefer, we could alternately support XMONAD_BROWSER. Note that putting the browser in the environment would also make it immediately runtime-configurable (well, with a few lines of code in contrib).
How do you see it?
I'm not sure what you're asking. You'd just start a terminal and then run echo $BROWSER to see what the value is. -- David Roundy
I think he means that if I go and define 'declare -xr BROWSER="firefox"' in my .zshenv, how does XMonad, which is running from .xinitrc which is running from an *old* Zsh instance, ever get to find out about the new environmental variable? -- gwern BVD forces AOL IACIS CCSQ SNT 414 rsta NRC Geraldton

On Mon, Mar 31, 2008 at 01:09:01PM -0400, gwern0@gmail.com wrote:
On 2008.03.31 09:05:33 -0700, David Roundy
scribbled 1.3K characters: On Mon, Mar 31, 2008 at 06:21:35PM +0300, Roman Cheplyaka wrote:
* David Roundy
[2008-03-31 07:58:52-0700] If you prefer, we could alternately support XMONAD_BROWSER. Note that putting the browser in the environment would also make it immediately runtime-configurable (well, with a few lines of code in contrib).
How do you see it?
I'm not sure what you're asking. You'd just start a terminal and then run echo $BROWSER to see what the value is. -- David Roundy
I think he means that if I go and define 'declare -xr BROWSER="firefox"' in my .zshenv, how does XMonad, which is running from .xinitrc which is running from an *old* Zsh instance, ever get to find out about the new environmental variable?
The shell which starts xmonad should read some config file. Stefan

On 2008.03.31 07:58:52 -0700, David Roundy
On Sat, Mar 29, 2008 at 11:45:33PM -0400, gwern0@gmail.com wrote:
Why am I constantly supplying Firefox as a parameter? Well, the answer is that those functions *need* a browser to use, they can't get away with getting it from somewhere else. There is no somewhere else, as there is no POSIX standard way of letting a user define a preferred browser (yes, I know about Debian's x-www-browser stuff, but that's Debian, and I know about environmental variables, but I don't think there's any standard $BROWSER like there is $HOME or $EDITOR).
Why not just use BROWSER even though it isn't commonly defined? Just define a
getBrowser = getEnv "BROWSER" `catch` \_ -> return "firefox"
and it's still just one line (well, plus an import) to define a default browser in xmonad.hs by calling setEnv in the startupHook (or in main before calling xmonad). And lo, users are now also able to define their browser preferences in a non-xmonad-specific location!
Yes, if anything else uses $BROWSER...
I don't like the idea of cluttering up XConfig with this sort of thing. I'd rather see the terminal pref removed (it seems silly for all the same reasons) than another pref (that's only used in contrib) added to the core of xmonad.
Well, that would be a second best. Consistency is a good thing here if we can't agree to my suggestion. I would prefer both browser and terminal; they are both general interfaces, they are both universally used (heck, browser might be even more common - I could see many people not using terminals though they use browsers), and so on. The only other similarly used genres of programs are editors (covered by $EDITOR) and mail clients (are mail programs handled by env vars?). It's an easy two-line change at its most flagrant, and so on.
If you prefer, we could alternately support XMONAD_BROWSER. Note that putting the browser in the environment would also make it immediately runtime-configurable (well, with a few lines of code in contrib). -- David Roundy
See my other email about runtime-configurable; I think what would actually be runtime configurable is my suggestion (make it modifiable in xmonad.hs, not the shell configs). -- gwern BVD forces AOL IACIS CCSQ SNT 414 rsta NRC Geraldton

On Mon, Mar 31, 2008 at 01:16:15PM -0400, gwern0@gmail.com wrote:
I don't like the idea of cluttering up XConfig with this sort of thing. I'd rather see the terminal pref removed (it seems silly for all the same reasons) than another pref (that's only used in contrib) added to the core of xmonad.
Well, that would be a second best. Consistency is a good thing here if we can't agree to my suggestion.
I would prefer both browser and terminal; they are both general interfaces, they are both universally used (heck, browser might be even more common - I could see many people not using terminals though they use browsers), and so on. The only other similarly used genres of programs are editors (covered by $EDITOR) and mail clients (are mail programs handled by env vars?). It's an easy two-line change at its most flagrant, and so on.
Actually, the browser is never be used in my xmonad.hs. In fact, it's only used by a very few contrib extensions.
If you prefer, we could alternately support XMONAD_BROWSER. Note that putting the browser in the environment would also make it immediately runtime-configurable (well, with a few lines of code in contrib).
See my other email about runtime-configurable; I think what would actually be runtime configurable is my suggestion (make it modifiable in xmonad.hs, not the shell configs).
Right, my approach would be configurable either in xmonad.hs or in the shell. -- David Roundy Department of Physics Oregon State University
participants (6)
-
Bruce Stephens
-
David Roundy
-
gwern0@gmail.com
-
Roman Cheplyaka
-
Spencer Janssen
-
Stefan O'Rear