Platform-specific memory meter design discussion

[Explorer09]

I dislike pull requests #1824 and #1829. Yes, my own PR included as I regret suggesting changes in that current form.

The two requests were about reworking htop's memory meter code to accommodate different memory categories (or items) that could be reported by different operating systems (Linux, FreeBSD, Darwin, etc.).

When I reviewed and debated with Nathan (@natoscott) and Pierre-Marie (@PierreMarieBaty), I realize it would be better to discuss and clarify what are the real problems first before trying to come up with "solutions" that actually solve nothing or bring regressions along the way. Hence this discussion thread.

In other words, I wish we "go back to the drawing board" on the new memory meter design.

The problem

1. Different operating systems report different categories of memory usage, and htop's memory categorization, which is primarily targeted for Linux memory, is a poor fit for other operating systems (including FreeBSD and Darwin).
2. There are reasons that users expect different memory categories to be reported for different OSes in htop. There is no single format for reporting memory use that "fits all".
3. The requirement is not just about adding extra memory categories to the MemoryMeter, but there should be custom label as well as custom order of memory categories/items. The new code thus need such flexibility in OS customization. (I apologize on missing this third point before. Thus in #1824 I argued with Nathan and Pierre-Marie in a wrong direction.)

Implied in point no. 3 is that we should no longer denote unsupported memory items with the value NaN, as that causes a skip in character assignment in monochrome display of htop's memory meter (it can create user confusion).

The constraints

htop is a cross-platform app (for process monitoring), and htop's memory meter has a (stacked) bar and graph drawing that's unlike the OS's native top app. These two main reasons combined cause the following constraints:

• (C1) For documentation reasons, and for the consistency of memory coloring across OSes, memory categories that function similarly should be assigned with the same or similar color (e.g. buffer memory always colored blue 🟦, and cache memory always brown 🟫; the potentially new "wired" memory category should also be colored the same across OSes).
• (C2) The memory categories plotted onto the bar or graph must not overlap, and the plotted memory items plus the "free" memory must sum to 100%. (For this reason, the "available" memory category in Linux is never plotted as it overlaps with others.)
• (C3) Users might choose to display only memory categories that are considered "used" (i.e. not reclaimable), and if that happens, all reclaimable memory categories shall be hidden. To avoid major disruptions in bar and graph drawing between two modes, all unreclaimable memory categories should display before reclaimable memory categories. (I don't think there are good exceptions to this constraint.)
• (C4) Memory categories that are never plotted (e.g. "available" memory in Linux) may be displayed in text meter mode after the unreclaimable and reclaimable memory categories. These do not need color assignments. While there is no prohibition of placing unplotted memory categories before plotted ones. Such use should be rare and there should be a good reason for this exception.
• (C5) No more than 8 items can be plotted onto the bar display. (This current limit is due To the BarMeterMode_characters definition in Meter.c; it's unwise to plot more than 7 items due to the limited set of ANSI color codes even though 7 is not a hard limit here.)

The above are the problem and the necessary constraints I can think of. I don't think the solutions presented by Nathan, Pierre-Marie and even me fit all the requirements above. Thus it's better to re-think and discuss another solution.