According to Michael Kaplan's blog, it should be possible to have chained dead keys in KLC. With chained dead keys, it is possible to implement a compose key for Windows. But when I follow the instructions in the blog, I get the same error as Ralph Hancock (the last comment)...
Does anyone here get it working?
Create advanced keyboard layouts in various formats using my Keyboard Layout Files Creator!
Explain exactly what you mean by "chained dead keys" and give an example.
Perhaps this can be done in AHK
Ok heres the example from the link:
''u -> ű
''U -> Ű
''o -> ő
''O -> Ő
'' -> ″here's the AHK code:
:*?:''::
Input, key, L1
if (key == "u")
Send, ű
else if (key == "U")
Send, Ű
else if (key == "o")
Send, ő
else if (key == "O")
Send, Ő
else
Send, ″
returnWith PKL, you can chain dead keys to your heart's content. I've used that for some nifty tricks (for instance, dk_math+< is ⊆ but dk_stroke+dk_math+< is ⊈ – on my layout that's {AltGr+/, AltGr+=, comma key}). Unfortunately, you'll have to remember to define the combo both ways for robustness.
The trick is that dead keys nest. So while the first dead key waits for a releasing input, you may hit another and then another and a release key – and the resulting glyph will be sent up the stack of waiting dead keys. Nifty.
*** Learn Colemak in 2–5 steps with Tarmak! ***
*** Check out my Big Bag of Keyboard Tricks for Win/Linux/TMK... ***
Thanks both of you, but the solutions aren't perfect.
The AHK script does what I want, but I rather use KLC or PKL.
The nested dead keys in PKL are indeed neat, but it isn't powerful enough to enable a compose key. For example, it isn't possible to get '→' when 'Compose, -, >' is typed, unless '-' is a dead key. But in that case the sequence 'Compose, <, -' to give '←' isn't possible...
Create advanced keyboard layouts in various formats using my Keyboard Layout Files Creator!
The AHK script does what I want, but I rather use KLC or PKL.
Yeah I understand you don't want extra apps if not necessary. But PKL is just an AHK script too
Indeed, PKL is "just" an AHK script too, but it holds so much functionality that some of us like to use it. And you can't use both PKL and another keyboard hooking AHK script simultaneously, so you'd have to choose one or the other.
Writing a proper compose key into the PKL code would be possible. Doing it elegantly is hard, as the method misterW shows above would get very clunky for a large compose table.
*** Learn Colemak in 2–5 steps with Tarmak! ***
*** Check out my Big Bag of Keyboard Tricks for Win/Linux/TMK... ***
And you can't use both PKL and another keyboard hooking AHK script simultaneously, so you'd have to choose one or the other.
You've said this before. Are you certain about that? Because I've used AHK for quite a while and never heard of this limitation. Can you describe an example that you think would fail?
You've said this before. Are you certain about that? Because I've used AHK for quite a while and never heard of this limitation. Can you describe an example that you think would fail?
I've tried to use BigCtrl with PKL, and it doesn't work.
Just try running PKL simultaneously with a standard AHK remapping script. They'll compete for the keys unless I'm mistaken, the one that started last gets the hook iirc.
*** Learn Colemak in 2–5 steps with Tarmak! ***
*** Check out my Big Bag of Keyboard Tricks for Win/Linux/TMK... ***
Oh if both scripts are trying to control the same key, then yes, but I would expect that to happen with any two 'remapping' programs, whether AHK or not.
I think it affects any key. The "dominant" script gets the results from the keyboard hook (and may pass them on into the input stream), but the other instance doesn't because the input gets "unhooked" then. One might write AHK scripts that circumvene this I suppose, but then it'd require extra coding which I wouldn't know how to do.
In AHK you just ask for a (low-level) keyboard hook. I suppose it runs as some sort of low-level service? And it seems that there can be only one; maybe AHK will overwrite the first hook instance with the next, and it isn't configured to make (or Windows may not allow?) multiple hooks of the same type with different IDs?
*** Learn Colemak in 2–5 steps with Tarmak! ***
*** Check out my Big Bag of Keyboard Tricks for Win/Linux/TMK... ***
I think it affects any key. The "dominant" script gets the results from the keyboard hook (and may pass them on into the input stream), but the other instance doesn't because the input gets "unhooked" then.
Can you give me an example of what you mean? I just created two scripts: one with keyboard hook hotkey for the letter 'a' , and another script for a keyboard hook hotkey hooking the letter 'b', and both worked. So I'm not following..
Ah, tricky. Could it be different when one or both scripts are compiled instead of running off the AHK.exe? I don't remember exactly under which conditions this is and isn't a problem, but I remember that back in the days when PKL was still actively developed many people complained about running it with other remapping apps ("remapps", heh?). And the competing-hook theory, while never proved explicitly I think, was seen as a likely explanation for these phenomena.
*** Learn Colemak in 2–5 steps with Tarmak! ***
*** Check out my Big Bag of Keyboard Tricks for Win/Linux/TMK... ***
