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

Refactor sticky/oneshot keys #978

Merged
merged 5 commits into from
Jun 24, 2024
Merged

Refactor sticky/oneshot keys #978

merged 5 commits into from
Jun 24, 2024

Conversation

xs5871
Copy link
Collaborator

@xs5871 xs5871 commented Jun 7, 2024

There was a thing that didn't work for me, and once again... as I came to realize, the current implementation based on modified hold-tap mechanism wasn't the best choice in the first place and increasingly difficult to work around.

  • complete rewrite, basically from scratch
  • rebranded to "sticky keys", because that is unarguably the more sensible name
  • no more dependency on hold-tap
  • actually helpful comments (I hope)
  • works from tap dance, can even stack multiple sticky keys from a single tap dance
  • even more tests
  • new feature to stack with any other keys until all keys are released

The old oneshot module is still in place, can be cleaned up eventually.

@regicidalplutophage
Copy link
Member

Oneshot name is a staple when discussing small keymaps. I don't mind the module being called sticky keys, but can you make it clear the sticky keys are the same as oneshot?

I'm a heavy oneshot user with the implementation almost the same as Callum, so I'm going to test it before approving.
One feature I'd like is if a sticky keycode is being held for some time, it starts being treated as a normal keycode that's being held. Current implementation didn't mix well with holdtap, so going to test that too. The reason is modifier+mouse inputs are common in CAD packages and mouse being a different device has no effect on sticky/oneshot keys.

@xs5871
Copy link
Collaborator Author

xs5871 commented Jun 8, 2024

Here's my argument: The term "one shot mod" is QMK specific as far as I can tell, the term "sticky keys" has been around since the late 80's and is used pretty much everywhere, except QMK.
If you're not already familiar with QMK and its tendency for whacky names "oneshot" sounds like a key that can only be used once, and that'd be silly.
I conjecture that "sticky key" will more readily convey the functionality to the uninitiated.

Mentioning the alternative name is a good idea. We've also been misspelling "one shot".

All of the problems of the old one shot implementation you mentioned should be fixed and verified by unit tests.
There were too many corner cases where they didn't quite do what one would expect.

Copy link
Member

@regicidalplutophage regicidalplutophage 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 using this for a while and it's great!

@xs5871 xs5871 merged commit 53f7c9d into main Jun 24, 2024
2 checks passed
@xs5871 xs5871 deleted the refactor-sticky-keys branch June 24, 2024 07:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants