4th axis latches jog using keyboard [ or ] followed by shift

I am used to doing a rapid jog by keyboard by pressing the shift key and the desired arrow or pgup / pgdn.
Linuxncc ignores the shift if pressed after one of the axis direction buttons, and only engages rapid if shift is pressed before.

While messing around setting up my 4th axis for something, I noticed that it kept rotating after I released the keys.  If shift is pressed after the [ or ] it latches the motion at the set jog speed.

Curious if this is an undocumented feature (or I just didn't find the documentation) or a bug?  Only occurs on my A axis, not happening on XYZ.

AXIS interface with 2.8.2

Is it possible that your A axis jog speed is faster than the axis can move, and it is simply catching up to the jogged-to position?

The behavior is definitely like its latching. If I change the jog speed the speed it stays latched at is the same as the jog speed. A noticeably slower jog still latches - i.e. its not playing catch up.

Just curious if someone else with AXIS display and a 4th axis can verify the behavior? I never really used keyboard jogging for the 4th axis before, but now that I learned where it is, I just was curious about this feature.

Is it by any chance a wireless keyboard?

Its a wired keyboard.

So I've confirmed that the behavior is not PC related as I used a different one - a laptop I've installed 2,8,2 on.
The latching only happens for the 4th axis, and must be the key sequence of one of the square brackets [ or ] first followed by the shift key and then releasing the bracket key and then releasing the shift key. Motion seems to continue forever at whatever the angular jog was set to.

Also, clicking away into any of the menu fields stops the jog, or away from AXIS altogether (i.e. to write this post).

Keyboard jogging sends a straight move to the axis limit. Then on key-up it sends an abort.

So what is probably happening is that the key-down is being seen, but the key-up is not, due to the shift.

ie, it sees ] - down, and then } - up.

But that should be a problem for all axes, they share common declaration code:
github.com/LinuxCNC/linuxcnc/blob/master...cripts/axis.py#L3278

I would guess the reason its not happening on the other axes is that they are controlled by keys that do not have another identity when the shift key is pressed (i.e. PgUp, PgDn, and the 4 arrow keys).

Anyways, my 4th axis is slow enough its not a real problem for me, just an observation I made and I couldn't find documentation on the behavior. I guess this could be an issue for keyboards where the keys maybe do have a different identity when shift is pressed, or if someone tries to reassign the axis movement to different keys.

Thanks

A fix might be to bind { and } to jog-stop. But that does rather assume that all keyboards have [ and ] paired with { and }.

A quick survey seems to indicate that this is not the case on AZERTY (French) or QWERTZ (German) keyboards, so a proper fix is not as easy as I first thought.

I made the same observation. I am using US keyboards for coding and Swiss German for office.
Suggestion to change A axis clockwise to char 'a' key - same and fix for most. Rapid jogging with use of SHIFT-a = A key. B,C,U,V,W map to char b,c,u,v w. Then pick any free neighboring Key to implement counterclockwise rotation. Alternative use of CTR or ALT.