top: swat bug impacting 'idle' mode & 'user' filtering

When Other filtering was introduced the nature of what
constituted a displayed row changed. No longer would a
task_show() call guarantee that another line is shown.
Rather, a non-empty string must have also been tested.

Unfortunately, when any task window was being filtered
for 'idle' mode or a particular 'user', the proc index
was incremented twice due to the perils of copy/paste.
Combining such an index increment with the new test of
task_show results works fine if filtering is inactive.

This was a particularly insidious bug which meant that
an adjacent task would be skipped whenever the current
task met 'idle' and/or 'user' filter criteria, and was
not otherwise excluded due to 'Other' filter criteria.

And, since it was the very next task that was ignored,
the bug was very susceptible to a window's sort order.
This could be illustrated when filtering on some user,
while sorting on PID. Then, toggling Forest View could
make otherwise unseen tasks appear and then disappear.

User workarounds are possible via interactive commands
trading the 'i' and 'u'/'U' provisions for the 'o'/'O'
other filtering capability thus avoiding an extra i++.
But that is certainly less than ideal and doesn't help
the 3.3.7 and 3.3.8 distorted command line provisions.

( this little buggie may end up costing me my pocket )
( protector, my coding badge & maybe even my cubicle )

Reference(s):
http://www.freelists.org/post/procps/Idle-elides-nonidle-processes
. bug originated with 'Other' filtering
commit 5edc6fb317

Signed-off-by: Jim Warner <james.warner@comcast.net>

top/top.c

@@ -5399,7 +5399,7 @@ static int window_show (WIN_t *q, int wmax) {
       while (i < Frame_maxtask && lwin < wmax) {
          if ((CHKw(q, Show_IDLEPS) || isBUSY(q->ppt[i]))
          && user_matched(q, q->ppt[i])
-         && *task_show(q, q->ppt[i++]))
+         && *task_show(q, q->ppt[i]))
             ++lwin;
          ++i;
       }