[dwm] dmenu navigation with a lot of items.

Hi,

I love dmenu, but one thing has been bothering me for a while: lists
with a lot of items are hard to navigate. With a short list, you can
just browse through it with left/right; with a long list you can use
the filter to speed up navigation.
This is only true however when you already know what you're looking
for: typing 'fire' to quickly jump to firefox is only useful if you
already know that that's what you want _and_ that it's in the list. If
you are faced with a long list, in which you don't know exactly what's
in it, typing in a filter isn't really going to help, and scrolling
all the way through the list with --> is a big pita.
So from this pov, "It manages huge amounts (up to 10.000 and more) of
user defined menu items efficiently" (from the manpage) is only partly
true.
In order to solve this, I believe some shortcuts to make bigger jumps
in the menu are needed.
Attached to this mail is a patch that uses PageUp/PageDown for jumping
back/forward a full 'page', and Home/End to jump to the first/last
item in the list. The patch also updates the manpage accordingly.

Have fun,
Greetings, Sander.

@arg: I'd like to see this go mainstream; if you agree on that, I
suggest to resort the keys in kpress(), they are a bit messy now (I
didn't resort them in this patch to keep the patch more readable). And
by the way: the reason I implemented the XK_End behavior this way is
because it leaves the 'pages' intact. A simple
    while(sel->right)
        curr = sel = sel->right;
    calcoffsets();
Would probably do a similar job with slightly less overhead, but it
would change the beginnings and ends of pages. The way it is now,
pressing End will lead to the exact same result as keeping PageDown
(or -->) down for a while, which the above code would not do (in most
cases). Since that keeps things more predictable, I think it should be
the way it is in my patch; besides, I checked the speed on my Pentium
2 (400 mHz), with a list of 10.000 items, and jumping from the start
to the end isn't noticably slower than jumping from the end to the
start (a _much_ cheaper operation) anyway.