[debug] improve debug readability

[crazyiop]

little tweak in the debug output to make things more readable:

• wrap KMKKeyboard report to 100 char (changeable), not splitting a key=value
• include a \n before MatrixChange as those are the begining of a new logical 'block'

example result:

MatrixChange(ic=14, pressed=True)
KeyResolution(key=Key(code=1021, has_modifiers=None))
KMKKeyboard(
  debug_enabled=True, diode_orientation=1, matrix=(<MatrixScanner object at 0x2000eef0>,),
  unicode_mode=0, _hid_helper=USBHID(REPORT_BYTES=9), keys_pressed=set(),
  _coordkeys_pressed={14: Key(code=1021, has_modifiers=None)}, hid_pending=False,
  active_layers=[1, 0], _timeouts={},
)

MatrixChange(ic=52, pressed=True)
KeyResolution(key=Key(code=20, has_modifiers={1}))
KMKKeyboard(
  debug_enabled=True, diode_orientation=1, matrix=(<MatrixScanner object at 0x2000eef0>,),
  unicode_mode=0, _hid_helper=USBHID(REPORT_BYTES=9),
  keys_pressed={Key(code=20, has_modifiers={1})},
  _coordkeys_pressed={52: Key(code=20, has_modifiers={1}), 14: Key(code=1021, has_modifiers=None)},
  hid_pending=False, active_layers=[1, 0], _timeouts={},
)

MatrixChange(ic=52, pressed=False)
KeyResolution(key=Key(code=20, has_modifiers={1}))
KMKKeyboard(
  debug_enabled=True, diode_orientation=1, matrix=(<MatrixScanner object at 0x2000eef0>,),
  unicode_mode=0, _hid_helper=USBHID(REPORT_BYTES=9), keys_pressed=set(),
  _coordkeys_pressed={14: Key(code=1021, has_modifiers=None)}, hid_pending=False,
  active_layers=[1, 0], _timeouts={},
)

MatrixChange(ic=14, pressed=False)
KeyResolution(key=Key(code=1021, has_modifiers=None))
KMKKeyboard(
  debug_enabled=True, diode_orientation=1, matrix=(<MatrixScanner object at 0x2000eef0>,),
  unicode_mode=0, _hid_helper=USBHID(REPORT_BYTES=9), keys_pressed=set(), _coordkeys_pressed={},
  hid_pending=False, active_layers=[0], _timeouts={},
)

[xs5871]

I've been working on better debug output on the side and didn't have the opportunity to commit anything yet.
In my opinion _print_debug_cycle shouldn't print all that static, never changing clutter on every key event.
We can show the entire keyboard configuration at boot/init once, and the debug cycle should only contain relevant information, i.e. active_layers, _coordkeys_pressed and maybe keys_pressed.

[crazyiop]

@xs5871 Nice! glad to here that.

This MR does not change many things so I guess it will not interfer much with that work. It might still be nice to have it until you have that new debug ready ?

[klardotsh]

Approving the idea; I have a remark inline that OP and @xs5871 can work out whether they want to take or leave but aside from that this LGTM.

[kdb424]

Why is this not an f-string but the others are?

[crazyiop]

those are not fstring as that would make the line too long. The goal of fstring is to give an option that in most case is a more readable string. Here the more readable, given the lenght, is the format. as it is each argument is below it's corresponding {}.
It was also an attempt to have both not too long line, and "the output will look exactly like the string is formated in the code" you suggested.

I can split it into more fstring line if the consistency of string formatting is wanted. (I can even push a commit to remove all .format() given the low number of them if you want).

[kdb424]

I'll leave the final call to @xs5871 but I believe that consistency makes more sense personally, but I suppose that's a valid point.

[xs5871]

+1 to consistency.
When I suggested "make it an f-string" I had a single multi-line f-string in mind. The x += '*\n' feels quite unpythonic.

I have to say, this discussion has been going on for almost to long, considering this concerns such a minor change.
It's probably because we started with a complex, possibly over-engineered (no offense, we all do over-engineer sometimes; also it's fun), solution and step for step reverted it back to a pragmatic one, instead of starting from scratch.
At this point, we could just as well keep the original code, just with a couple of newlines thrown into it.

[kdb424]

I know these aren't the changes you originally wanted in there, but I believe this is easy to read, and improves debug-ability quite a bit.

[kdb424]

make fix-formatting fix-isort test should auto fix errors, and give you the test output before committing and pushing if you weren't aware.

[crazyiop]

Sorry I did not fully tested the fstring change before upload but got back to my board:

• some attribute were wrong as the previous KMKKeyboard log had for instance "timeouts={}" but it is actually self._timeouts use in the format parameter (I failed to see the difference).
• circuitpython cannot implicitely concat multiple fstring. So I put them in a list with a ''.join() as a workaround.

[xs5871]

Looks good, verified on hardware. Thanks for sticking with the issue.
I'm going to go ahead and merge.

[klardotsh]

Ah, yeah, when I wrote CircuitPython's f-strings implementation I left some comments about that concatenation error. Technically this means Micro+CircuitPython are not actually PEP-498 compliant, but both upstreams agreed with me that the tradeoff was worthwhile. Definitely confusing the first time one runs into it, though :\ https://github.com/adafruit/circuitpython/pull/2690/files#diff-e4737fa9a48c19ab35f9083a424c50059a6e94008f7d2aeaa4418eab7b3bc332R86-R102