bester42 wrote:Only ´`^ are supported by German OS-layout, so everything else requires a macro, simmulating keypresses for an unicodecharacter.
As I said - not the most urgent problem to me, as it would be only needed for full neo2 layout with company-PCs without administration rights. A verry special case.
Sure... I'm just thinking about how these things could work, it might be quite some time before I actually implement any of them!
bester42 wrote:If I understand right, without POP_ALL_META the modifiers set in a macro will stay alive until the modifierkey is pressed and released again. So SET_META lshift in a macro without POP_ALL_META at the end will work like capslock on some old typewiters. If you remap caps_lock to functionkey24 and call a macro on functionkey24 setting lshift, a press on caps_lock will activate shift and only pressing lshift will deactivate it.
PUSH_META and POP_META should occur in pairs. They manipulate a stack of saved meta states, so if there are more PUSH_METAs, the stack will overflow! POP_ALL_META is a shortcut to clearing the stack - think of it as 'pop all (saved meta states)', rather than 'pop (all meta)', since it acts like a sequence of POP_META commands. Almost always the PUSH_META and POP_META will occur within the same macro, with the only (rare) exception being to have a PUSH_META in the make clause, a POP_META in the break clause, and the 'norestoremeta' flag on the break clause.
To make a sticky shift lock as you describe, just don't use the PUSH_META command
bester42 wrote:Same would be with virtual modifiers. A keypress can directliy set the modifierstate (via remaptable) or call a macro activating the modifier, deactivating it or tongle it. Of course using a virtual modifier to make deadkeys is somehow more complicated - the deadkey calls a macro to set the modifier and any(!) other key has to call a macro with deactivating the modifier in the end (argh and two modifiers on the same character... upps something to think later...).
If I understand right, only the first macro matching is procedured. Maybe doing all matching macros will be an easy solution in the order they are written in the config. So to make a deadkey, the keys activating a virtual modifier are down the list of macros, if you want to reset a key after one following character, you simply put a macro before it deactivating the modifier if its set.
"Mody01 to Mody32" was a little joke, but after it I thought it over: "Mody00 to Mody15" would be realy nice - 4 independend modifiers "ModyA-ModyD" making 32 combinations, so instead of "ModyA -ModyB -ModyC ModyD" a Mody09 would do for good reading.
Maybe different types of macro would be more simple for complex solutions:
- like it is now (first matching, no automatic saving and resetting modifiers)
- automatic embedded (first matching, automatic saving and resetting modifiers)
- done if its conditions fit - even if other macros have been done before
This are just some ideas I had. Virtual Modifiers would be usefull in many more cases than Deadkeys (if an other "layer" meens not a remapping like switching between qwert / neo2 /dvorak but to call another set of macros or enabling "locking" by pressing right and left modifier together).
I may have to read that section again, but I think some of these features go too far beyond what a keyboard should do
Trouble is, only certain ways of doing things can be made totally reliable. Simply tracking which keys are up or down becomes unreliable if two keys produce the same code - press both, release only one, but the code thinks neither are pressed... damn!
I can't really see the need for virtual modifiers, in the form you're currently thinking of. I think the dead key solution I outlined is reasonably self-contained and can be made reliable quite easily. For other uses of virtual modifiers, using the Fn keys to access layers would achieve similar functionality (once I allow triggering a macro based on the layer). So the only part missing from virtual modifiers is being able to set them from a macro, and I'm struggling to see the need (apart from the specific case of dead keys). Perhaps some other mechanism could be just as useful, but without examples of what it would allow people to do I can't think what that might be!
Layers are not for switching between say qwerty / dvorak etc, that is what 'ifselect' is for. Layers allow you to remap to a different key depending on the Fn keys - for example, people have used it to have F1 to F12 available by pressing a Fn key with keys on the number row.
The key thing about reusing the Fn keys as virtual modifiers would be that you can already set it up so there is a left and right key accessing the same layer, but from different FN keys. So it would also be possible to trigger a macro from pressing both FN keys (once I implement layer match in the macro trigger, and also pass FN key codes through to the macro stage).
I'm almost certain to change macros so they have a PUSH_META and POP_META by default, with a flag to remove them. However, I think it should still be that only the first one matched is executed, because I think allowing the alternative is very hard to write good (predictable!) configs for.
.
