Skip to content

fix: caps-remap restarts only its own xcape instance - #63

Merged
YASoftwareDev merged 1 commit into
masterfrom
fix/caps-remap-own-xcape
Sep 26, 2026
Merged

YASoftwareDev merged 1 commit into
masterfrom
fix/caps-remap-own-xcape

Conversation

@YASoftwareDev

Copy link
Copy Markdown
Owner

Summary

x11/caps-remap.sh restarted xcape with pkill -x xcape, which also killed unrelated xcape instances — e.g. a separate Super_L tap binding (xcape -t 200 -e Super_L=Alt_L F1) started by another tool.

It now kills only its own instance: pkill -f '^xcape .*-e Hyper_L'. xcape rewrites its argv in place, so = shows up as a space in the process list — the pattern matches on Hyper_L rather than the literal Hyper_L=Escape.

Test plan

  • With both xcape instances running, pgrep -af xcape shows xcape -t 200 -e Hyper_L Escape and xcape -t 200 -e Super_L Alt_L F1 — the pattern matches only the first
  • Re-run x11/caps-remap.sh: Caps tap → Escape still works, Super tap binding survives
  • CI gate green

pkill -x xcape also killed unrelated xcape instances (e.g. a Super_L
tap binding). Match our Hyper_L invocation instead; xcape rewrites its
argv so '=' appears as a space.
@YASoftwareDev
YASoftwareDev merged commit 25cd686 into master Sep 26, 2026
30 checks passed
@YASoftwareDev
YASoftwareDev deleted the fix/caps-remap-own-xcape branch September 26, 2026 08:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants