Make a PR of this and push it. That'd be easiest way to help you I think.

I feel like this is thinking about it strangely... I think we just need to make it easier to control the "Return to parent":

C("Alt-Grave"): {
    Trigger.onEnter: C("Grave"),  # ` Leave accent character
    C("Alt-Grave"): [C("Grave"), remain_here_dont_return_parent],
    C("A"):  UC(0x00E0),  # à Latin Small a with Grave
},

You're getting there. Have you done any Exercism or other Python exercises lately? You just need to pass the whole device now:

def on_event(event, device):

We don't need a default - device is mandatory... then later if you need name or path you just get them from device... piece of code that need access to LEDs (KeyContext) you can pass down the full device object... piece of code that don't you just change to reference device.name instead of the older variable, etc....

tabindex="0" just means that it will follow the natural flow of the DOM.

Ah, right. In that case this seems a reasonable default.

It doesn't steal focus, it is just inserted into the list of tab-able items in the DOM.

Yeah, I was forgetting the behavior of 0...

I was asking if you can screw up the state of leds by unplugging and replugging regular old keyboArds.

Individual examples of these 3 things and how they might be used and behave would be helpful. Just looking at your last code snippet I have no idea what either is supposed to do exactly..

The other thing is that the OS does seem to keep the lock key states latched to be the same no matter which keyboard ... You can turn a lock key "on" using one device and then "off" using a different keyboard. I don't think these keys were ever intended to be used independently "per device".

Thanks for this research!

I tried to import the relevant class into key_context so that it could report the LED states there, but can't get the import reference to work.

I dunno what you mean... look at tranform.py lines 296-302... every time a key is hit we pass in the device name, and device_name is passed to KeyContext directly... if you need the whole device, just stat passing the device to on_event instead of the device_name... then you'll need to switch to device.name in a few places... and you'll now have device right inside KeyContext where you want it.

Can you confirm behavior with REAL physical keyboards? I mean stopping keyser is essentially unplugging a keyboard... I wonder if perhaps this is more of a kernel bug/issue than our problem (even if we might need to solve it)... We don't do anything in particular to change the LED states on close.

If Highlight.js is powering Chrome's debugger view that would come as a big surprise to me... so I have no idea what theme they are using - probably one of their own devising.

We have a TON of existing themes though - did you flip thru them all to see if there was anything similar?

New themes are always welcome: https://highlightjs.readthedocs.io/en/latest/theme-guide.html

Are there any downsides here? Does this now make all code snippets "steal focus" if someone starts tabbing and they all have scrollable regions? Are there cases where someone might want tabindex=1000000 instead or to custom configure the index?

https://highlightjs.readthedocs.io/en/latest/building-testing.html

https://github.com/highlightjs/cdn-release/tree/11-stable

See https://github.com/rbreaves/kinto/blob/master/linux/xkeysnail.service

You need to use xhost from the current logged in used to grant the keymapper user permission to access your X session.

/usr/bin/xhost +SI:localuser:keymapper

I think?

Please add some general information about your environment:

• Operating System - Linux
• Sublime Text version - lattest
• Details about your config e.g. do you use rbenv, rvm or your_own_command to run rubocop? rbenv

Steps to reproduce:

• modify a file and save multiple times
• the linkt hints never change

They only change if I manually choose "Check current file" in which case it works fine. The console doesn't seem to have any logs or errors.

Maybe su first. Then once you already have a shell prompt as key mapper try running it?

It's gonna be something really stupid simple. And it looks like bash is throwing the error, not keyszer.

XML is already aliased to HTML if you check supported languages.

What is the full content of local bin keyszer?

What is the shebang line? Does it exist on your system?

xml

Yes, these input devices are secure pieces of the system. You need to run the command within udev - which should already be running as root.

Sudo should work though but it'll just break after you reboot.

Once you get the permissions correct are you running keyszer as the keymapper user?

Did you setup and test your udev rules?

Fix typo (#73)

Changes

Checklist

• [ ] Added tests (if necessary)
• [X] Updated README...

using textContent preserves spaces but still strips newlines.

Please provide a jsfiddle demonstrating this and I will review.

Please open an issue against my repo if you'd like support. Thanks.

PR for the typos would be great.

It's the APIs you are using. Use textContent instead of innerText.

I also multi-map my pipe key to Hyper (for the right hand side), but it's still a bit buggy - haven't found the time to track it down yet.

I write the following config and it works fine

Yep, looks reasonable to me.

Make Emacs doesn't respond right ctrl

My fork keyszer allows you to define custom modifiers... so you could choose a key you're never going to use, declare it a REAL modifier and then multi-modmap semicolon to that... then keymap your custom modifier... without "cutting in" on any of your real modifiers...

I do this myself to create a Hyper key for all my Window Manager stuff:

https://github.com/joshgoebel/keyszer/wiki/Hyper

Then I modmap capslock to Hyper/F24 since I have no real F24 key.