I am surprised to see no changes to the top row of 1-0. Can we just get rid of the number keys and put them in a numpad format on the side? Sequential numbers on the top are (arguably) worse than numpad.
Not to say that I think it's particularly practical, but there is a somewhat well-established "40%" keyboard design that doesn't have a number row. They typically rely heavily on modifier keys or layer switching.
I have used a 60% for the past 4 years or so, and have found it to be just fine for daily coding. I use VIM keybindings in my text editor, so my navigation keys are on home row and I don't need them (for non-VIM contexts, I just use FN+WASD, which is pretty effortless). I also mapped Caps Lock to ESC, since I never need that anyways, and it's more efficient. I don't think that the F-keys or Home/End/Pgup/Pgdn cluster are really critical for coding (plus the F-keys can be emulated with FN+numkeys). Obviously, some editor bindings may require those keys.
It really seems to me like the only thing you lose with a 60% is the arrow keys, and you can always go to a 65% layout if you need them. I use a 40% Planck for a while, and honestly didn't really like it much (got some strain in my pinky after a while).
> my opinion is for serious coding it's inefficient to go smaller than that.
I'd say it depends. With a "normal" layout probably true, however I found I am at least as quick with programming on my ~45% keyboard.
Mainly it's because I moved all the special characters and arrow keys down to the letters on a secondary layer. That allows me to enter anything without moving or stretching my hands, which I find very pleasant and at least feels very efficient. The layers are switched with thumb keys, so they're always accessible quickly.
For me it was the best approach(especially compared to Dvorak, Colemak etc.) because it's still fully compatible with Vim and other programs without needing to relearn and reconfigure everything.
Although I must admit when I'm typing on a qwerty keyboard I always need a few minutes to get used to it again.
Any layout that changes the positions of letters is super unpractical in my opinion, as it first requires many months of practice to get back to speed and then it's incompatible with many programs like Vim. Also typing on any other keyboard becomes a nightmare.
I'm using them all the time for entry and shortcuts. Cmd + 1 for switching to the first tab/item/thing.
Even bought a tenkeyless gaming keyboard. I was having the opposite thought that we should deprecate the number pad and just leave it as an additional hardware add-on for accountants
I've heard that pre-computer typewriters actually required the ‘shift’ key pressed for numbers, and had symbols available without ‘shift,’ so numbers as primary symbols in the top row are an invention of computer engineers. Though looking at photos of typewriters suggests differently.
You can switch the shift-behavior with some software, e.g. Karabiner for Mac.
You can also use Programmer Dvorak, where you have to use shift to type numbers instead of symbols and the numbers are laid out as in Dvoraks original keyboard, so that the index fingers are typing the most common ones 7531902468
I tried a custom layout that did that for a while. I put the arrow keys in the centre (Qwerty's y, g, h, b), I think along with some other usually far away things. Then the letters needed to extend up onto the number row, so I made the function keys the numbers, and the numeric keypad the function keys.
I used it enough to touch type at a decent speed, but I didn't keep using it for long, as at that point I was better off avoiding keyboards entirely.
Numbers only on the numeric keypad would be awfully inconvenient for programming.
As a lefthander I find using the numpad difficult as it is on the wrong side on standard keyboards. As I use more than one machine daily, having a custom reversed keyboard is not an option. As such I basically never do number entry using the numpad.
"I used a series of articles from various online media. I don't have copyrights to provide them with this project, so you will have to use your own source."
and
"Create the text folder and fill it in with *.txt files which you'd like to use as the test data source. "
It would be interesting to see what a layout full of source code/terminal history would generate - although you'd have to take into consideration all variety of autocomplete functionality (tab key usage) in text editors to get accurate input data, not to mention window switching shortcuts etc.
Yes, would be very keen to see what sort of result you'd get if (say) you captured keystrokes directly from a collection of engineers (or indeed a broad variety of individuals)
Might be trickier though, as I anticipate you'd need to somehow semantically separate the keystrokes into logical units. Maybe just a time-between-strokes threshold would be enough?
In the era of swiping keyboards, Touch Bar technology, and hyper keys, it would be interesting to see an expanded project. For example, what is the optimal position and size for a dynamic OLED touch interface on a keyboard? Which keys should do something different when held? What chords are worth putting on a keyboard? It would be especially interesting if usage over time and the cost of relying on a specialized environment were factored in.
And how about software that watches you type and suggests a more keyboard-heavy workflow as your speed increases?
Interesting, but it suits the marginal user. Ideally, I'd want to analyze my typing patterns to tailor to that (that is, a Bayesian solution where I can supply my data)
I always thought splitting the keyboard and number pad so I could put the mouse in the middle would be a great optimization. Finally did it last year and ended up with tennis elbow. Turns out having my mouse pad a good distance away from the keyboard gives me a chance to stretch out my arm. That tiny bit of extra movement was crucial in not pushing my body over the limit of too much tiny movements resulting in elbow/arm pain.
There are other contributors like using my phone too much in the evenings. But for sure, the keyboard change pushed me over the edge. I now view micro optimizations like this slightly differently. Maybe this keyboard layout would be great! But I sure would pay more attention and watch for negative side effects now.
Would be curious to see what happpens if we let an optimizer go wild with tye keyboard structure as well. For a while, I've been wanting to try a Dactyl:
> Would be curious to see what happpens if we let an optimizer go wild with tye keyboard structure as well. ... But I wonder if the space of possibilities contains some wacky hidden gems
These "wacky hidden gems" are not at all that wacky or hidden. Any future "AI" keyboard won't use typical letters or symbols, it would capture strokes that convey thoughts or meaning. We already have this to some degree with mobile keyboard software that turns gestures into commands and swipes into words and predictive sentences.
Considering that fingers rotate on joints instead of extending forward, and don't crook to the side while doing that, the Maltron/Kinesis/Dactyl shape and ortholinear layout are pretty intuitive. It's flat boards and the typewriter-inherited staggered layout that don't make sense in the age of plastic.
The thing about computer generated layouts (as with all computer optimizations) is that it optimizes an evaluation function and not the actual process of typing. And who knows how closely your function that scores how good a keyboard is matches the physics and physiology of typing.
And why do people use pieces of perfectly written text. The Backspace key is like one of my top 5 most used keys and it's always under the pinky.
If you were to read the OP, and especially follow the links to the articles the author has written about the development process, you'd see that these shortcomings are exactly what Halmak is trying to address.
> you'd see that these shortcomings are exactly what Halmak is trying to address
It’s still all dependent on how good the authors physiological model is. If their model of hand movements is incorrect, then any generated results will be incorrect, too. For instance: the author talks about developing a model of travel distance for various keys. Fine, but (a) it’s based on their own hands, so it might not be a good fit for others, and (b) the distances are all from resting hand position, which means that as your fingerS move over the course of typing a word, those distances should adjust as well. Does the author account for this? I don’t think so, but it’s not clear.
My larger concern is that human muscle movement involves a whole lot more than just the mechanical aspect. Any model that doesn't include some notion of human perception, cognition, and voluntary muscle control seems like it could be optimizing with the wrong evaluation function.
I actually feel the other way; the cost of learning a seemingly arbitrary layout is probably less than the cost of using an inefficient layout, in the longrun.
> the cost of learning a seemingly arbitrary layout is probably less than the cost of using an inefficient layout, in the longrun
It might be—but that’s no consolation if you’re less likely to get to the long run. Or if you get to the long run, find out their models were off, and realize it was extra time wasted.
Reading through his blogs, he keeps saying that one of the advantages of his layout is intentionally alternating keys between hands, and slags colemak for being "really bad" at that.
But when I was reading up about the colemak, they claimed that was done on purpose -- that in fact, at high speeds, coordinating alternating keystrokes between hands is very difficult, and that it's actually a lot more efficient to have "rolling" patterns where a single hand can type a sequence of characters in a smooth motion. I can definitely say that the "inter-hand coordination" is the source of an awful lot of my typing errors.
Made the same observation! And the rolling patterns are better if they go from in the pinkie-to-index direction than the other way around. An example of how Halmak does not take this into account is how the h and t keys are placed. It immediately jumped out at me as a Dvorak user.
The myth of alternating-hand advantage probably dates to the era of mechanical typewriters, when hammers arriving from opposite sides of the machine were less likely to jam.
Alternating hands was certainly better for my hand joint issues. I found Dvorak not really faster, but more comfortable, and the alternating hands is a big part of that. Alternating hands is much better than consecutive keys far apart on the same hand, and way better than consecutive keys on the same finger.
Actually they were more likely to jam. They hit the same place and if you hit a left and right key at the same time, they'd invariably jam, which necessitated going in and manually prying them back free (the keys sort-of fit into each other)
>that in fact, at high speeds, coordinating alternating keystrokes between hands is very difficult, and that it's actually a lot more efficient to have "rolling" patterns where a single hand can type a sequence of characters in a smooth motion.
This seems like a particularly easy hypothesis to test (if I weren't on mobile I would try coding it up).
From a dictionary of words ordered from most to least common, start bagging them into three lists: all right, all left, and mixed.
There are 2 ways to do the next part:
1. When you have, say 30 of each, start A/B/C testing how long it takes to do a random one from one of them (first choose a random number 1 to 3 and then based on that choose a random word from the associated list.)
2. Instead of the above, I prefer to add them all into one big bag, randomize the bag, then pop elements from the bag (without replacement) until you're done, timing how long it takes the user to type each one. Don't look up which list each element was from until you're done collecting the timing information. (By grepping the three lists to figure out where you got it.) This makes things a bit "double blind" in that your user timing algorithm just gets a mixed bag to pop through. It doesn't know the sources.
At any rate, once you do either the first or the second one, you can see if there is such an effect.
It is worth checking via print statements and an iterator variable, how far down your list each one came from, just as a sanity check.
(I could imagine that due to some historical accident in qwerty placement, most of the common words are mixed, and very uncommon ones are the first ones to be done all with one hand. They could be very long as well, something to watch out for.)
Someone doing this in python should be able to complete this in about 20 minutes (if they're not used to saving timing information, and including finding the list of words).
It seems easy to test. The only single-character common words are a and I - I would remove these two words because they'll add to single hand typing speed.
Additionally it may be worth removing the "enter" penalty. (Maybe sending an enter is slower than pressing space.)
Finally, perhaps it is worth seeing how long it takes to type one of the most common 20 words that are all left, all right, or mixed, of a given length. (such as 5 or 7 characters.)
I would have to look and see how far down the frequency chart the words are, to see if the user suffers an "unfamiliar" penalty.
>at high speeds, coordinating alternating keystrokes between hands is very difficult
It's for this reason I believe the traditionally wide spacebar should be split up into a number of different keys. Having two sets of Shift, Control, Alt, and the Windows key on either side of the keyboard seems less sensible than one set that can be accessed by either thumb.
I for example use a custom layout that splits the Spacebar into both Space and Shift. Now I don't have to shift my hands to the left/right to capitalize a letter, make an exclamation/question mark, make a double quote, etc.
Dunno if the author took this into account, but the fingers that do the work also matter: the index and middle finger are considerably stronger than the ring finger and especially the pinky. See e.g. the Workman layout: https://workmanlayout.org, and specifically the illustrative picture: https://raw.githubusercontent.com/kdeloach/workman/gh-pages/...
This also means that Windows/Linux and especially Emacs users are sorely screwed by the prevalence of the Ctrl key in shortcuts. Somewhat ironically, MS' Natural 4000 keyboard with its gigantic Alt keys is eye-openingly great on MacOS where those keys serve as often-used Cmd, right under the thumbs, the strongest digits. And, when Emacs was created, Control was also under the thumbs.
Also, as a bilingual, I'm pining for a design consideration that punctuation is on the same keys between the layouts in different languages.
I almost bought a Kinesis back in 2009 and in the end didn't because of the cost. I eventually got one in 2017 and now I greatly regret not buying one back in 2009. Best computer purchasing decision I ever made.
I was wondering if anyone used different switches on the same keyboard, say heavier ones like mx clears for index and middle, and browns for ring and pinky.
Weirdly, it seems[0][1][2], that the layout doesn't do particularly well by Carpalx's keyboard effort estimator[3], as it gets a total effort score of 2.260, compared to 3, 2.098 and 1.842 for Qwerty, Dvorak and Colemak, respectively[4] (lower is better). In contrast, the halmak repo claims[5] an efficiency gain of +134% over Qwerty for halmak, compared to +77% for Dvorak and +84% for Colemak. Since (one would assume) efficiency and effort should be approximately inversely correlated, these results don't square.
I have no idea whether Carpalx's or Halmak's keyboard layout (efficiency|effort) evaluator is more accurate (indicative of real (efficiency|effort)), but the huge disparity between the two is troubling.
(Obviously, Carpalx and Halmak use different optimisation methods — Monte Carlo simulated annealing versus an "evolution algorithm based AI" — and these could well give different results, even with the same scoring method, due to getting stuck in different local maxima etc., but the issue is that the scoring methods themselves give different rankings of fixed keyboard layouts.)
Edit: quickly reading through all of the halmak author's blog posts, it seems that they're aware of the Carpalx project. They describe their (current?) effort model here[6]. It seems heavily data-based, but it's still difficult to determine whether it's "better" than Carpalx's.
Neat project, I've wanted to give it a try for a while but never got around to do it, great job !
Interesting that it put the comma at the same place as the bepo [1] ! It obviously recognized that vowels should be placed on the home row on a single hand, it has it on the right hand when dvorak/bepo have them on the left hand.
It'd be interesting to train it on code as well and see where it positions the special chars. I personally really like the bepo's choice of putting them on alt_gr+[right_hand_key] as it allows me to reduce finger stretches to hit them, that's what was causing me pain on QWERTY, especially with js, and convinced me to make the move to bepo. I fins lisp is BY FAR the healthiest language when it comes to fingers, though you do need shortcuts to manipulate lisp code sanely.
Is the keyboard-gentrics [2] src code the only way of knowing how this was designed ? I've skimmed the github page and blog it links but cannot find anything. It looks like its a genetic algorithm ?
As a software dev, the biggest gain for me was incorporating the arrow keys under my right hand fingers via a layer switch, and having movement modifiers under the left (jump word, end-of-line etc).
I think one moves around so much in code that anythng else is micro optimization.
I switched to a Kinesis advantage some years ago, and the arrow keys are such a massive improvement.
I was thinking about using layers like you suggest for movements, but outside of vim where you need to shift+move to select text, isn't that going to be quite awkward?
I see yours allows for 300 keypresses in macros, that's pretty cool. I'm using the Vortex Pok3r, it only allows for 32, which is 99% okay, but I did run into this limit.
On the other hand, how do you access the macros? I can't see any special keys on it, except for maybe the `progm` key on the top right, but it is out of reach.
On the Pok3r, I have remapped the CapsLock key to be the layer modifier key, so while it is pressed, the special macro layer is active. I barely need the Caps key, so it is a minor annoyance to have lost it, but the gains are way bigger. That way, I'm using IJKL as my arrow keys. I have remapped Space to mean Shift, thus while it is pressed, I can select anything while moving around with the arrows. Also, I remapped F to Ctrl for jumping words (I'm on Windows, F stands for Fast :P). U -> start of line, P -> end of line.
It's sure not as powerful as vim, but the fact that this is available everywhere, even while I'm typing a comment on HN, totally outweighs it for me.
So nah, it's not awkward for me. Or does it come across like that?
For anyone is interested, if you are on Windows, you can write an Autohotkey script to emulate this, although it will be buggy because of key shadowing (google if you don't know what it is).
I can even send my script to anybody interested to try it out. But you will really need a proper keyboard for this to work where each key has its own dedicated wire.
It looks like this makes q easier to type than w, which seems a bit strange, and wh seems particularly awkward. "What", "where", "when", "why", and "who" are all pretty common.
What I find the weirdest with all these "efficient" keyboard layouts is that seemingly none of them ever move things to/from any of the Ctrl/Alt/Shift keys.
E.g. I find that for me, reaching for the Shift key majorly contributes to slowdowns and fatigue.
If you're going to go through the effort of redesigning a faster layout, why not fix everything from the ground up? Why design a layout with key stagger still a property when we all know that it was a relic of technological limitations that are not nor will ever be present in any future keyboards?
61 comments
[ 0.30 ms ] story [ 152 ms ] threadSome issues and questions:
- Many notebook keyboards will not accommodate a number pad.
- What is the plan for !@#$%^&*()_+ and "~"?
- Where will the backspace key be located?
Here's an example:
https://www.amazon.com/dp/B01MS3PWS0
If you're interested in different keyboard sizes:
https://www.keyboardco.com/blog/index.php/2017/08/full-size-...
I personally use 75%, my opinion is for serious coding it's inefficient to go smaller than that.
It really seems to me like the only thing you lose with a 60% is the arrow keys, and you can always go to a 65% layout if you need them. I use a 40% Planck for a while, and honestly didn't really like it much (got some strain in my pinky after a while).
I'd say it depends. With a "normal" layout probably true, however I found I am at least as quick with programming on my ~45% keyboard.
Mainly it's because I moved all the special characters and arrow keys down to the letters on a secondary layer. That allows me to enter anything without moving or stretching my hands, which I find very pleasant and at least feels very efficient. The layers are switched with thumb keys, so they're always accessible quickly.
For me it was the best approach(especially compared to Dvorak, Colemak etc.) because it's still fully compatible with Vim and other programs without needing to relearn and reconfigure everything. Although I must admit when I'm typing on a qwerty keyboard I always need a few minutes to get used to it again.
Even bought a tenkeyless gaming keyboard. I was having the opposite thought that we should deprecate the number pad and just leave it as an additional hardware add-on for accountants
You can switch the shift-behavior with some software, e.g. Karabiner for Mac.
https://www.kaufmann.no/roland/dvorak/
Available on Linux with
I used it enough to touch type at a decent speed, but I didn't keep using it for long, as at that point I was better off avoiding keyboards entirely.
Numbers only on the numeric keypad would be awfully inconvenient for programming.
Keen to know what sort of typing samples he used - was it mostly people writing prose, operating shells, other?
Imagine you'd need a fairly large and varied sample set to land good generality?
"I used a series of articles from various online media. I don't have copyrights to provide them with this project, so you will have to use your own source."
and
"Create the text folder and fill it in with *.txt files which you'd like to use as the test data source. "
It would be interesting to see what a layout full of source code/terminal history would generate - although you'd have to take into consideration all variety of autocomplete functionality (tab key usage) in text editors to get accurate input data, not to mention window switching shortcuts etc.
Yes, would be very keen to see what sort of result you'd get if (say) you captured keystrokes directly from a collection of engineers (or indeed a broad variety of individuals)
Might be trickier though, as I anticipate you'd need to somehow semantically separate the keystrokes into logical units. Maybe just a time-between-strokes threshold would be enough?
And how about software that watches you type and suggests a more keyboard-heavy workflow as your speed increases?
Far away.
c.f. http://nikolay.rocks/2016-10-22-keyboard-analytics
https://github.com/adereth/dactyl-keyboard
But I wonder if the space of possibilities contains some wacky hidden gems that we are just missing.
These "wacky hidden gems" are not at all that wacky or hidden. Any future "AI" keyboard won't use typical letters or symbols, it would capture strokes that convey thoughts or meaning. We already have this to some degree with mobile keyboard software that turns gestures into commands and swipes into words and predictive sentences.
And why do people use pieces of perfectly written text. The Backspace key is like one of my top 5 most used keys and it's always under the pinky.
It’s still all dependent on how good the authors physiological model is. If their model of hand movements is incorrect, then any generated results will be incorrect, too. For instance: the author talks about developing a model of travel distance for various keys. Fine, but (a) it’s based on their own hands, so it might not be a good fit for others, and (b) the distances are all from resting hand position, which means that as your fingerS move over the course of typing a word, those distances should adjust as well. Does the author account for this? I don’t think so, but it’s not clear.
https://en.wikipedia.org/wiki/PLUM_keyboard
I actually feel the other way; the cost of learning a seemingly arbitrary layout is probably less than the cost of using an inefficient layout, in the longrun.
It might be—but that’s no consolation if you’re less likely to get to the long run. Or if you get to the long run, find out their models were off, and realize it was extra time wasted.
But when I was reading up about the colemak, they claimed that was done on purpose -- that in fact, at high speeds, coordinating alternating keystrokes between hands is very difficult, and that it's actually a lot more efficient to have "rolling" patterns where a single hand can type a sequence of characters in a smooth motion. I can definitely say that the "inter-hand coordination" is the source of an awful lot of my typing errors.
This seems like a particularly easy hypothesis to test (if I weren't on mobile I would try coding it up).
From a dictionary of words ordered from most to least common, start bagging them into three lists: all right, all left, and mixed.
There are 2 ways to do the next part:
1. When you have, say 30 of each, start A/B/C testing how long it takes to do a random one from one of them (first choose a random number 1 to 3 and then based on that choose a random word from the associated list.)
2. Instead of the above, I prefer to add them all into one big bag, randomize the bag, then pop elements from the bag (without replacement) until you're done, timing how long it takes the user to type each one. Don't look up which list each element was from until you're done collecting the timing information. (By grepping the three lists to figure out where you got it.) This makes things a bit "double blind" in that your user timing algorithm just gets a mixed bag to pop through. It doesn't know the sources.
At any rate, once you do either the first or the second one, you can see if there is such an effect.
It is worth checking via print statements and an iterator variable, how far down your list each one came from, just as a sanity check.
(I could imagine that due to some historical accident in qwerty placement, most of the common words are mixed, and very uncommon ones are the first ones to be done all with one hand. They could be very long as well, something to watch out for.)
Someone doing this in python should be able to complete this in about 20 minutes (if they're not used to saving timing information, and including finding the list of words).
It seems easy to test. The only single-character common words are a and I - I would remove these two words because they'll add to single hand typing speed.
Additionally it may be worth removing the "enter" penalty. (Maybe sending an enter is slower than pressing space.)
Finally, perhaps it is worth seeing how long it takes to type one of the most common 20 words that are all left, all right, or mixed, of a given length. (such as 5 or 7 characters.)
I would have to look and see how far down the frequency chart the words are, to see if the user suffers an "unfamiliar" penalty.
Data science and testing are fun :)
Maybe I'll do it when I get home.
It's for this reason I believe the traditionally wide spacebar should be split up into a number of different keys. Having two sets of Shift, Control, Alt, and the Windows key on either side of the keyboard seems less sensible than one set that can be accessed by either thumb.
I for example use a custom layout that splits the Spacebar into both Space and Shift. Now I don't have to shift my hands to the left/right to capitalize a letter, make an exclamation/question mark, make a double quote, etc.
This also means that Windows/Linux and especially Emacs users are sorely screwed by the prevalence of the Ctrl key in shortcuts. Somewhat ironically, MS' Natural 4000 keyboard with its gigantic Alt keys is eye-openingly great on MacOS where those keys serve as often-used Cmd, right under the thumbs, the strongest digits. And, when Emacs was created, Control was also under the thumbs.
Also, as a bilingual, I'm pining for a design consideration that punctuation is on the same keys between the layouts in different languages.
I have no idea whether Carpalx's or Halmak's keyboard layout (efficiency|effort) evaluator is more accurate (indicative of real (efficiency|effort)), but the huge disparity between the two is troubling.
(Obviously, Carpalx and Halmak use different optimisation methods — Monte Carlo simulated annealing versus an "evolution algorithm based AI" — and these could well give different results, even with the same scoring method, due to getting stuck in different local maxima etc., but the issue is that the scoring methods themselves give different rankings of fixed keyboard layouts.)
Edit: quickly reading through all of the halmak author's blog posts, it seems that they're aware of the Carpalx project. They describe their (current?) effort model here[6]. It seems heavily data-based, but it's still difficult to determine whether it's "better" than Carpalx's.
[0] https://gist.github.com/tdegrunt/80e63f464c9a1c336e0f1d4e6aa...
[1] https://github.com/MadRabbit/halmak/issues/4#issuecomment-44...
[2] I haven't done the analysis myself and can't be sure that it was done correctly
[3] http://mkweb.bcgsc.ca/carpalx/?interpreting_optimization
[4] http://mkweb.bcgsc.ca/carpalx/?keyboard_layouts
[5] https://github.com/MadRabbit/halmak#comparisons
[6] http://nikolay.rocks/2016-10-22-keyboard-analytics
Interesting that it put the comma at the same place as the bepo [1] ! It obviously recognized that vowels should be placed on the home row on a single hand, it has it on the right hand when dvorak/bepo have them on the left hand.
It'd be interesting to train it on code as well and see where it positions the special chars. I personally really like the bepo's choice of putting them on alt_gr+[right_hand_key] as it allows me to reduce finger stretches to hit them, that's what was causing me pain on QWERTY, especially with js, and convinced me to make the move to bepo. I fins lisp is BY FAR the healthiest language when it comes to fingers, though you do need shortcuts to manipulate lisp code sanely.
Is the keyboard-gentrics [2] src code the only way of knowing how this was designed ? I've skimmed the github page and blog it links but cannot find anything. It looks like its a genetic algorithm ?
[1] https://bepo.fr [2] https://github.com/MadRabbit/keyboard-genetics
I think one moves around so much in code that anythng else is micro optimization.
YMMV.
I was thinking about using layers like you suggest for movements, but outside of vim where you need to shift+move to select text, isn't that going to be quite awkward?
On the other hand, how do you access the macros? I can't see any special keys on it, except for maybe the `progm` key on the top right, but it is out of reach.
On the Pok3r, I have remapped the CapsLock key to be the layer modifier key, so while it is pressed, the special macro layer is active. I barely need the Caps key, so it is a minor annoyance to have lost it, but the gains are way bigger. That way, I'm using IJKL as my arrow keys. I have remapped Space to mean Shift, thus while it is pressed, I can select anything while moving around with the arrows. Also, I remapped F to Ctrl for jumping words (I'm on Windows, F stands for Fast :P). U -> start of line, P -> end of line.
It's sure not as powerful as vim, but the fact that this is available everywhere, even while I'm typing a comment on HN, totally outweighs it for me.
So nah, it's not awkward for me. Or does it come across like that?
Edit: typo
I can even send my script to anybody interested to try it out. But you will really need a proper keyboard for this to work where each key has its own dedicated wire.
http://www.keyboard-layout-editor.com/#/gists/75c4808455c07a...
(This is my main driver now)
And... What is this website? I can't make any sense of it. Seems to be some powerful configuration tool to do.. What exactly? :D
This site is part of a few that are used to made your own keyboard.
E.g. I find that for me, reaching for the Shift key majorly contributes to slowdowns and fatigue.