Re: [wmii] Fwd: Re: wmii post from requires approval

From: Salva Peiró <>
Date: Fri, 7 Apr 2006 11:48:36 +0000

On 4/7/06, Steffen Liebergeld <> wrote:
> On Fri, 7 Apr 2006 09:26:15 +0000, "Salva Peiró" <> said:
> > On 4/6/06, <> wrote:
> >> On Thursday 06 April 2006 11:38, Anselm R. Garbe wrote: > If
> >> someone presents a nice idea which works with sh, maybe in >
> >> conjunction with awk, I'm open to do it. Otherwise blame X that >
> >> it needs to grab shortcuts and there is no portable way to get >
> >> keyboard events in any other way.
> >>
> > As talked yesterday on irc, about removing the duplicity of having
> > to write the keybindings in two places (and thus keep them
> > consistent), so as garbeam suggested, i've wrote a wmiirc that greps
> > itself for extracting the list of keybindings to be grabbed, and
> > then write them to /def/keys, and also grouped all the key handling
> > related stuff in a handlekeys function.
> I had some time to think about it yesterday... Actually the best idea
> I had would be to have a seperate file with only a list of keybindings
> and their action. Maybe something like that:
> $MODKEY-Control-c xwrite /view/sel/sel/ctl kill
> $MODKEY-Control-l xwrite /view/sel/sel/ctl sendto next
> ...
> I think that would be quite easy to parse. All fields are seperated by
> whitespaces/tabs (or both) and the first field represents the
> shortcut, whereas all the following fields together represent the
> command.
problem of having an external file is that it'll need formating, that
will have to
be known by anyone that wants to modify/edit wmiirc, and also separes things
that should be grouped and it removes the power and simplicity that
the current approach gives of launching any sequence of commands/using
variables, and control flow instructions provided by sh:
all this was talked on (at 17:00)

> > Now, more than ever, I think a advice/comments regarding this
> > behaviour, it's worth, just because it's not the default way of
> > doing things, and because it can obviously have unwanted side
> > effects, due to grep matching '$MODKEY.*)' that we don't want:
> > <snip> MODKEY=M4 # changed $MODKEY to Mod4 (instead of $MODKEY=Alt)
> > <snip> that matches '$MODKEY=Alt)'
> > <snip> klist=`grep '$MODKEY.*)' $HOME/.wmii-3/wmiirc | sed -n 's/^[
> > ]*//g; s/).*$//; s/$MODKEY/'$MODKEY'/; 2,$p'` <snip> also as the
> > grep command in wmiirc, used to extract the keys matches itself:
> > '$MODKEY.*)', it has to be dropped by sed that discards it's first
> > match.
> > by now i've placed: handlekeys() { # greps wmiirc itself, to extract
> > keybidings to be un/grabbed or reacted # you're adviced to be
> > careful, because putting $MODKEY.*), could trash # /def/keys and
> > result in a apparently strange key reacting behavious at worst. ...
> > }
> > (it's long but necessary, tand now hope that people read their
> > wmiirc :-P)
> It is not bullet proof and will look like a weakness or the result or
> bad design for people new to wmii. Thus I think we should eliminate
> hacks like that.
I know it's not bullet proof, that's why I pointed it out, and well this
was just a suggestion/attempt (maybe will help others to find a "nice idea").

Principle of utility.
There's no experiment that turns out to be a total defeat,
at least it serves as counterexample.

gualteri (at)
Received on Fri Apr 07 2006 - 13:48:41 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:01:56 UTC