--- dmenu-4.1.1/dmenu.1 2010-11-19 22:04:48.000000000 +0100
+++ dmenu-4.1.1/dmenu.1 2010-11-19 22:15:49.000000000 +0100
@@ -10,6 +10,7 @@
.RB [ \-nb " <color>"]
.RB [ \-nf " <color>"]
.RB [ \-p " <prompt>"]
+.RB [ \-s ]
.RB [ \-sb " <color>"]
.RB [ \-sf " <color>"]
.RB [ \-xs ]
@@ -44,6 +45,9 @@
.B \-p <prompt>
defines a prompt to be displayed before the input area.
.TP
+.B \-s
+stable sorting
+.TP
.B \-sb <color>
defines the selected background color (#RGB, #RRGGBB, and color names are supported).
.TP
--- dmenu-4.1.1/dmenu.c 2010-11-19 22:01:22.000000000 +0100
+++ dmenu-4.1.1/dmenu.c 2010-11-19 22:04:48.000000000 +0100
@@ -73,6 +73,7 @@
#include "config.h"
/* variables */
+static Bool stable = False;
static char *maxname = NULL;
static char *prompt = NULL;
static char **tokens = NULL;
@@ -622,6 +623,10 @@
break;
}
}
+ if(stable) {
+ appenditem(i, &lprefix, &prefixend);
+ continue;
+ }
if(append == 1)
appenditem(i, &lexact, &exactend);
else if(append == 2)
@@ -844,11 +849,13 @@
}
else if(!strcmp(argv[i], "-xs"))
xmms = True;
+ else if(!strcmp(argv[i], "-s"))
+ stable = True;
else if(!strcmp(argv[i], "-v"))
eprint("dmenu-"VERSION", © 2006-2010 dmenu engineers, see LICENSE for details\n");
else
eprint("usage: dmenu [-i] [-b] [-e <xid>] [-l <lines>] [-fn <font>] [-nb <color>]\n"
- " [-nf <color>] [-p <prompt>] [-sb <color>] [-sf <color>] [-xs] [-v]\n");
+ " [-nf <color>] [-p <prompt>] [-sb <color>] [-sf <color>] [-xs] [-s] [-v]\n");
if(!setlocale(LC_CTYPE, "") || !XSupportsLocale())
fprintf(stderr, "warning: no locale support\n");
if(!(dpy = XOpenDisplay(NULL)))
edit: seems like this patch is buggy.
For example. when I do:
echo -e "mpc toggle\nncmpcpp" | dmenu -s
and i start typing "ncmpcpp" , the resultset stays the same ('mpc toggle' on top, 'ncmpcpp' below it), when i press enter, dmenu will write 'mpc toggle' instead of 'ncmpcpp'
]]>The good news is, http://tools.suckless.org/dmenu/patches … n_matching applies nicely onto dmenu 4.1.1, and seems to work fine so far.
I really should have looked at the patches section more, it seems to be quite well maintained.
btw 4.2 is now finally released; but the changes are only code cleanups
edit: figured it out. pasting in 4.1 is with mod+p; yeay. 4.2 contains paste code not depending on sselp invoked as c^y.. didn't want to waste too much time porting the xmms patch so i stick to 4.1 for now.
]]>dmenu 4.1.1-4 # included vertical mode, cursor, c^u, c^w, no copypaste, no xmms-like matching
dmenu-xft 4.1.1-4 # looks the same to me (I don't think I care for xft anyway)
dmenu-vertical-xft-4.0-5 # vertical mode, no cursor, no c^u, c^w, no copypaste but xmms-like matching.
you can already guess what I'll ask now...
is there a version that has vertical mode, cursor, c^u, c^w, copypaste, and xmms-like matching?
@Procyon I think you are pretty close right, can you share your complete patched file (and tell us what it's based on) ?
@Scytale: how is fmenu doing? is any particular branch good for me?
edit: this is odd. the online manpage claims you can paste x selection with c^y: http://man.suckless.org/tools/1/dmenu
but this doesn't work for me (with official dmenu 4.1.1-1, which is the latest, maybe it's only in VCS)
Options to echo are not portable.
Well, guess what. We are on the arch forums, discussing working with arch packages. Arch uses bash as default shell, and uses gnu coreutils. The advice given works fine.
]]>bashism.
Can you be any more vague?
I think ninian is right.
dieter@dieter-dellD620-arch ~ /bin/echo "a\nb\nc"
a\nb\nc
dieter@dieter-dellD620-arch ~ /bin/echo -e "a\nb\nc"
a
b
c
What happens when you try this:
echo "a\nb\nc" | dmenu -l 3
Methinks you mean
echo -e "a\nb\nc" | dmenu -l 3
does dmenu from the arch repo support vertical menus, it doesnt work for me.
What happens when you try this:
echo "a\nb\nc" | dmenu -l 3
sed -i -f stable.sed dmenu.c
stable.sed
/\/\* variables/a static Bool stable = False;
/if(append == 1)/i\ if(stable) {\
appenditem(i, &lprefix, &prefixend);\
continue;\
}
/argv\[i\], "-v"/i\ else if(!strcmp(argv[i], "-s"))\
stable = True;
s/\[-v\]/[-s] &/
I posted about this: #46
I think I missed one though, because now I use this code:
if(append == 1) // appenditem(i, &lexact, &exactend); appenditem(i, &lprefix, &prefixend); else if(append == 2) appenditem(i, &lprefix, &prefixend); else if(append == 3) appenditem(i, &lprefix, &prefixend); // appenditem(i, &lsubstr, &substrend);
It does this all the time though, right? And not just in xmms mode.
my mistake. you're right. it does this always. I would love your fix to go into dmenu-vertical-xft (and dmenu-vertical but I don't use that) on AUR.
]]>I just noticed that, when you feed dmenu this:
aa bb cc bb cc
and you use the 'xmms-style' matching, and you type 'bb' it will first show the 2nd entry rather then the first.
for a "lists of artists" this makes sense because the order is usually just alphabetically and the 2nd item matches "bb" "better".
But, for an app launcher where you list apps ordered by frequency of use, you probably want the first entry. this is also how firefox' awesomebar behaves: it will show you all hits where your typed words occur, in the order of it's "input file" ("frecency" as they call it). and it won't care if your input is at the beginning or in the middle of a string.So, can we get such a behavior in dmenu? maybe -xs for xmms-like and -aw for awesomebar-like. other then this difference, i think the behaviors are the same.
I posted about this: #46
I think I missed one though, because now I use this code:
if(append == 1)
// appenditem(i, &lexact, &exactend);
appenditem(i, &lprefix, &prefixend);
else if(append == 2)
appenditem(i, &lprefix, &prefixend);
else if(append == 3)
appenditem(i, &lprefix, &prefixend);
// appenditem(i, &lsubstr, &substrend);
It does this all the time though, right? And not just in xmms mode.
]]>