As it states on the main page for Colemak, there's no copyright claims on it and it's Public Domain. See the Colemak License page if you wish. However, do mention Shai Coleman (2006) for his great work! :)

I think the reason I don't want to get me a new piece of more radical hardware is that I want to stay fully compatible with the many keyboards I have to use out there! I can always (well, nearly) get a Colemak option running on those but obviously a thumb button is missing.

Given that, the challenge is to make as much out of the standard hardware as possible. And with Extend layer(s) and various other tricks I do in fact feel that I now have a really good keyboard! Maybe I'm tricking myself out of the last bit of goodness there, but as mentioned - no extra worries at work (where I have several desk places).

Maybe if there were a really light-weight, compact, driverless DataHand I'd consider lugging it around with me! :)

I was able to improve the Cole-e-Shift with the same thing as the ColeMalt: by using just one thumb as shift (for whatever reason that's seen as a slight improvement), and especially adding Enter instead of the right shift.

This depends a lot on the corpus though: With a list of words or triads, which had a newline after each word/triad, KinesisColemak turned out to be the best (that's regular Colemak with a thumb Space and Enter) from all the layouts. Obviously this isn't a very meaningful corpus for most people.

With part of a book text (Alice in Wonderland, which had a newline after up to 70 characters) on the other hand, other layouts fared better:

ColeMalt1 is KinesisColemak (thumb Space and Enter) plus "e" on left thumb, and nothing in the original "e" spot. ColeMalt-A to G are the earlier variants a) to g) with a thumb Enter.

I wonder what a typical day's use of keys is. There's writing mail, IMs, forum posts, web browsing/searching/..., using CLIs, IDEs with various programming languages and so forth. Could be interesting to see the key frequencies averaged over some time of computer use... :)

Alice may be a poor corpus: When typing Through The Looking-Glass, I noticed an astounding number of oddities. Fancy stuff.

I finally got carPalx to run on my machine and played around a bit. Mostly I generated keyboard statistics for layouts of my choice.

Unmodified Colemak:

b                       0.344  18.7  18.7
p                       0.763  41.4 145.1
s                       0.735  39.9 100.0
all                     1.842 100.0 100.0

Details how to read these numbers can be found at carPalx: keyboard statistics.

Kinda off-topic, but I also tested MTGAP layouts because I was curious. Here are their total efforts (compare to the all row above):

• Fully optimized standard keyboard: 2.007 source

• Fully optimized shifted layout: 1.980 source

• Main 30: 2.077 source

CarPalx seems not well suited to analyse layouts that use thumb on a letter. I kinda faked it by adding an extra key in the home row (to avoid penalty of moving away from the home row) which has a base effort of 0 - so essentially an extra home key.

Colemak with e on thumb:

b                       0.344  18.3  18.3
p                       0.763  40.5 145.1
s                       0.776  41.2 100.0
all                     1.883 100.0 100.0

For some reason moving e to that spot increased the stroke component a little. I don't know how to fix this ATM so we'll have to use the layout with e on the left thumb - and no other change - to compare to...

Now let's compare the overall effort (the line starting with all) to the basic ColeMalt permutations:

• DLH: 1.779

• GHD: 1.793 e)

• GDH: 1.795

• Malt: 1.796

• LDH: 1.801

• DGH: 1.804 d)

• LHD: 1.805

• DHU: 1.806 f)

• DHG: 1.837

• HLD: 1.851

• DGU: 1.871 g)

Update: Added Malt layout for comparison.
Update 2: Added DLH and its permutations LHD, HLD and LDH. DLH is this:

qwfp *  j guy;
arst d  l nhio
zxcv b  k m,./
     e  Space

I use a modified Maltron keyboard with a layout I call Dlyz, based on Malt's layout:
43218  90567
=-pucb  kdlyz+
(anisw  gthor)
“'.,f_  qmv/x”
[?;*    j:\]
In case you're reading this with a variable-width font and the layout is visually misaligned, note that underscore and Q are on Qwerty's B and N positions. Space and E are on the right and left thumb home keys, the same as on Malt's layout, and adjacent to space and E are enter and tab. I use a palm key for shift.
Dlyz is more comfortable to type on than Malt's layout. Unfortunately, Dlyz has more same-finger digraphs (including UI, and most annoyingly YO), but also has more laterally adjacent digraphs, more comfortable diagonals (Malt's worst is LO), less index finger stretches to the center columns, less ring finger jumps (e.g. AD or EA on Qwerty), and better finger loading.

I would love to solve the YO problem, but don't know how, without creating something even worse than the YO. With Y over I and U over H like on Malt's layout, there'd be no good place to put L. If there weren't this problem, I would be happy with Dlyz, and would recommend that other people use it too. The UI problem isn't bad, despite Malt's warning not to put vowels on the same finger; I mix up S and C (which are the same on Malt's layout and Dlyz) at least as often as I mix up U and I.

http://www.codesharp.co.uk/dvorak/ appears to be down, so I can't check what it would say about how Dlyz compares to Cole-e and Cole-e-shift, but keep in mind that the numbers that symphonic posted don't show ring finger jumps, which is an important metric. Colemak has a lot of them, mostly from AS, AC, and OU.

I originally posted part of this message to http://geekhack.org/index.php?topic=281 … #msg749462 but this is a more relevant thread.

I use Maltron keyboard for about 14 months. I am a programmer and for programming environment I use Unix shell (bash) and vim editor (almost exclusively) with some other shell utils.

Immediately after buy this keyboard (qwerty 90 model) I slightly modified it layout to be more vim friendly. Modification consist of change electrical connections between some keys. There is modified keyboard below:

As you can see ESC key was moved to be accessed by left thumb. CapsLock was moved to usual place, and blank key was moved to thumb group and mapped as secondary Enter (Del key on left thumb group). PgUp, PgDown were moved to numpad (where CapsLock and ESC used to be). This wasn't easy to do this swap (patience and some soldering experience are need).

Finally (after some research described below) I swapped left Space and Backspace (two blank keys in left thumb group) because it was very uncomfortable to press small Backspace in original place. So now I have big Space on right, big Backspace and small Space on left. The small left Space I use occasionally when my right hand is on mouse (the same with left Enter).

I known about Colemak layout when I start to use this Maltron keyboard, but at start I try learn its original Qwerty layout. It wasn't easy task and I began to wonder why not learn Colemak layout if I can't start to use this keyboard without any learning effort, even in Qwerty layout.

So I configured Colemak layout in X11 and in Linux console and start to learn it. I realized that Colemak isn't well suited for vim. Furthermore, I discovered that I can't press keys on right side of keyboard using left hand, when my right hand is on mouse. I started to think about moving some mouse related keys from the right to the left.

Obviously I've tried some keyboard optimizers/raters to see if my choice is good. At last I found that such optimizers and especially they sample sources aren't well suited for programming. I write my own key statistic application (https://github.com/ziutek/kbdstat) and use it on all places where I work, to see what is the real key frequency, including all keys (ESC, Backspace, arrows, ...).

Bellow you can see the final layout, attached to my monitor (I still use it sometimes when I enter passwords):

It is based on Colemak (home row is identical) with some keys swapped. I use it in this form for about last 6-7 months. During the previous 5-6 months it was slightly modified based on my writing experiences (mainly bottom row). You can easily see which keys have not been changed since the initial layout and which keys are changed more often.

I don't recommend this layout to anybody, but if you plan to buy a Maltron keyboard and you are shell, vim (with mouse) user you can treat this layout as initial start for your modification. In current form it is very comfortable to me, with one exception: sometime I need to use 'Y' key with mouse and I can't because it is still on right side. But I have no good place for it on left side without modify the home row.

For linux users, there is a definition of my current layout for X:

    key <TLDE> { [        grave,   asciitilde,      dead_tilde,       asciitilde ] };
    key <AE01> { [            1,       exclam,      exclamdown,      onesuperior ] };
    key <AE02> { [            2,           at,       masculine,      twosuperior ] };
    key <AE03> { [            3,   numbersign,     ordfeminine,    threesuperior ] };
    key <AE04> { [            4,       dollar,            cent,         sterling ] };
    key <AE05> { [            5,      percent,        EuroSign,              yen ] };
    key <AE06> { [            6,  asciicircum,         hstroke,          Hstroke ] };
    key <AE07> { [            7,    ampersand,             eth,              ETH ] };
    key <AE08> { [            8,     asterisk,           thorn,            THORN ] };
    key <AE09> { [            9,    parenleft,  leftsinglequotemark,  leftdoublequotemark ] };
    key <AE10> { [            0,   parenright, rightsinglequotemark,  rightdoublequotemark ] };
    key <AE11> { [        minus,   underscore,          endash,           emdash ] };
    key <AE12> { [        equal,         plus,        multiply,         division ] };

    key <AD01> { [            q,            Q,      adiaeresis,       Adiaeresis ] };
    key <AD02> { [            y,            Y,      udiaeresis,       Udiaeresis ] };
    key <AD03> { [            u,            U,          uacute,           Uacute ] };
    key <AD04> { [            p,            P,          oslash,         Ooblique ] };
    key <AD05> { [            g,            G,     dead_ogonek,       asciitilde ] };
    key <AD06> { [            j,            J,         dstroke,          Dstroke ] };
    key <AD07> { [            m,            M,     dead_macron,       asciitilde ] };
    key <AD08> { [            f,            F,          atilde,           Atilde ] };
    key <AD09> { [            w,            W,           aring,            Aring ] };
    key <AD10> { [            b,            B,      dead_breve,       asciitilde ] };
    key <AD11> { [  bracketleft,    braceleft,   guillemotleft,        0x1002039 ] };
    key <AD12> { [ bracketright,   braceright,  guillemotright,        0x100203a ] };
    key <BKSL> { [    backslash,          bar,      asciitilde,       asciitilde ] };

    key <AC01> { [            a,            A,         aogonek,          Aogonek ] };
    key <AC02> { [            r,            R,      dead_grave,       asciitilde ] };
    key <AC03> { [            s,            S,          sacute,           Sacute ] };
    key <AC04> { [            t,            T,      dead_acute, dead_doubleacute ] };
    key <AC05> { [            d,            D,  dead_diaeresis,       asciitilde ] };
    key <AC06> { [            h,            H,      dead_caron,       asciitilde ] };
    key <AC07> { [            n,            N,          nacute,           Nacute ] };
    key <AC08> { [            e,            E,          eogonek,         Eogonek ] };
    key <AC09> { [            i,            I,          iacute,           Iacute ] };
    key <AC10> { [            o,            O,          oacute,           Oacute ] };
    key <AC11> { [   apostrophe,     quotedbl,          otilde,           Otilde ] };

    key <AB01> { [            z,            Z,       zabovedot,        Zabovedot ] };
    key <AB02> { [            x,            X,          zacute,           Zacute ] };
    key <AB03> { [       period,      greater,   dead_abovedot,       asciitilde ] };
    key <AB04> { [            c,            C,          cacute,           Cacute ] };
    key <AB05> { [            v,            V,              oe,               Oe ] };
    key <AB06> { [            k,            K,  dead_abovering,       asciitilde ] };
    key <AB07> { [            l,            L,         lstroke,          Lstroke ] };
    key <AB08> { [        comma,         less,    dead_cedilla,       asciitilde ] };
    key <AB09> { [    semicolon,        colon,      odiaeresis,       Odiaeresis ] };
    key <AB10> { [        slash,     question,    questiondown,       asciitilde ] };

    key <LSGT> { [        minus,   underscore,          endash,           emdash ] };
    key <SPCE> { [        space,        space,           space,     nobreakspace ] };

and for console:

keycode  86 =    Return
keycode  83 =    KP_Period


keycode  16 = q
keycode  17 = y
keycode  18 = u
keycode  19 = p
keycode  20 = g

keycode  21 = j
keycode  22 = m
keycode  23 = f
keycode  24 = w
keycode  25 = b


keycode  30 = a
keycode  31 = r
keycode  32 = s
keycode  33 = t
keycode  34 = d

keycode  35 = h
keycode  36 = n
keycode  37 = e
keycode  38 = i
keycode  39 = o


keycode  44 = z
keycode  45 = x
keycode  46 = period           greater
keycode  47 = c
keycode  48 = v

keycode  49 = k
keycode  50 = l
keycode  51 = comma            less
keycode  52 = semicolon        colon

As I wrote in a post #66 i use vim editor with mouse. There is no problem on conventional keyboard to press some keys on its right side using left hand (when right is on mouse). With Maltron keyboard this is very uncomfortable because of its shape.  For example, I very often want to repeat some action using '.' key in places pointed by mouse.  Another example is the case when you make a mistake (eg. you paste something in wrong place), so you need to press 'u' key to undo. '.' and 'u' are on the right side of qwerty/colemak layout, so to press them on Maltron keyboard you need to move right hand from mouse.

Mouse is always there and I try to use it more if it really helps, a specially in programming. See
http://plan9.bell-labs.com/wiki/plan9/m … _keyboard/