Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug17281 - Retain momentary layers until the end of tapping #17282

Merged
merged 3 commits into from
Nov 28, 2022

Conversation

fxkuehl
Copy link
Contributor

@fxkuehl fxkuehl commented Jun 1, 2022

Description

"Retain momentary layers until the end of tapping" is my solution for Bug17281.

"Make process_tapping more readable" helped me understand the code better as I was investigating this problem. I'm including it for consideration. It's purely for readability and should have no impact on functionality. It is not needed to fix the bug.

Types of Changes

  • Core
  • Bugfix
  • New feature
  • Enhancement/optimization
  • Keyboard (addition or update)
  • Keymap/layout/userspace (addition or update)
  • Documentation

Issues Fixed or Closed by This PR

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).

@github-actions github-actions bot added the core label Jun 1, 2022
@drashna
Copy link
Member

drashna commented Jun 2, 2022

If possible, it would be very helpful to add unit tests to ensure that the correct behavior is being triggered, and to ensure that it's not broken in the future.

@drashna drashna requested a review from a team June 2, 2022 15:48
@fxkuehl
Copy link
Contributor Author

fxkuehl commented Jun 2, 2022

Sounds reasonable. I have no idea how to write or run unit tests for QMK. I'm still pretty new to it. I'll start reading the docs at https://docs.qmk.fm/#/unit_testing. Edit: At least it looks like I haven't broken any existing unit tests, so that's a good start. ;)

@drashna
Copy link
Member

drashna commented Jun 2, 2022

well, if you take a look at the secure tests and the caps word tests, that may give you a good idea, on how to start.

It's not too different from a keymap, but with some of the special stuff due to the testing code. You can use stuff like layer_state_is(x) still, etc.

If you need further help, the discord would be a good place to discuss it.

@precondition
Copy link
Contributor

precondition commented Jun 3, 2022

Since your change affects the tap-hold logic, you might be also interested in taking a look at the tap-hold unit tests I wrote for #15741, especially the test roll_layer_tap_key_with_regular_key. You should be able to simply copy one of those, swap a few lines and change some assertions.

Copy link
Contributor

@precondition precondition left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review of "Make process_tapping more readable"

quantum/action_tapping.c Outdated Show resolved Hide resolved
quantum/action_tapping.c Outdated Show resolved Hide resolved
quantum/action_tapping.c Outdated Show resolved Hide resolved
quantum/action_tapping.c Outdated Show resolved Hide resolved
quantum/action_tapping.c Outdated Show resolved Hide resolved
quantum/action_tapping.c Outdated Show resolved Hide resolved
@fxkuehl
Copy link
Contributor Author

fxkuehl commented Jun 6, 2022

Since your change affects the tap-hold logic, you might be also interested in taking a look at the tap-hold unit tests I wrote for #15741, especially the test roll_layer_tap_key_with_regular_key. You should be able to simply copy one of those, swap a few lines and change some assertions.

Thanks. I was looking for a good place to add my test. It's not really specific to any of the tap_hold_configurations. I deliberately broke the retaining of modifiers during tapping, to see if it would break an existing test similar to what I was doing with layers. But no tests broke. So I ended up adding two tests to tests/basic/test_tapping.cpp. One for releasing Shift while tapping, one for releasing a layer key while tapping.

@bschwehn
Copy link

What is needed to get this merged? It solves an annoyance for me and it would be nice not having to maintain this as a private patch :)

Move most #ifdefs into conditionally defined macros to make the logic
easier to follow.

Signed-off-by: Felix Kuehling <[email protected]>
This allows mod-tap and layer-tap keys on layers to behave as expected.

Bug: qmk#17281
Signed-off-by: Felix Kuehling <[email protected]>
Mods and layer key release is delayed while tapping is in progress to
ensure that the tap is registered with the modifier state and on the
layer where the key was first pressed.

Signed-off-by: Felix Kuehling <[email protected]>
@KarlK90
Copy link
Member

KarlK90 commented Sep 15, 2022

@precondition reading through the discussions and the code changes it seems that most (if not all?) have come to a resolution, if so could you resolve them?

@fxkuehl reading through the code nothing stands out for me that would prevent a merge from my side. I'm going to try out the changes and add my approval. Thanks for the bugfix and cleaning up that mess that action_tapping.c is.

@precondition
Copy link
Contributor

Uh, I don't see a "Resolve" button anywhere in my previous review. Isn't that something that's only shown to the author of the PR? I can make a new approving review though.

@KarlK90
Copy link
Member

KarlK90 commented Sep 18, 2022

Interesting, I thought that you should be able to resolve those 🤔 anyway, if you are happy with the current changes I can resolve the threads for you.

Copy link
Member

@KarlK90 KarlK90 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been testing this PR and haven't encountered any problems. The changes also LGTM! Thanks!

@KarlK90 KarlK90 requested a review from a team October 5, 2022 15:42
# else
# define TAP_GET_RETRO_TAPPING true
# endif
# define MAYBE_RETRO_SHIFTING(ev) (TAP_GET_RETRO_TAPPING && (RETRO_SHIFT + 0) != 0 && TIMER_DIFF_16((ev).time, tapping_key.event.time) < (RETRO_SHIFT + 0))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't fully understand why did you prefix the macro name with "maybe"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are more conditions that are checked before the actual retry-shifting code (e.g. tapping_key.tap.count == 0). The condition here is necessary but not sufficient for retro shifting.

@github-actions
Copy link

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with bug, awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

@github-actions github-actions bot added the stale Issues or pull requests that have become inactive without resolution. label Nov 20, 2022
@fxkuehl
Copy link
Contributor Author

fxkuehl commented Nov 20, 2022

What do I need to do to get this merged. I don't think it should just be closed for being stale.

@github-actions github-actions bot removed the stale Issues or pull requests that have become inactive without resolution. label Nov 21, 2022
@KarlK90
Copy link
Member

KarlK90 commented Nov 23, 2022

What do I need to do to get this merged. I don't think it should just be closed for being stale.

It won't be closed 👍, at the moment it is just missing one more review from a collaborator and then it can be merged.

@drashna drashna requested a review from a team November 23, 2022 18:05
@KarlK90
Copy link
Member

KarlK90 commented Nov 24, 2022

@fxkuehl now that all approvals are in we can merge your PR next week after the breaking changes merge from develop to master

@KarlK90 KarlK90 merged commit 4ae7525 into qmk:develop Nov 28, 2022
elpekenin pushed a commit to elpekenin/qmk_firmware that referenced this pull request Dec 7, 2022
* Make process_tapping more readable

Move most #ifdefs into conditionally defined macros to make the logic
easier to follow.

* Retain momentary layers until the end of tapping

This allows mod-tap and layer-tap keys on layers to behave as expected.

Bug: qmk#17281

* Add tests for delayed mod/layer release while tapping

Mods and layer key release is delayed while tapping is in progress to
ensure that the tap is registered with the modifier state and on the
layer where the key was first pressed.

Signed-off-by: Felix Kuehling <[email protected]>
omikronik pushed a commit to omikronik/qmk_firmware that referenced this pull request Jan 22, 2023
* Make process_tapping more readable

Move most #ifdefs into conditionally defined macros to make the logic
easier to follow.

* Retain momentary layers until the end of tapping

This allows mod-tap and layer-tap keys on layers to behave as expected.

Bug: qmk#17281

* Add tests for delayed mod/layer release while tapping

Mods and layer key release is delayed while tapping is in progress to
ensure that the tap is registered with the modifier state and on the
layer where the key was first pressed.

Signed-off-by: Felix Kuehling <[email protected]>
@fxkuehl fxkuehl deleted the bug17281 branch February 20, 2023 22:41
@fxkuehl fxkuehl restored the bug17281 branch February 20, 2023 22:41
fxkuehl added a commit to fxkuehl/qmk_firmware that referenced this pull request Mar 20, 2023
* Make process_tapping more readable

Move most #ifdefs into conditionally defined macros to make the logic
easier to follow.

* Retain momentary layers until the end of tapping

This allows mod-tap and layer-tap keys on layers to behave as expected.

Bug: qmk#17281

* Add tests for delayed mod/layer release while tapping

Mods and layer key release is delayed while tapping is in progress to
ensure that the tap is registered with the modifier state and on the
layer where the key was first pressed.

Signed-off-by: Felix Kuehling <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants