GitLab

With the CLAMP macro replacing the combination of MIN and MAX, we will
have at least two advantages:
1. It's more obvious semantically.
2. There are no more mixes of confusing uses like MIN(MAX(a,b),c) and
   MAX(MIN(a,b),c) and MIN(a,MAX(b,c)) appearing everywhere. We unify
   the 'clamping' with a single macro.
Note that the behavior of this CLAMP macro is different from
the combination `MAX(low,MIN(x,high))`.
* This CLAMP macro expands to two comparisons instead of three from
  MAX and MIN combination. In theory, this makes the code slightly
  smaller, in case that (low) or (high) or both are computed at
  runtime, so that compilers cannot optimize them. (The third
  comparison will matter if (low)>(high); see below.)
* CLAMP has a side effect, that if (low)>(high) it will produce weird
  results. Unlike MIN & MAX which will force either (low) or (high) to
  win. No assertion of ((low)<=(high)) is done in this macro, for now.

This CLAMP macro is implemented like described in glib
<http://developer.gnome.org/glib/stable/glib-Standard-Macros.html>
and does not handle weird uses like CLAMP(a++, low++, high--) .

Could no longer reproduce #244 after these fixes.

Closes PR #111.

Closes #241.

Fixes #174.

Conflicts:
	Panel.c

Fixes #174.

Made the logic more modular, hopefully easier to follow,
and removed repeated code.
Plus, some optimization in RichString code.

(thanks to Moritz Barsnick)

Fix subtree hiding
Fix reading of CPU values in hidden threads
Fix hiding of zombie processes as kernel threads
Remove "debug proc" code
Code cleanup in processElements

flag, which requires libncursesw.
Thanks to Sergej Pupykin!

accurate description. It is still available in
split time, now called detailed CPU time.
(thanks to Samuel Thibault for the report)

Avoid unnecessary operations when processing entries on ProcessList.