Queue and dispatch events for fixes and having gorgeous features

[Thanatermesis]

I was trying to configure the layout and I have just encountered a very annoying issue: it makes other keys to be wrongly typed, like:

Use case example:

I have set the "<" and ">" to unique/single keys, because they are very used, specially for xml or just write a small html chunk, I had always difficulties to type those chars in other layouts because they are not very friendly and so slow to type a small chunk of html content

Then i tried to play with some <ul><li> in my ergodox to see if they are friendly to type, and then I noticed something: I got things like:
<Li> and <Ul>

Why this happened? because seems like the < and > chars are in the code a hack that makes use of the shift key, so a normal person when types fastly in the keyboard (and not so fast, just normal typing), most of the times you don't finish to release the key before to press the next one, and this will generate a "not yet released shift" when you have pressed the next one (note: I'm mostly speculating what the code does)

Then I said "oh my god, again this annoying issue" (I had a similar problem typing ":wq" on vim with my os-modified layout: https://github.com/Elive/programmerskblayout , i was so much annoyed by it that I have even needed to write a map in my vim conf to correct it), anyways...

Solutions

The first thing that come to my head: we need a generic-for-everybody driver to install in the OS where it is assigned an "ergodox layout", country/language-agnostic, where the ppl can configure his layout in any language - too much painful, difficult, time and work.

Then I realized another solution:

The super-dupper queue and dispatch smart manager !

So let's think the idea about something like this:

• Each keypress is sent to a queue waiting to be dispatched, which will be inmediately sent to the computer if there's not a special meaning assigned to it, for example: if you press a "marco-shifted-mode" key like <, and before to have released it you press another normal key, the dispatcher makes sure to first release it before to mark as pressed the next one

This can perfectly solve the issue!

(And then an universe of new ideas blinked in front of my eyes)...

So what about new horizon of possibilities ? See those nice ideas:

• dead keys: this can allow to make functions for really-dead keys (that acts like), so you can make the key to not be sent to the computer until the next one is pressed (to generate a special one)
• one-touch layered keys mode (like dead keys): if you press a layer key (ex. L3) and release it (instead of keep it pressed), then you press another key (ex. "m"), then it will be sent the "m" equivalent-key from the layer 3 -- this improves in speed and ergonomic health by not stressing the wrist when pressing more than one key at the same time
  • friendly example: you have layer L4 set to "media keys", so you hit the media key and then (after to release) you press the key "n" which means "next song"
• special combos:
  • if you press three times the backspace key you will have 3 chars deleted, but instead you can say in the dispatcher that if this key is pressed three times it should send the combo "shift + home + backspace" (will delete everything from-cursor to start-of-line)
  • note: this could include a "lag" of not send anything to the computer until it knows that the next key is or not another backspace, but it can also dispatch things instantly and then trigger the combo in case that this step was reached
• replacements: similar to the previous idea let's say i write emailsignature1, a function that is defined to replace this will count the number of characters to send the same amount of "backspace" to delete the word and then type a chunk of text that you commonly use for sign your emails --> this can be a friendly replacement of "remember all your keys in all the layouts of your keyboard"
• Create infinite layers: A small problem that I have see is that I want to set all of my keys in the first layer to be able to have all of them, but then i have no space for set the ones assigned to the layers, so I have now in my draft "only" 6 layers, i dont see the way to have more than sacrificing other keys, using this dispatcher idea you can configure things like:
  • if i press the key L1 and then L2 (one after the other or at the same time) then I go to the layer L3 --> (L1 + L2 = L3, easy to remember)
  • if I press L2 twice I go to L4
  • if I press Lx "a layer trigger" and then the number 9 I go to the layer 9
• OMG how much ideas can happen with a dispatcher! I should stop thinking NOW! :)

Note that these are just ideas of possibilities, I don't mean that we should have all those features but making the keys work on a queue/dispatcher way can allow all those possibilities to exist, and with a few entries (or just a copypaste of these ideas) in the documentation there would be eventually people that would write nice features like these listed ideas :)

[Thanatermesis]

Some cc: @almul0, @sandraliarte

[bmedicke]

I just finished my first ErgoDox today (damn, those SMDs are small). I'm already annoyed by the shifting of subsequent characters when using dedicated keys for shift based symbols. Great idea.

It would be nice to introduce a timeout to counteract the mentioned queue lag. Maybe something similar to vim's timeoutlen.

[Thanatermesis]

The most annoying here is when you do something like the most used vim keystroke: :w , since the double-dot is a shifted one you press accidentally :W

[Thanatermesis]

For me it sounds like the only problem for not release the key before to press the next one is the -possible- need of having the key "still typing", for example if I press ":" without release i get "::::::::::::: etc". So I think that the small issue of the shifted keys (should be reported in another github-issue imho) can be easly fixed by releasing the key before to press the next one IF we press a different key than the actual one (or in an easy way, if we press a non-shifted key), maybe with a simple variable flag somewhere