Mod-Tap implementation

[onolox]

https://zmk.dev/docs/behaviors/mod-tap https://github.com/davebrny/long-press

This page has an example of the behavior I want to achieve, for example: When i click "a" it outputs "a" I hold for a determined time the key "a", let's say 100ms, it outputs "A"

I don't need the repeating "aaaaaa", I want to use the hold instead of the shift key.

I can achieve this behavior with this app?

[cajhin]

That's not an option, sorry. Generally, timing of the input is not considered. Press-hold-release [a] to produce "A" sounds like a clever idea, but I believe waiting for it kills your rhythm and gets old really quick. What's the point, when shift a is faster?

[onolox]

It's just an example, other functions can be done. Like hold F to format, or a hold 5 to hit F5...

I don't think it breaks the rithm, shift+a it's not faster, and most important, I have to move my hand a lot to hit the difficult left and right shifts, to CamelCaseTheThings.

[dimitrioschr]

That's not an option, sorry. Generally, timing of the input is not considered. Press-hold-release [a] to produce "A" sounds like a clever idea, but I believe waiting for it kills your rhythm and gets old really quick. What's the point, when shift a is faster?

I have the same request, and maybe there is a way to do it without consideration to timing, only using KEYv and KEY^ events:

• when a key is pressed down, the KEYv event is registered and the KEY character is sent to the computer.
• if the same KEYv event is registered, ie a "tap slow" begins, then send BSP and the combo LSHF + KEY, and ignore up to and including the next KEY^ event.

I suppose that events have to be considered after REWIREs and may not apply to COMBOs. Also, the ability to send repeated characters by holding down a key is lost as well, but that should be expected for this feature. This could be implemented as an OPTION.

Thank you.

[cajhin]

That is similar to how macOS deals with accents (opt+i prints ˆ then e replaces ˆ with ê). It is supported by the OS though, and it only happens when the app says that it supports it.

To pick up onolox' example: "hold 5 for F5". In a text box, this would print 5, then backspace, then F5. What would happen if you do the same in a non-text environment like Blender? '5' and 'backspace' could have any meaning here.

You could not produce output until the outcome is known, but then you have to delay "5" until the key is released, which can have side effects.

I'm not against such a feature, but it needs to be a clear design, and not cause complicated issues. I'm not quite satisfied with the ideas in my head yet.

[dimitrioschr]

You could enable / disable this with an [Esc] + [Key] combo, like Debug and AutoHotKey.

The enable / disable could be either global (for the entire keymap), or for the keys that have been defined (i.e we will have to specify in the config which keys to AutoShift, for example you may only want to AutoShift brackets to braces).

The last point could be useful also if one wants the long press to do another action, e.g send a dead key. Then use dead keys like in the [SHOWOFF] section for sequences to trigger macros etc.

Thank you.