Using super+space as the start of a chord chain causes it not to end at the tail

[TheZoq2]

When making a chord chain that starts with super+space, the chain doesn't seem to end after the last chord in the chain has been reached.

super + space ; s
    someCommand

Causes someCommand to run each time s is pressed after super+space has been pressed atleast once.

super+p ; s
   someCommand

Causes someCommand only run the first time the s key is pressed after the super+p chord and I would expect that to be the result when using super+space awell.

I also tried this

super+p ; super+space ; s

Which does the expected thing of only running once

[baskerville]

I can't reproduce.

[blairdrummond]

Can't confirm that this is the same issue, but I think that the chain doesn't end on ";" if there is another keybind that has a chain that doesn't end.

I tried this with

super + m; Return
  some command

super + m: {comma,period,t,p}
  some other commands

versus

super + m; Return
  some command

# super + m: {comma,period,t,p}
#   some other commands

super + m; Return behaves differently in these two examples, as though it inherits the : from the other super+m: keybinding.

[pjones]

@blairdrummond identified the problem. I was experiencing the same issue and was able to work around the problem by changing all my cords with the same prefix to use a semicolon.

[baskerville]

@blairdrummond identified the problem.

Indeed. I'm afraid I don't see any solution for this other than not having chains that start with the same chord and have a different locking policy. When *sxhkd* receives the initial chord, it has no way of knowing whether it should lock the chain or not.

[TheZoq2]

How about a vim-like solution with a timeout. If the chain is ambiguous, wait for a timeout to decide. Also, I would find a mode where a command is run for multiple steps in a coord. For example, having it run a command to show a bar when the meta key is pressed and have that bar open while other chords are run

[blairdrummond]

I don't know if this is practical, but would it be possible to create some command that tells sxhkd to abort a current chain? For example, something like

super + m: {comma,period,Return}
    {move left, move right, st && pkill -USR2 -x sxhkd}

The idea being, if you could end a chain without using : and ; syntax, you could bundle everything under one : command, and still get the behavior you would expect

 super + m; Return
  st

super + m: {comma,period}
  {move left, move right}

to have.

[blairdrummond]

Update: Sorry, that was a dumb suggestion, because you can already do that without new technology.

super + m: {comma,period,Return}
    {move left, move right, st &; xdotool key Escape}

Should accomplish that. Is that an adequate work-around?

[protesilaos]

Just to note that I have experienced this issue.

Defining this works as intended:

super + n ; f ; {l,s,p}
     bspc node -g {locked,sticky,private}

But the following is triggered just by pressing any of l, s, p:

super + n ; {l,s,p}
     bspc node -g {locked,sticky,private}

[buzuck]

I stumbled onto this issue as well.

I wanted to warn the user he was entering a complex chord chain, by overloading the first keypress

super + n
    notify-send "Node state?" "l: locked, s: sticky, p: private"
super + n ; {l,s,p}
    bspc node -g {locked,sticky,private}

l, s and p were triggering theirs respective commands one super + n was pressed.

[indeedwatson]

Update: Sorry, that was a dumb suggestion, because you can already do that without new technology.

super + m: {comma,period,Return}
    {move left, move right, st &; xdotool key Escape}

Should accomplish that. Is that an adequate work-around?

you need sleep .4 (or some low number like that) before xdotool for this to work, otherwise it is most likely that when xdotool presses Escape you will still be holding super, making it super + Escape, so it won't work unless you add a brief pause.

This is rather unfortunate, coming from i3 modes were some of the best features, sad to see it's not as robust here. I think at least some integrated command to end the chain should be implemented.

[rosshadden]

I think at least some integrated command to end the chain should be implemented.

Also coming from i3 (yesterday) I hit this immediately as well. In i3 I had the following aliases:

# return to the default mode
set $return mode "PREFIX"
set $exit mode "default"

I had a mode named "PREFIX" which was basically a menu for accessing other modes. In other modes I would end commands with $exit if they needed to exit the mode, and each mode had a mapping to return to the PREFIX mode which was mostly so I wouldn't get stuck or lost in mode hell.

Having commands in sxhkd to allow us to programmatically enter or exit modes would be extremely useful, though the former wouldn't really be possible without also introducing some sort of labeling. Which is way beyond the scope of this issue 😅. Just an exit command alone would be very useful, so we don't have to trigger the escape key.