Kang-Che Sung (宋岡哲)

I would suggest you drop `COMMANDLINE_OPTION_DISPLAY_HELP_*` fow two reasons: 1. It gives a false sense that user can configure the variable values to anything they like, and the variable names...

@Lin-Buo-Ren My argument was about unnecessary bloat. It is quite unlikely that your `util_check_function_parameters_quantity()` or `meta_trap_err_print_debugging_info()` or whatever routine will be called by outside (user code), and so why bother...

@Lin-Buo-Ren Then what if I make a function that accepts a variable number of arguments? And to check whether there are a minimum number (instead of exact number) of arguments?...

@Lin-Buo-Ren It might be just me, but I really hate when people replicate a functionality that is provided already in the shell environment, let alone with obscure and long function...

> I think, instead of hacks on top of other hacks, the overall libsensors-to-cpucore mapping should be addressed properly. I believe the libsensors-to-cpu-core mapping shouldn't be handled in htop's side....

The CPU percentage displayed is per core, so when you have 16 CPU core (or threads) active, the maximum would be 1600%. Do you consider this takes too much CPU...

One more thing. We should allow the user to disable this "syscall" monitoring at compile time time. Since the `/proc//syscall` file is only present when the kernel is compiled with...

> @ Explorer09 Or disable the column, when the feature is not available at runtime. I wish a compile time option to disable it as well.

@BenBE * I merged your "runtime-check" and "always-on" into one option, because checking the thing at runtime is trivial. * When cross-compiling, checking `/proc/self/syscall` won't help. It's better just enable...

> > You should handle the `running` string as special and assign a placeholder number for it. The reason is it allows us to display `running` string with colors. This...