Row.c code shrink and adding a new format for Row_printNanoseconds()

[Explorer09]

The first three commits are code shrinks. The last one commit adds a new format for Row_printNanoseconds() because I feel I missed a chance of allowing one extra digit of precision to be printed. The last commit is optional. If people feel the new format is not worth it, I can drop that commit.

(Follow-up of #1425)

[Explorer09]

LGTM. Although a bit unconventional to skip from ns to ms right away … Also, even though we have Unicode, for units I'd still prefer to use us unconditionally.

"1.0000ms" vs. "1000.0us" ...

These are same precision for showing the fractions of a second. I don't know which one looks better.

Note that the time units in the GPUMeter would have to use us anyway (due to shorter width of the field). I have thought of adding the code to display μs there.

[BenBE]

I'm neutral either way …

[fasterit]

Can we have one "format times" code as in #1583 and this combined?

[fasterit]

https://en.wikipedia.org/wiki/Microsecond ... "Its symbol is μs, sometimes simplified to us when Unicode is not available." No need to ignore the unit. It's 2025 and we have #ifdef HAVE_LIBNCURSESW :tada: .

[Explorer09]

Can we have one "format times" code as in #1583 and this combined?

The output of #1583 is an ASCII string (char []), potentially allowing UTF-8. The output of this one (#1579 and #1425) is a RichString buffer. So, nope. While I wish the two routines be merged, it's impossible due to the difference of output object types.

https://en.wikipedia.org/wiki/Microsecond ... "Its symbol is μs, sometimes simplified to us when Unicode is not available." No need to ignore the unit. It's 2025 and we have #ifdef HAVE_LIBNCURSESW 🎉 .

Ask @BenBE for this. Actually I wished the Greek letter mu (μ, U+03BC) be used when it's available, but a previous comment of BenBE said something about using us unconditionally...

[BenBE]

Using us instead of µs was suggested in my comment mostly for two reasons:

1. Avoids distinguishing cases in the code whether Unicode is available or not.
2. Avoids issues with printing on the terminal when locales are badly configured.

At least the second situation can occur easily when working with screen and tmux over SSH when some of the environment variables are forwarded incorrectly or mixed up due to diverging settings on different computers. Using us, while not being canonical, avoids both these issues and is usually understood just as well.

@fasterit: For me it's not a pressing issue and I'm totally indifferent about which one we use in the end.

[Explorer09]

Using us instead of µs was suggested in my comment mostly for two reasons:

1. Avoids distinguishing cases in the code whether Unicode is available or not.
2. Avoids issues with printing on the terminal when locales are badly configured.

At least the second situation can occur easily when working with screen and tmux over SSH when some of the environment variables are forwarded incorrectly or mixed up due to diverging settings on different computers. Using us, while not being canonical, avoids both these issues and is usually understood just as well.

I'm personally neutral on this, because after #1598 it would be easier to add the μ symbol support while having u as an appropriate fallback. It's just extra code that some people might consider it not worth it.