Why not use official caps2esc plugin?

[MarcelRobitaille]

First off, I appreciate what you've done here and I'm loving the spacefn layer.

I wonder why re-implement caps2esc though when there's an official plugin for it. As I understand it, interception tools is made so you can pipe through multiple transformers. I actually use the -m 2 option with the official caps2esc plugin. Would you consider removing the caps2esc functionality from this plugin and use that one instead?

[maricn]

Hi @MarcelRobitaille, thanks for your interest.. The main difference is I'm reckless and I don't sleep. Where caps2esc uses usleep(...), my code doesn't.

I know it's recommended to have the sleeps, but I found them detrimental and causing typing inconsistencies in some rare cases. Use my code with caution. (I should update the README.md file to announce that) [UPDATE: also worth mentioning - I personally haven't had any issues w/o sleeps at all]

Additionally, iirc, I found that sending [too many] SYN events breaks some big (3+ keys) chords on my machine (sometimes). ~So, since caps2esc and any other InterceptionTools plugins I know of send them on chording with downstream (caps2esc example), I wrote a single plugin that's able to be context aware like no chaining solution can be.~ [UPDATE: actually no, I found that sending too many SYN events in my code produces unexpected results, but that was not my reasoning for not choosing caps2esc in the first place.] This is NOT in the spirit of InterceptionTools :( (and I should also put a notice about that in the README.md).

Not sure if I missed something, it's been a while since I wrote any code for this[, and tbh not sure if I was introduced to caps2esc working on libudev and not on xmodmap at that moment]. I plan to rewrite parts of it in more C++-ish way and make it more general and hackable, and to add support for combined CAPS_LOCK + mouse click with the new mux option of InterceptionTools, but I am lazyyyy... I mention that bc in case you wanna hack it, I can reduce the scope of the incoming update and push the C++ refactor asap.

[skrat]

I find your space cadet mode really useful, especially in the shell and in the insert mode. I also find it odd to include functionality already provided by caps2esc.

[harmtemolder]

I kind of need the -m 2 of caps2esc on my 60% keyboard. Is there a way to make the the caps part of this plugin optional? I'd love to be able to use space+h/j/k/l...

[maricn]

I kind of need the -m 2 of caps2esc on my 60% keyboard. Is there a way to make the the caps part of this plugin optional? I'd love to be able to use space+h/j/k/l...

@harmtemolder OK, I pushed my WIP branch that is more structured. I want to run it for a day or two before merging to mainline branch to make sure I didn't introduce any bugs, but you may try it out on this branch: https://github.com/maricn/interception-vimproved/tree/ivimp-1-generic-key-definition.

For configuring which keys to be used, check out https://github.com/maricn/interception-vimproved/blob/d142702644267c83a3ba5aa3fa591121f9217819/interception-vimproved.cpp#L378 - just add/remove whatever you like.

[harmtemolder]

I commented out lines 390, 391 and a couple of the space lines, ran make installand saved this as /etc/interception/udevmon.yaml, replacing the first line with:

- JOB: "intercept -g $DEVNODE | caps2esc -m 2 | /opt/interception/interception-vimproved | uinput -d $DEVNODE"

This gives me both the -m 2 of the official caps2esc and your space cadet, but when typing fast my spaces seem delayed, arriving 1 character too late. How can I debug this?

[harmtemolder]

I've now removed the caps2esc bits, only running vimproved, but I keep getting the same behavior: spaces are too late. I'll show you by repeating that a little faster:

I've now removedt he caps2esc bits, onlyr unning vimproved, buti k eepg ettingt he same behavior: spaces are too late. I'lls how youb y repeating that a littlef aster

[harmtemolder]

Ran a git restore so that I'm on par with what's on https://github.com/maricn/interception-vimproved/tree/ivimp-1-generic-key-definition. Same thing, so must be something in there, not caused by my changes

[harmtemolder]

Now on your master branch instead, ran make install again: samet hing. Please let me know how I can help debug

[maricn]

I commented out lines 390, 391 and a couple of the space lines, ran make installand saved this as /etc/interception/udevmon.yaml, replacing the first line with:

- JOB: "intercept -g $DEVNODE | caps2esc -m 2 | /opt/interception/interception-vimproved | uinput -d $DEVNODE"

This gives me both the -m 2 of the official caps2esc and your space cadet, but when typing fast my spaces seem delayed, arriving 1 character too late. How can I debug this?

OK, that sounds like what I would do.

I haven't really run it in combination with any other interception-tools, just a bit long time ago, but didn't notice any issues. But can't guarantee there's no conflicts.

Regarding debugging, phew, I don't really have a good process, tbh. I should invest into setting up a test framework for this, but as mentioned in the readme, it's just a side-side-project that I happen to drive daily on my machine, but no QA done on other machines.

I've now removedt he caps2esc bits, onlyr unning vimproved, buti k eepg ettingt he same behavior: spaces are too late. I'lls how youb y repeating that a littlef aster

What looks interesting there is: how youb y repeating - youb is spaced from y, so I guess your keypresses didn't go: SPACE.down, B.down, B.up, SPACE.up nor SPACE.down, B.down, SPACE.up, B.up because this would emit a BACKSPACE. Can you play around with that and let me know the sequence that works?

I often do trials like: A.down, S.down, SPACE.down, A.up, F.down, S.up, SPACE.up, F.up and that should emit a pattern something like: aaaaassssfffff(SPACE) or matching a+s+f+\b{1} if you like regex :).

Now on your master branch instead, ran make install again: samet hing. Please let me know how I can help debug

This is strange, I haven't experienced this on master so far... Probably we should emit some extra SYN keys, but not sure where.. If you could let me know exact sequence of up/down character presses that causes unexpected behavior that would help a lot. And thank you for your interest and offering to debug!

[maricn]

@harmtemolder Also, one unfortunate effect of using a space cadet is that if you emit a sequence: SPACE.down, A.down, SPACE.up, A.up, it will output a because letter keys output on keydown event, while "layer" key such as SPACE in our case mustn't output on keydown event. By [my] definition, it must wait to see if there will be another key pressed that will match a key defined in its layer map.

This causes typing issues while you don't get used to emit very short SPACE keypresses (lifting the spacebar up before pressing down on the next key). I admit it causes slight inconvenience in the start, but I think some form of this issue is present in all implementations of space cadets.

EDIT: There are different design choices that could be taken here, but they all cause some form of a problem. For instance, I went for not using any timers to expire the modifier/layer keys, nor any timers to ignore the letter keypresses after the SPACE.down. I tried both variants, and it actually produced more artifacts than the one that I implemented in the end.

EDIT2: Also, please take a look at Correct synthesization of event sequences at Interception Tools project. As stated previously, I recklessly don't send EV_SYNs and emit timeouts as they produce unexpected results with my space cadet (I had issues with https://github.com/zsugabubus/interception-k2k, so I wrote my own tool). When you provide more info, I'll look into debugging it, but if introducing extra timeouts for your setup to register order of events is the only way, I think it would make things a bit complicated.

[harmtemolder]

Also, one unfortunate effect of using a space cadet is that if you emit a sequence: SPACE.down, A.down, SPACE.up, A.up, it will output a because letter keys output on keydown event, while "layer" key such as SPACE in our case mustn't output on keydown event. By [my] definition, it must wait to see if there will be another key pressed that will match a key defined in its layer map.

This might actually be the case with what I'm seeing: It only happens when I type fast, so could be that the SPACE.up hasn't registered yet when I'm already pressing A.down...

What looks interesting there is: how youb y repeating - youb is spaced from y, so I guess your keypresses didn't go: SPACE.down, B.down, B.up, SPACE.up nor SPACE.down, B.down, SPACE.up, B.up because this would emit a BACKSPACE. Can you play around with that and let me know the sequence that works?

I actually commented out line 336 when I typed that, so no B to backspace, sorry. So let's try that again:

1. I'm on master
2. make install
3. systemctl restart udevmon (set up to only run vimproved, no other Interception Tools)
4. That took some fingerbending, but: aaaaaassssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssfffffffffffffffffffffffffffffffffff
5. Wait, after these steps B still doesn't work. Am I missing something and am I still on the ivimp-1-generic-key-definition branch?

[maricn]

5. Wait, after these steps `B` still doesn't work. Am I missing something and am I still on the `ivimp-1-generic-key-definition` branch?

@harmtemolder Are you sure your make install finished successfully? You might need to shut down (stop) the udevmon service that's using the binary at /opt/interception/ so it can be installed over it.

[maricn]

Closing due to inactivity. Please reopen if the same issue happens again, or create a new issue.