Combining mods with tap-hold-release-keys (i.e. Achordion-like tap-hold behaviour)

[jurf]

Is your feature request related to a problem? Please describe.

Homerow mods with Kanata are almost perfect thanks to tap-hold-release-keys that can much improve same-hand rolls, but unfortunately this prevents combing mods (e.g. Ctrl+Shift).

Describe the solution you'd like.

The solution I use in QMK is the Achordion library. In principle, it works similarly to tap-hold-release-keys, but it does not eagerly tap the keys on the down press. This unfortunately adds back the typical tap-hold delay, but allows to combine mods.

The implementation is a bit more nuanced (e.g. it employs a longer timeout but eagerly applies configured mods to improve usage when combined with a mouse), but the documentation is well-written.

Describe alternatives you've considered.

I currently simply hold the first modifier for the timeout duration, but honestly it's annoying and I'd rather revert back to the old behaviour.

Additional context

No response

[jtroo]

Here's some random ideas I threw together ;)

[jtroo]

With the random ideas thrown into the wind, perhaps one/some of them are sufficient to hit the use case.

If all are still insufficient, let's come up with what the minimal set of "missing" behaviours are. And achordion itself seems to be very similar to the internal Custom tap-hold variant which is used by tap-hold-release-keys.

kanata/keyberon/src/action.rs

Line 90 in 0f98920

Custom(&'a (dyn Fn(QueuedIter) -> (Option<WaitingAction>, bool) + Send + Sync)),

kanata/parser/src/cfg/mod.rs

Line 1719 in 0f98920

config: HoldTapConfig::Custom(custom_func(&tap_trigger_keys, &s.a)),

kanata/parser/src/cfg/custom_tap_hold.rs

Lines 7 to 34 in 0f98920

	/// Returns a closure that can be used in `HoldTapConfig::Custom`, which will return early with a
	/// Tap action in the case that any of `keys` are pressed. Otherwise it behaves as
	/// `HoldTapConfig::PermissiveHold` would.
	pub(crate) fn custom_tap_hold_release(
	keys: &[OsCode],
	a: &Allocations,
	) -> &'static (dyn Fn(QueuedIter) -> (Option<WaitingAction>, bool) + Send + Sync) {
	let keys = a.sref_vec(Vec::from_iter(keys.iter().copied()));
	a.sref(
	move |mut queued: QueuedIter| -> (Option<WaitingAction>, bool) {
	while let Some(q) = queued.next() {
	if q.event().is_press() {
	let (i, j) = q.event().coord();
	// If any key matches the input, do a tap right away.
	if keys.iter().copied().map(u16::from).any(|j2| j2 == j) {
	return (Some(WaitingAction::Tap), false);
	}
	// Otherwise do the PermissiveHold algorithm.
	let target = Event::Release(i, j);
	if queued.clone().copied().any(|q| q.event() == target) {
	return (Some(WaitingAction::Hold), false);
	}
	}
	}
	(None, false)
	},
	)
	}

One major difference I can think of from QMK is that multiple "eager mods" can't activate without terminating the antecedent tap-hold pending state; i.e. the decision of tap vs. hold must be chosen before activating the next eager mod. A way around this, if this is too restricting, is perhaps to forego tap-hold entirely and use:

• multi
• cancellable macro
• virtual keys with switch logic tapped within the macro