Add GET_TAPPING_TERM macro to reduce duplicate code

[joukewitteveen]

The macro gives the right tapping term depending on whether per-key
tapping terms and/or dynamic tapping terms are enabled. Unnecessary
function calls and variable resolution are avoided.

Description

The time when TAPPING_TERM was the tapping term is over. Per-key and dynamic tapping terms are possible now. This makes using the correct tapping term tricky and it requires some preprocessor-fu. Let's abstract all of that away in a GET_TAPPING_TERM macro modeled after the get_tapping_term function. Using this macro instead of TAPPING_TERM will produce the optimal and correct code for getting the tapping term.

Types of Changes

• Core
• Bugfix (edit: partially, as a dynamic tapping term is now respected more broadly)
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

• [Feature Request] Per-key tapping term API simplification #16472

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[precondition]

Looks good to me and I didn't notice any firmware size regressions when checking out this PR. In fact, compiling a keymap with AUTO_SHIFT_ENABLE like qmk compile -kb nacly/splitreus62 -km scheiklp for example actually produced a smaller binary, so that's nice.

[joukewitteveen]

I added a mention of the macro to the documentation.

@drashna: The new macro could replace TAP_CHECK in /users/drashna/pointing/pointing.c. Other than that, I did not find any user code refering to get_tapping_term.

[KarlK90]

Very nice, action_tapping.c getting simpler not more complex is always a win.

I found one other place that would benefit from the usage of this macro, it is the cirque trackpoint driver in quantum. Could you add the simplification for CIRQUE_PINNACLE_TAPPING_TERM as well?

https://github.com/qmk/qmk_firmware/blob/develop/quantum/pointing_device_drivers.c#L100-L115

The else branch in in this condition in the cirque driver doesn't make any sense as TAPPING_TERM is always defined so this can just be discarded.

#            ifdef TAPPING_TERM
#                define CIRQUE_PINNACLE_TAPPING_TERM TAPPING_TERM
#            else
#                define CIRQUE_PINNACLE_TAPPING_TERM 200
#            endif

[joukewitteveen]

it is the cirque trackpoint driver in quantum.

That looks similar to, but a litttle more complex than the Drashna pointing code. Unfortunately, I'm away from a decent computer for the coming week. Feel free to pile up a commit that takes care of those two pointer usages. Otherwise, I can do it at the end of next week at the earliest.

[KarlK90]

@joukewitteveen done! @drashna and @precondition please review and feel free to merge if ok.