Programming layer

Programmer-specific issues and ideas kept popping up in conversation in the Colemak Layout topic. It’s something the community cares about, but it often conflicted with the topic’s goal of getting sensible defaults and labels for the Colemak key set. I wanted to create this space so that we could discuss these programming-related issues. At a minimum, we’ll have somewhere to discuss ideas without derailing other discussions :slight_smile:

Here’s my idea: Perhaps we could arrive at a sensible layer for programmers of the most popular languages, which could come with Keyboardio on day 1, ready to be activated and used. For example, the right palm key could activate the standard QWERTY/Dvorak/Colemak/whatever Function layer, and the left palm key could activate this programmer-oriented layer. Having it as an optional layer means that we don’t need to worry about keycap legends.

I’m particularly curious to hear @algernon’s ideas, since his blog is full of amazing keyboard-related ideas like one-shot, tap-dance, and leader modifiers. He has some interesting placement of programmer-oriented keys like braces, too (the middle of [this post] (https://asylum.madhouse-project.org/blog/2016/09/10/ergodox-day-141/)).

1 Like

For my purposes I treated programming languages like any other language and when I built my layout I did statistical analysis of letter frequencies, rolling characteristics and spreading. The question of balance is always hard but I used the popularity of each language as the weight to determine where symbols ended up.

For general programming purpose use I don’t think there is much of a difference, once people start optimizing for specific languages and IDEs you can see a lot of variety but I don’t think that should be our goal.

Finally one has to establish some sort of ratio between programming and regular typing, if I remember correctly I used a 30% programming estimate but this varies greatly between people.

One last point is that in the aforementioned blog posts it looks like all the scan codes retain their original US English interpretation in the OS, whilst this simple it’s very far from optimal, creating a custom keyboard layout and modifying how the scan codes are interpreted allows for a lot of optimization and simpler firmware using things like dead-keys.

I’m not convinced such a compromise is possible (or if a coding layer is useful at all, but then a number of people seem to like them…), but I wish you good luck. Do keep in mind, that one may well want the most used keys on the primary layer, and that may interfere with prose typing.

This. How much you code, which symbols you use, and how often, is a kind of statistics where it is hard to find some common ground. Language, IDE, habits, style, preferences, experience, and a lot of other factors can introduce great variety even within one language, let alone more than one.

I tried creating an OS layout. On Linux, that is an experience I don’t wish on my enemies. And if I did create a layout for Linux, I’d have to create one for Windows too, because I game there, and sometimes type a few things into chat windows. Not going to happen… And even if it did, I’d have to take the layout with me whenever I go and plug my keyboard into a computer I don’t own. No thanks, I’d rather do everything I can within the firmware, because that makes a lot more sense to me, than the OS side things: its just code, and code is my friend. Cryptic config files are not. It is also portable to any OS that uses the QWERTY layout.

Not to mention that I also change the shifted symbols on some keys, but don’t want that active on every layer: for example, on one layer, I want Shift+5 to input *, but on another, I want it to input its usual %. To do this on the OS side, I’d need to implement layers there, too. Yuck.

For these reasons, while the firmware implementation may not be the simplest, or most efficient, or optimal, it is, by far, the most practical. I like practical things.

Sorry for the rant, but thinking about my experience with OS layouts makes me upset. :frowning:

I’m fairly familiar with that as I use all 3 OSes and maintain layouts for them, if you ever need a baseline including a rudimentary installer for Linux see: https://github.com/antevens/gelatin

It is annoying to have to install the layout but in my layout I use the closest possible combination so that even if I don’t install the keyboard layout I can still use 99% of everything since it’s sending the correct scan codes. Where it will fail is with the internationalization and non ASCII characters.

So my strategy is try to make everything work without a layout but if you want the full experience and full optimization you need to install a custom keyboard layout in your OS.

I’m currently mainly using windows and mac. Linux only via ssh where it seems to work reasonably well with the keyboard-layout I’m using on my client-computer.

I am really interested in what additional software you use on your mac and what kind of a keyboard-layout you implement with them @antevens. Trying to implement two additional layers on my mac worked using a combination of a new mac layout, karabiner and a few tweaks in the mac-os-x setting. At the moment I’m having difficulties restoring that layout tho and it is a nightmare to switch between layouts e.g. if someone else wants to use the computer and just expects a normal layout.

On windows it is much easier thanks to autohotkey which allows you to do virtually everything.

That said I’m currently on the same road as @algernon because it let’s me use my keyboard layout on any computer. Given I carry my keyboard that is ;-).

Hi Michael,

I currently only use Karabiner for things which I can’t map in any other way (power and lock screen), everything else is done in a custom language layout and then in custom ErgoDox firmware.


Note that there are two layouts, one to use for the laptop keyboard (which sends standard scan codes) and one for the ErgoDox (which tries to send scan codes matching the original key presses)

What this means is that it’s easy to switch between US\Canadian English and my own custom layout, just flip hit the language menu in the top bar and switch.
It also means that I can use my custom layout in console and applications that use scan codes directly (VirtualBox/VMWare/Remote Control) when using the ErgoDox.

I essentially do the same thing for both Windows and Linux, one keyboard layout for the laptop keyboard and any keyboard that sends standard scan codes and one for custom programmable keyboards that send the “correct” scan codes for the letter pressed, keyboard layouts included in my Github repo.

Programming layer is something that very much interests me. I am still typing on a regular keyboard, and this will be my first foray into using a programmable keyboard. I have been planning on mapping my Keyboardio to the layout specified here, which is modified Colemak for programming:

https://wildlyinaccurate.com/transitioning-to-a-new-keyboard-layout/

Just an additional perspective.

Although the analyzer you linked to is not perfect it does give a pretty good estimate but sadly the layout that you reference (Colemak with JJT Symbols) scores quite badly compared to the other Colemak layouts. 29 vs 50+ for all other Colemak derived keyboards.

See: Keyboard Layout Analyzer - QWERTY vs Dvorak vs Colemak

I am not sure, but it seems like the setup of the layout may be wrong for the website. I put in a chunk of C# code that I have worked with, and the finger use makes sense, but the heat map doesn’t seem to account for both thumbs being able to hit AltGR.

Maybe I am misunderstanding the score, but it seems odd to me that with dramatically less pinky use, there is such a lower score.

http://patorjk.com/keyboard-layout-analyzer/#/load/QvJKq1Z1

From what I can tell it’s giving a low score based on a couple of things:

  1. It’s only using One AltGr
  2. The thumb is having travel a lot from Space to Enter to AltGr
  3. Even when removing the left AltGr all the extra key presses seem to penalize the layout.