I often have many windows open (mostly with pdf files I need to read), and
try to come up with a tool that lets me find and focus a window easily. I
now simply list all windows with xwininfo and feed that to dmenu. But the
list is full of invisible/dummy windows I don't care about. I clean the
list
Just a comment on your method rather than your problem, calling ''grep''
that many times through that many pipes is fairly expensive and should be
avoided, since it has to create each new process and pass the same data
through every single one. You'd be better using awk and a single pipe.
Chris
O
Yes, my solution is very ad hoc, I'm sure it can be improved in many ways.
But I'm looking for something that avoids the problem to begin with.
On Tue, Feb 12, 2013 at 17:39:30 +0800, Chris Down wrote:
> Just a comment on your method rather than your problem, calling ''grep''
> that many times thr
You might consider using lsw (http://tools.suckless.org/lsw).
-- Michal.
On Tue, Feb 12, 2013 at 11:07:52 +0100, Michał Kazior wrote:
> You might consider using lsw (http://tools.suckless.org/lsw).
Excellent! I think I tried it earlier, but it did not list the window id's
back then. Now it does the job perfectly, thanks!
On Tue, Feb 12, 2013 at 10:39 AM, Chris Down wrote:
> Just a comment on your method rather than your problem, calling ''grep''
> that many times through that many pipes is fairly expensive and should be
> avoided, since it has to create each new process and pass the same data
> through every singl
Yes, you can string a huge bunch of stuff in one grep invocation, which is
great until you discover you want to do other stuff down the line.
Considering he's already doing rudimentary filtering through in *addition*
to sed calls, awk is more generalisable choice to the problem set.
Chris
On 12 F
What I've been doing for a bit is using a modified version of lsw + xdotool:
~/bin $ cat dwm-xdo-focus
#!/bin/sh
TMPFILE=$HOME/.tmp/dwm-lastwindow
xdotool getwindowfocus > $TMPFILE
xdotool windowactivate $1
diff -r e86225980f5d lsw.c
--- a/lsw.c Sat Jun 18 18:47:03 2011 +0100
+++ b/lsw.c
On 2013-02-12, at 13:22, Chris Down wrote:
> Considering he's already doing rudimentary filtering through in *addition*
> to sed calls, awk is more generalisable choice to the problem set.
Alternatively, you could say that sed is the more generalisable choice since
grep is pretty much a subset of
On Sun, Feb 10, 2013 at 03:29:31PM +0100, Christoph Lohmann wrote:
> Greetings,
>
> here is a patch against latest dvtm git which makes it having the same
> config.def.h behaviour as known from other suckless projects.
Thanks, applied.
> This will remove the config.h from the repository and repl
you don't like the little watch?
On Tue, Feb 12, 2013 at 12:39 AM, Christoph Lohmann <2...@r-36.net> wrote:
> Looking at the patch already gives me nightmares of the past when I was
> using this Windows stuff where the changing of this cursor indicated
> that some amateur programmer did
[2013-02-12 14:27] Truls Becken
> On 2013-02-12, at 13:22, Chris Down wrote:
>
> > Considering he's already doing rudimentary filtering through in *addition*
> > to sed calls, awk is more generalisable choice to the problem set.
>
> Alternatively, you could say that sed is the more generalisable
On Tue, Feb 12, 2013 at 10:36:27AM +0100, Thomas Dean wrote:
> all the unwanted windows in the list. See the attached scripts. Does anyone
> know a solution for this? Is there an existing tool that lists all
> "visible" windows along with their id?
>
the ids of visible windows is stored in the _
Quoth Carlos Torres:
> you don't like the little watch?
Christoph is right, the weird different cursor paradigm is not nice
at all. Let the title bar hold status, not the pointer.
Quoth Jens Nyberg:
> I think removing the loading indicator (progress bar) at the bottom
> could be a good idea.
Excellent idea. Agreed.
On Tue, Feb 12, 2013 at 10:45 AM, Nick wrote:
> Let the title bar hold status, not the pointer.
Fine. Die cursor die!
* markus schnalke 2013-02-12 16:39
> The following is NOT portable:
>
> > sed -E 's/\s\+// ; /"(vim|surf):"/d'
>
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html
>
> If you want sed with Extended Regular Expressions, take awk. :-)
For the particular case of emulating these m
On Tue, Feb 12, 2013 at 16:40:55 +0100, Andreas Amann wrote:
> the ids of visible windows is stored in the _NET_CLIENT_LIST property of the
> root window and can be accessed with "xprop -root _NET_CLIENT_LIST"
>
> The followning script lets you select one with dmenu and then focus it:
Thank you f
I've created a patch that implements what we have talked about.
I'm still very unsure about what characters we should use and how the
window title text should be formatted so if anyone has a better idea
please let me know or just make the changes before pushing it.
// Jens (jfu on irc)
0001-Rem
Disregard my previous patch. I just remember that I forgot one case
(when not using SSL).
I think this patch is more correct.
// Jens
2013/2/12 Jens Nyberg :
> I've created a patch that implements what we have talked about.
>
> I'm still very unsure about what characters we should use and how th
Greetings.
On Tue, 12 Feb 2013 21:12:03 +0100 Jens Nyberg wrote:
> I've created a patch that implements what we have talked about.
>
> I'm still very unsure about what characters we should use and how the
> window title text should be formatted so if anyone has a better idea
> please let me know
People wrote:
> grep? awk? sed?
Or you can just use the simplest tool for the job now, grep, and if your
needs change some day, you can use a different tool. OMFG I had to switch
to a different tool the sky is falling the sky is falling. No seriously.
markus schnalke wrote:
> I disagree because grep (with -E or as egrep) does support Extended
> Regular Expressions, which sed does not.
if you want fancy regular expressions, just use perl (troll ducks for cover!)
;)
On Mon, Nov 26, 2012 at 11:25:18AM +0100, Christoph Lohmann wrote:
> I am proposing a migration of all mercurial to git repositories.
I've been working with git lately, trying to do some unusual things,
and I need to say this is one of the least suckless pieces of software
I've ever worked with.
> I disagree because grep (with -E or as egrep) does support Extended
> Regular Expressions, which sed does not.
>
sed -r
Care to give some examples of where git sucks more than hg? I've found it
particularly un-sucky, but non-intuitive in places.
On 13 February 2013 07:28, Sam Watkins wrote:
> On Mon, Nov 26, 2012 at 11:25:18AM +0100, Christoph Lohmann wrote:
> > I am proposing a migration of all mercurial to git
-r is not POSIX.
On 13 February 2013 07:29, Nimrod Omer wrote:
>
> > I disagree because grep (with -E or as egrep) does support Extended
> > Regular Expressions, which sed does not.
> >
>
> sed -r
>
(perhaps I should expand since that's perhaps a "no shit" considering it's
ERE)
sed has no ERE in POSIX, and kinda lacks for certain functionality when
you're looking for portability. In general awk doesn't suffer the same
caveat. But I'm an awk fanboy, so I would say that.
Chris
On 13 February
2013/2/13 Chris Down :
> Care to give some examples of where git sucks more than hg? I've found it
> particularly un-sucky, but non-intuitive in places.
>
People who can not grasp git thinks it's bad, it's that simple. Irony
of it all is that it is actually a very simple design that is both
fast,
My mother was actually not pleased when she used git. She liked the idea of
a suck less frontend though.
Wolfgang
On Feb 12, 2013 6:57 PM, "Jens Nyberg" wrote:
> 2013/2/13 Chris Down :
> > Care to give some examples of where git sucks more than hg? I've found it
> > particularly un-sucky, but no
To be fair I think there are a multitude of ways in which git is less sucky
than hg:
- multiple binaries
- significantly more modular design framework
- doesn't assume the user is an idiot (which is probably why so many people
have problems with it)
- there are plenty of things of *daily use* in g
On 02/12/2013 07:14, Carlos Torres wrote:
because a line accross the bottom of the screen indicates more than
the change of a cursor?
that tells you missed the point of the line. because just as well the
line can get stuck at 10% say and never progress until suddenly its
done.
Yeah, that's a
Hello,
Attached you'll find a simple patch that makes the DOWNLOAD macro
use the cookiefile variable.
--Carlos
fix_DOWNLOAD_macro.patch
Description: Binary data
33 matches
Mail list logo
