darcs patch: pass-through-unrecognised-flags
1 patch for repository http://code.haskell.org/xmonad: Sun Aug 18 12:31:19 EST 2013 gopsychonauts@gmail.com * pass-through-unrecognised-flags Changes XMonad's core binary so that it won't reject arbitrary flags passed to the xmonad command, but instead simply passes them on to the user's XMonad binary. This allows for -contrib extensions to add their own command-line flags if desired. This does imply slightly less error-checking, but the flexibility afforded is, I think, worth it.
Hi David, Is there an advantage to passing information this way over using environment variables? Currently this seems to work (System.Environment.getEnvironment): $ ENABLE_FOO=1 xmonad while your patch would allow contrib code to call System.Environment.getArgs to get something out of a very similar command line: $ xmonad --enable-foo=1 -- Adam On Sat, Aug 17, 2013 at 10:32 PM, <gopsychonauts@gmail.com> wrote:
1 patch for repository http://code.haskell.org/xmonad:
Sun Aug 18 12:31:19 EST 2013 gopsychonauts@gmail.com * pass-through-unrecognised-flags
Changes XMonad's core binary so that it won't reject arbitrary flags passed to the xmonad command, but instead simply passes them on to the user's XMonad binary. This allows for -contrib extensions to add their own command-line flags if desired.
This does imply slightly less error-checking, but the flexibility afforded is, I think, worth it.
[pass-through-unrecognised-flags gopsychonauts@gmail.com**20130818023119 Ignore-this: 7f892156a5abb05247014337b70be013
Changes XMonad's core binary so that it won't reject arbitrary flags passed to the xmonad command, but instead simply passes them on to the user's XMonad binary. This allows for -contrib extensions to add their own command-line flags if desired.
This does imply slightly less error-checking, but the flexibility afforded is, I think, worth it.
] hunk ./Main.hs 53 #ifdef TESTING ("--run-tests":_) -> Properties.main #endif - _ -> fail "unrecognized flags" + _ -> launch where shortVersion = ["xmonad", showVersion version] longVersion = [ "compiled by", compilerName, showVersion compilerVersion
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
On Sun, Aug 18, 2013 at 09:58:52PM -0400, adam vogt wrote:
Is there an advantage to passing information this way over using environment variables? Currently this seems to work (System.Environment.getEnvironment):
$ ENABLE_FOO=1 xmonad
while your patch would allow contrib code to call System.Environment.getArgs to get something out of a very similar command line:
$ xmonad --enable-foo=1
Hmm. For "enabling" features, there isn't much of a difference, true. However, my particular use-case for this change is to extend the xmonad binary such that it can do things like this: $ xmonad -c view workspace1 $ xmonad -c nextLayout $ xmonad -c spawnHere firefox (I've already implemented a module, basically an extended version of Hooks.ServerMode, which allows this sort of interaction; I'll probably throw it into a -contrib patch once this is resolved.) I suppose that, from a technical point of view, it would *work* equally well to do this like: $ COMMAND="view workspace1" xmonad $ COMMAND=nextLayout xmonad $ COMMAND="spawnHere firefox" xmonad But I find such an interface rather clunky and less revealing of the fact that the xmonad binary will perform an unusual operation, i.e., not starting XMonad. Allowing for arguments to be passed through enables use of the former interface instead, which I think is a much better interface to expose to this functionality. Thoughts?
Dunno about advantage/disadvantage, but certainly a difference: environment variables will get inherited by children and command-line arguments will not. ~d On 2013-08-18 21:58, adam vogt wrote:
Hi David,
Is there an advantage to passing information this way over using environment variables? Currently this seems to work (System.Environment.getEnvironment):
$ ENABLE_FOO=1 xmonad
while your patch would allow contrib code to call System.Environment.getArgs to get something out of a very similar command line:
$ xmonad --enable-foo=1
-- Adam
On Sat, Aug 17, 2013 at 10:32 PM, <gopsychonauts@gmail.com> wrote:
1 patch for repository http://code.haskell.org/xmonad:
Sun Aug 18 12:31:19 EST 2013 gopsychonauts@gmail.com * pass-through-unrecognised-flags
Changes XMonad's core binary so that it won't reject arbitrary flags passed to the xmonad command, but instead simply passes them on to the user's XMonad binary. This allows for -contrib extensions to add their own command-line flags if desired.
This does imply slightly less error-checking, but the flexibility afforded is, I think, worth it.
[pass-through-unrecognised-flags gopsychonauts@gmail.com**20130818023119 Ignore-this: 7f892156a5abb05247014337b70be013
Changes XMonad's core binary so that it won't reject arbitrary flags passed to the xmonad command, but instead simply passes them on to the user's XMonad binary. This allows for -contrib extensions to add their own command-line flags if desired.
This does imply slightly less error-checking, but the flexibility afforded is, I think, worth it.
] hunk ./Main.hs 53 #ifdef TESTING ("--run-tests":_) -> Properties.main #endif - _ -> fail "unrecognized flags" + _ -> launch where shortVersion = ["xmonad", showVersion version] longVersion = [ "compiled by", compilerName, showVersion compilerVersion
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
participants (4)
-
adam vogt -
Daniel Wagner -
David McLean -
gopsychonauts＠gmail.com