You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sorry, there's quite a bit of backstory required for this one.
I am working on adding Tap Hold key support to Auto Shift in #11059. However, lots of the Tap Hold configurations' effects don't make sense; holding a key for longer (or not) will also change its shifted state. To change this behavior, I am currently just returning false on all Auto-Shift-enabled Tap Hold key events and implementing the configurations' relevant effects myself. This is already coded and working, but relies on action_tapping's sending records in the correct order with their keycodes unmodified.
The issue I'm running into is how action_tapping doesn't send those records until the action is decided (usually release, though depending on settings can be when TAPPING_TERM is exceeded). event.timeis unreliable, and process_auto_shift currently polls for the current time (as does process_tap_dance). If the records are delayed, it then polls for time on press record and immediately gets the release record, never shifting if holding a Tap Dance key. I fixed this by adding a method call before action_tapping to save the current time.
This workaround doesn't fix all scenarios, though. Mixing two Tap Hold keys and other edge cases causes that method to be called multiple times before any records get to process_auto_shift.
So, finally, "what is this issue?" Well, if event.time was accurate everything would be fine, but I can't reproduce to investigate myself (doesn't occur on my Corne or Planck rev6). Also, if it did, I would still have the jank approach of assuming records are sent unchanged and returning false (which does work, though). Alternatively, I could call parts of Auto Shift before action_tapping, to check if that Tap Hold key should be handled by it. I'm wondering whether I should do the latter (or open an issue for event.time and wait for someone else to investigate or for my next build and get a Proton C) as I have spring break coming up and could probably get the pull finalized.
The text was updated successfully, but these errors were encountered:
Sorry, there's quite a bit of backstory required for this one.
I am working on adding Tap Hold key support to Auto Shift in #11059. However, lots of the Tap Hold configurations' effects don't make sense; holding a key for longer (or not) will also change its shifted state. To change this behavior, I am currently just returning false on all Auto-Shift-enabled Tap Hold key events and implementing the configurations' relevant effects myself. This is already coded and working, but relies on
action_tapping
's sending records in the correct order with their keycodes unmodified.The issue I'm running into is how
action_tapping
doesn't send those records until the action is decided (usually release, though depending on settings can be whenTAPPING_TERM
is exceeded).event.time
is unreliable, andprocess_auto_shift
currently polls for the current time (as doesprocess_tap_dance
). If the records are delayed, it then polls for time on press record and immediately gets the release record, never shifting if holding a Tap Dance key. I fixed this by adding a method call beforeaction_tapping
to save the current time.This workaround doesn't fix all scenarios, though. Mixing two Tap Hold keys and other edge cases causes that method to be called multiple times before any records get to
process_auto_shift
.So, finally, "what is this issue?" Well, if
event.time
was accurate everything would be fine, but I can't reproduce to investigate myself (doesn't occur on my Corne or Planck rev6). Also, if it did, I would still have the jank approach of assuming records are sent unchanged and returning false (which does work, though). Alternatively, I could call parts of Auto Shift beforeaction_tapping
, to check if that Tap Hold key should be handled by it. I'm wondering whether I should do the latter (or open an issue forevent.time
and wait for someone else to investigate or for my next build and get a Proton C) as I have spring break coming up and could probably get the pull finalized.The text was updated successfully, but these errors were encountered: