Allow to enable (easily) auto repeat key feature, without giving up UI (not having to rewrite all bindings with macros).
I disabled autorepeat feature in GNOME and want to enable this feature using UHK. I want to have one global on/off option (as in GNOME). For example having in onInit:
set autoRepeat true
set autoRepeatDelay 500
set autoRepeatRate 50
and this will work for all sane defaults (as in GNOME), at least for all keys with long holding them (like left arrow or j key for vim).
As of now I see the only option is to bind macros to key and then add autoRepeat modifier.
And having some speed acceleration for auto repeat would be great to (like in mouse key settings). This will allow to have precise slow movement in file (vim, helix editors) with hjkl, and then (by additional key press, by time, by amount of key pressed while holding) accelerate auto repeat.
Yes, and this is a problem.
First, it’s not cross-platform. That means you can’t move around keyboard.
Second, it’s settings are not advanced. I see in GNOME only very basic features. I can’t tune it to myself, for example, auto repeat speed increase, as in scenario I described above.
Here potentially I could utilize full power of UHK keyboard.
I would like to have all keyboard-related features in UHK keyboard itself.
And I would like to have ability to use more advanced auto repeat rules.
Dynamic auto repeat - increase / decrease repeat speed. Usefull when navigating with keys in modal editor like vim. When using hjkl in normal mode. It’s either too slow (when want to scroll fast multiple rows, or too fast, when want to stop at precise line).
Regarding holding hjkl in vim… isn’t it an antipattern? Shouldn’t you use specific jump commands? E.g., search with /<text to search>, jump with <line number>gg or <lines to jump>j, or use some plugin like easy-motion (GitHub - easymotion/vim-easymotion: Vim motions on speed!)?
I see it as different patterns. navigating with hjkl is mostly to look at code, some implementation. It’s comparable to mouse scrolling with mouse wheel in VS Code. I use it a lot to look around. There is often no specific location or method to jump to. It’s more like explore mode.
Might be there is more advanced or better ways to do this, but you have to mature to that advanced mode. Also it’s not only vim itself. Here is another usefull pattern.
Let’s say you have a very long http address string, and you want to modify it (delete/update some segment - search query, order id, etc.). I jump to address and move caret (holding left/right arrow to autorepeat) until I get to point. It might be very long wait till it scroll to desired location. Also I could’t find how to do that and it will differ from what vim keybindings (if possible at all).
A don’t want to remember all different combinations for all different apps (for vim/helix it’s ok, I’m software developer, but not for other not keyboard-oriented programs).
For nano text (for gedit too) editor this also would be very handy, it doesn’t allow advanced jumps.
So I just hold arrow key and wait till I get to desired location
It basically applies to all adress lines (file path in GNOME Files).
I see. If you dont mind me digging deeper into this (i am just seizing an opportunity to gather some feedback on how people use their UHKs)…
Are you aware of the caret navigation mode, in which right module produces arrow taps when you hold fn layer? Do you use it, does it (not) work well for you?
Holy…this is AMAZING!!!
I’ve just tried this, it’s awesome. I always skipped this part because there were too much technical details and thought “It’s something for mouse, never mind, first set up keys” (I have trackpoint module). So I skipped this (and almost never used key cluster or trackpoint).
Trackpoint because it’s not precise as mouse and it requires some training and patience.
And I thought that most description down below is about speed, acceleration, etc. I never cared about.
Keycluster because I don’t much like it, I prefer to bind as much to home row (previously it was not possible, but with secondary advanced mode it became possible) and to white spaces.
Can we do this not only for navigating, but for deletion?
So I navigate to desired location with “caret navigation mode”, and then delete with ''caret navigation mode" (when I need to delete long portion of text)?
You can already map that using macros, as discrete navigation modes can be remapped :-). But it is an excelent idea for a new pre-packaged mode slot!
Edit: namely, hijacking the media mode:
set navigationModeAction.media.left keystroke backspace
set navigationModeAction.media.right keystroke delete
...
set module.keycluster.navigationMode.base media
Haven’t you read the Module manual - Ultimate Hacking Keyboard, folks? It mentions the caret navigation mode and the uhk.io/m URL is featured in module boxes and on the bottom of modules.
As for the original suggestion, it’s very niche, and we should only implement it if the demand is stronger.
Yes, something like this. But to have ability to remap navigation mode to any key or scancode.
For trackpoint as example (qwerty):
d (instead of special fn key) key to go to caret navigation mode (note it’s already bound to key and fn3 secondary role - advanced mode, this should not be altered)
f key to delete (backspace/delete as you have shown) using trackpoint (the same - key and LCtrl mode)
or the same, but insteard of d and f keys use left and right keys of key cluster.
Without affecting other modes (like media) and without affecting original mode (not to choose either caret navigation mode or instead backspace/delete).
I think ideally it to implement using virtual navigation modes.
And also to have ability to disable standard navigation modes to allow maximum flexibility.
Do I understand correctly that you basically want a new command, let’s call it holdNavigationMode <navigation mode id>, that can activate navigation modes independently of layers, except that you want it to be compatible with keys that already do switch to a layer on secondary role? That is, you want to be able to use the fn3 layer with multiple different navigation modes depending on which key is used to switch to the fn3 layer?
I guess you could already do that with:
ifSecondary final {
set module.keycluster.navigationMode.fn3 caret
holdLayer fn3
set module.keycluster.navigationMode.fn3 <whatever was the original navigation mode bound to fn3>
}
holdKey d
(Still, requesting holdNavigationMode <navigation mode id> command is totally fair if you ask me.)
When the Fn layer is active, the pointing stick behaves like arrow keys, allowing quick movement in text editors.
That seemed totally uninteresting for me and I did not bother even trying it, because I have the arrow keys on my home row for years, so that did not sound like it would give any additional benefit for me. But this was wrong, because using the trackpoint l can controll the speed of the cursor, which I can not with the keys! That was not clear for me from the sentence in the manual.
So after seeing the benefit to control the caret speed I now better understand the original request. I am not sure if I would use a new option and if it is of benefit for characters? Likely makes most/ just sense for navigation I think.
But nice I am now aware of the caret mode with the trackpoint.
Yes, holdNavigationMode independently of layers. holdNavigationMode should itsefl behave as fn, mod (for navigation mode), etc. At the same time, holdNavigationMode never conflicts with any keybindings (correct me if I am wrong), because for right hand you either press some key or use trackpoint (holdNavigationMode is expected to be used exclusively with left hand). So in this scenario every keybindings works as before + pressing that key set navigation mode for trackpoint.
No, I would say independent of secondary role. No matter (for trackpoint) how I press/hold key, trackpoint navigation should work.
Let’s say I press d key fast and at the same time use trackpoint - navigation mode should work.
If I hold d key (and it switches to fn3 layer) - for trackpoint this doesn’t matter, it still should work as before (consitent behavior).
If I use other fancy combination - press d and other key (which triggers key from fn3, but without switching layer) and at the same time user trackpoint - it should work as before.
So in my case navigation mode is bind by scancode, but without affecting any other fancy key bindings I already made, because in my use case they never conflict. I either use key (just key, secondary role of key + other key) or navigation mode (pressing key + use trackpoint).
BUT, if I press d key (hold it) and start using trackpoint - after this (stopped using trackpoint, but still hold key) it should behave as if I never used trackpoint - pressing other key should emit key on fn3 layer.
It is for consistency, so I would not have to worry for how long I pressed d key to activate navigation mode. It just works, always.
