Ellipse's F77: a belated review (with some pontification thrown in).

[depletedvespene]

Obligatory disclaimer: I'm a braindead idiot who doesn't know anything about anything, and has the habit of presenting his own opinions as unquestioned and unquestionable facts.

Back in late November, I got my hands on one of the two keyboards I was in for from Ellipse — a black ultracompact F77 keyboard, with a set of unprinted keys. Then my job hit an unexpected high workload period and I couldn't find time to even fart. It was only during mid-February that I actually plugged the F77 and started using it.

So what are my findings?

F77 keyboard and green pen.

F77.jpg (110.02 KiB) Viewed 8368 times

First impressions.

• Since this was the aluminium, instead of zinc, case, I expected the keyboard to be light-ish. IT IS NOT! This keyboard weighs quite a bit, and that's an immediate reminder that this is a quality item and not some cheap-ass plastic unit or some "kustom" that artificially adds a weight to try to elevate itself to a higher category.
• The black case looks great and is quite, quite classy.
• The blank keycaps look just plain perfect.
• Once I installed (correctly — more on this below) the keycaps, I started typing right away. The keyfeel is the perfect F feel; heck, it feels even better than my old, beaten-up F122 (which does need some new foam). The sound... I just love it. It pings, it sings... this IS a true Model F keyboard.

First usage.

When I first plugged the F77, it was immediately recognized by the computer. I started typing... and most keys wouldn't produce anything. Dreading the worst, I started listing the ones that worked vs. the ones that didn't... quickly realizing that the latter did not sound "right": it turned out I had mis-seated those keycaps (I hadn't used the correct technique of putting the keyboard in vertical; Model M keyboards are more flexible in this regard). I took all keycaps out and placed them back in and the problem was solved for good.

Ellipse sent a set of blank keycaps for a full-size ANSI keyboard, which was almost enough to cover the F77, with only three spots missing — nothing I couldn't tend to with my stock of keycaps. Some people have mentioned that older keycaps feel scratchy, but I find no difference so far (I haven't tried Unicomp caps, though).

It was then time to test the pre-loaded layout. About that... nope! The idea of placing Fn where RCTRL is was anathema to me, so I immediately loaded my own layout, done with pandrew's QMK configurator. I've tinkered with the layout(s) quite a bit during this time, trying out a few experiments.

SIDE NOTE: I heavily prefer the QMK firmware to xwhatsit, as I find it quite more flexible and richer in features. There's the added fact that QMK is able to handle a chattering problem in the F107 I have, which xwhatsit couldn't (rendering the keyboard unusable).

The keyboard is FLAT and has several screws on its underside, so installing the feet, or at least the cork bumpers, was a must, to avoid scratching the table and damaging those screws. Me being me, I didn't want to waste time on that, so I simply placed some denim cloth that was lying around, and gave myself some typing angle with a piece of cardboard. Later, I added some height with a plank of wood under the keyboard. My very prim and proper, and handy at crafts, grandmother would be pissed if she were alive and were to see this:

F77 keyboard, ready for business.

F77_desk.jpg (139.58 KiB) Viewed 8368 times

 

The work of a craftsman (just say yes).

socrafty.jpg (223.82 KiB) Viewed 8368 times

 
This is temporary, okay? I intend to custom-order a deskmat for the exact size of the keyboard (I seriously dislike those gigantic 900×400 mm² things... and they don't fit in this table).


Not everything was well and god, though. The eagle-eyed among you will have already noticed a 1.25U keycap between the space bar and RALT. I had asked Ellipse to split every splittable key, up to and including splitting the 7U space bar into a 5.5U bar and a 1.5U key. I first placed a 1.5U key there, but whenever I pressed it, it would get stuck in the down position. This happened with all of Ellipse's 1.5U keycaps, and with OG IBM caps as well.

Stuck keycap.

stuck.jpg (134.04 KiB) Viewed 8368 times

As it turned out, the problem is the space bar's wire, which is sliiiiiightly wider than expected and protrudes a bit. Pressing down the key gives the keycap enough force pass the wire aside on its way down, but the release back up lacks that force and the wire impedes the return. I'll note that this does not occur on the left side — LALT goes down and back up without issue.

I tried to fix this issue by nudging the wire a bit to the left, but it didn't help much. I suppose that this is a matter of specs tolerance, and I'd rather not open the keyboard for further inspection (I'll probably screw things up) — instead, I'm working around this with a 1.25U keycap (for now; I'll later get a 1.5U keycap, file it a bit on the bottom left side, and use that instead).


Once everything was ready, it was time for some daily driving, and...


Daily driving blues: quirks of the physical layout.


The F row. First off, the most obvious one, and one which I (unlike someone else) knew would be coming and would have to be dealt with: the lack of a dedicated function row IS a hindrance on F-keys-heavy contexts. Having to press, say, Fn+5 for F5 is okay for occasional usage, but not for frequent usage, and it gets worse when having to press chords (Ctrl-F5, Ctrl-Shift-F2, etc.). Yes, some programs provide alternatives (for example, Ctrl-R and Alt-D instead of F5 and F6 in Firefox and Chrome), but not all do, or (worse), the alternatives are incomplete (F11 ⇒ Ctrl-F for "Find"? Fine, but "Find Next" is only available as F3...). I had to press an M0120 keypad into service to be able to keep the F keys in a base layer (which, yes, is the main reason for the plank of wood), but this is still not perfect.

As mentioned, this is a hindrance on F-keys-heavy contexts, and I missed the F keys dearly... except when I didn't. Whenever I connected to the bash shell on any Unix servers, that pain just didn't happen, as the F keys aren't used there. The F77 also spent a few days plugged to an Apple iMac (a 2009 double-hand-me-down that I prepared for my mother to use as a Netflix-viewing device), where I didn't miss them either; during this time, the quite decreased usage of Fn made it best to map those two keys to LGUI and RGUI, so they would behave as the Commmand (⌘) keys, and have Fn placed elsewhere.


The 5×3 pad. Ellipse's original layout moves the nav subcluster (Insert, Delete, Home, End, Page Up and Page Down) to the second and third row and places the supranav keys (Print Screen, Scroll Lock and Pause) on the first row, as some early 2000s keyboards used to do. I hated that then and still hate it now — what I did, instead, was to keep the first and second rows as the nav subcluster, and moved the supranav keys to the middle row. Works perfectly for me and it should work perfectly for everybody!!!

I had expected some pain because of the not-empty-anymore space between the arrow keys and the nav subcluster, but it got me surprisingly little time to get used to it. The fact that I placed a homing cap in the central key (Scroll Lock) surely helped... (which leads me to wonder if Ellipse will accept custom jobs like this for the printed caps).

Now, as a numpad... it falls short. Quite short. The arrows+numbers thingie is good to quickly type in some numeric sequence, but that's about it. Whenever dealing with actual numbers, I quickly find myself missing the operator keys and whatnot, and Excel, which I use a lot, is downright painful to use with this numpad (it does not help matters that even a regular 5×4 numpad is lacking for me, and I'd love to AT LEAST add a sixth row). As things go, I've found that I barely use the pad as a numpad, and the M0120, even placed on the left side, is a better alternative.


The (top-left) corner key.

Let's just acknowledge this: IBM made a serious mistake when it converted the corner key (which was Esc on most systems, up to and including the XT layout) into an alpha. Even when they insisted on isolating Esc on the Enhanced layout, it would have been best to keep the corner key as a modifier (Back Tab, IMNAAHO) instead of making it into an alpha (`~ in the en-US layout, ºª in the es-ES layout, |° in the es-LA layout, etc.), and now we're stuck with that. Then came the compact keyboards, took a page from the AT layout and moved the corner alpha to the E13 position (the left half of a Backspace key split in two). Then came those who thought overloading the corner key AS alpha and modifier at the same time (abusing the Fn layer or worse) would be a good idea "because the backquote and the tilde symbols are barely used"... and GFL, it is not.

I tried several things and in the end, I've kep the corner key as Esc, moved the backquote-tilde to the E13 position and remained unhappy about it — it's just too far away, where a modifier normally is, and my fingers go to the Esc key whenever I mean to type any corner key characters (which are ' " ` ¬ in my national layout), with disastrous results far too often.

On that note...


That extra key on the bottom row.

I split the 7U space bar into a 5.5U bar and a 1.5U key. My initial idea was, once I learned more than the basics of QMK, to turn it into a Macro key, distinct from Fn, where I could program common sequences of keystrokes (for example, Macro-F would produce the sequence to type out "`find . -type f`"). Now, however, is a second backquote-tilde key, alleviating the misery of said alpha key in E13. That said, except for the space bar, alphas definitely don't belong in the bottom row. If I ever get used to E13, I might revisit my initial Macro idea.


Split right Shift.

Split on the outside, works flawlessly. A good part of that is the fact that both successor keys (1.75U right Shift and 1U LGUI or Fn) are both modifiers. If I had to place an alpha in that 1U key (backquote-tilde, duh), I'd be complaining to no end.

Funny bit: at first, I had placed the OG stepped Caps Lock key here, to further isolate LGUI, but it turns out that when I hit right Shift, I press the key right where the stepping is. Swapping the non-stepped 1.75U keycap with the stepped one made quite the difference.


Split (ISO) Enter.

The high half is Backspace, the lower half is a TIE Enter. The HHKB-style Backspace is the only good thing inherited from the HHKB layout (and, of course, it was copied onto it, not invented there), and it's quite easy to get used to, even when alternating with keyboards with a normal 2U backspace in the first row.

As per the TIE Enter, same thing. I've mentioned before that having used for years ANSI- and ISO-Enter-sporting keyboards at the same time trained me (if unknowingly) to hit Enter in the area common to both.


Split Backspace.

The left side is now the bakquote-tilde alpha, which I've already mentioned. On the right side I had, until a few minutes ago, the layer selector to switch between the navpad and the numpad, but... it turns out that I switch between them less and less as days pass, and I pressed that key accidentally too many times. While writing this post, I decided to modify my layouts, and move the layer selector to the Fn layer; that key now simply produces MUTE in the base layer.



All in all, my only real issues with the physical layout are the two I fully expected from day one:

1) The lack of dedicated F keys... which is not a problem in contexts where those are seldom used.

2) The clash of the Esc and backquote-tilde keys, an issue that is common to all sub-75% physical layouts. If this problem was solved, it would have ripple effects up to enabling the unsplitting of the Enter and Backspace keys.



Is it daily driver worthy?

On a Windows system... no. But, as things happen, I'm mounting a (local) Linux machine (instead of a remote server) for a particular project, so the F77 will be its dedicated keyboard.




So, logical layouts?

This what I currently have, using QMK Configurator. I might make further changes later on.

my_F77_json.zip

JSON file for my F77.

(772 Bytes) Downloaded 139 times

Logical layout, layer 0.

layer0.png (37.89 KiB) Viewed 8368 times

Layer 0 is the most basic layer. Defines the entire alpha block and the pad as a nav cluster. Note both Fn keys placed between Ctrl and Alt, with LGUI (the Windows key) shoved off to a side, but still available for those few times when it's actually needed.

Logical layout, layer 1.

layer1.png (37.78 KiB) Viewed 8368 times

Layer 1 is identical to layer 0, except both Fn keys are now LGUI and RGUI. Fn is moved to the 1U key to the right of right Shift. This setup is a good fit when using this keyboard on a Macintosh, where GUI is equated to Command.

Logical layout, layer 2.

layer2.png (28.63 KiB) Viewed 8368 times

This layer maps the pad as a numpad. Fn+(top right key) in layer 0 and layer 1 toggle this layer on and off. The way this is set up, the numpad works without issue whether the default layer is 0 or 1.

Logical layout, layer 3.

layer3.png (39.66 KiB) Viewed 8368 times

This is the "Fn layer" proper. The F keys, volume control and a few other things are defined here. Note how Fn+Enter activates layer 0 as the default and Fn+Backspace does the same with Layer 1.



And now, let's pontificate.

I know perfectly well that the goal of Ellipse's project was to faithfully reproduce the F62 and F77 keyboards of old, and that we have several additional features added on top (a compact case, extra possibilities for the physical layout, QMK programmability, etc.), but...

... it still rushes into the problems and limitations that lacking a sixth key row implies. And boy, those keyboards would be EVEN better if they had it.

I understand that widening the curved inner plate is easier said than done, but then... it doesn't have to be 7U long (a simple separation of 0.25U, as modern compact keyboards to, should be enough). I can't help but wonder how big of a jump would be to go from an F77 to any six-row form factor, which doesn't have to be a TKL or a full-size — how about a 75% or a 96%, form factors that IBM never actually built? Something like this (please excuse my mad Paint™ skillz):

Hypothetical 75%.

75PC.png (194.48 KiB) Viewed 8368 times

Hypothetical 96%.

96PC.png (340.44 KiB) Viewed 8368 times

I would be the first in line if those were to be announced. Meanwhile, I'll continue to enjoy typing in my F77.

[Go-Kart]

A good read. I'd certainly be interested in a 75 %. I still don't know how I feel about keyboards that ping but if the typing experience is that good? Presumably I'd warm to it.

[depletedvespene]

A good read. I'd certainly be interested in a 75 %. I still don't know how I feel about keyboards that ping but if the typing experience is that good? Presumably I'd warm to it.

The typing experience IS all that was promised it would be, indeed.

[darkcruix]

Great write-up. Thanks for sharing!

I never had an issue with the missing F-row, but the shortcuts I use are seldomvy on the F-rows itself. On the other hand, I am using the num-pad quite frequently for both - navigation and numbers. On a Mac, you have to program these differently due to the fact that a real Num-Pad with num-lock like with Windows doesn't exist.
I used a F122 and a F107 for quite some time but it was too wide for me.

Your 75% looks like something I would consider buying

[depletedvespene]

Great write-up. Thanks for sharing!

I never had an issue with the missing F-row, but the shortcuts I use are seldomvy on the F-rows itself. On the other hand, I am using the num-pad quite frequently for both - navigation and numbers. On a Mac, you have to program these differently due to the fact that a real Num-Pad with num-lock like with Windows doesn't exist.

One of the things I intend to do, once I have learned beyond the basics of QMK, is to how to operate the Num Lock status (and light) as part of the change of layer (as it stands now, Num Lock is "emulated", so to speak, and if you want to produce numbers, you need to ensure Num Lock is indeed on, or else the key 4 will move the cursor to the left, etc.).

I used a F122 and a F107 for quite some time but it was too wide for me.

Your 75% looks like something I would consider buying

Me too, and the 96% would make me put the F122 away.

[darkcruix]

One of the things I intend to do, once I have learned beyond the basics of QMK, is to how to operate the Num Lock status (and light) as part of the change of layer (as it stands now, Num Lock is "emulated", so to speak, and if you want to produce numbers, you need to ensure Num Lock is indeed on, or else the key 4 will move the cursor to the left, etc.).

Ping me, when you want me to share my QMK config including the LEDs - I actually light up the LED, when I switch to numbers there

[Ellipse]

Thanks for your thorough review depletedvespene!

[Sam]

Me too, and the 96% would make me put the F122 away.

I'm also someone who uses the F1 - F12 keys extensively throughout the day, and I'm still struggling with my new F77. That 96% design is what I would have considered perfect, and would have been exactly what I would have ordered if there was such a thing. I always use the navigation keys on the numpad, which is something I use constantly throughout the day for editing. The F77 3x5 is usable, but a much larger numpad as what you suggested would be even more ideal, and for those who input lots of numbers into Excel or such, would give a lot more functionality in that mode. I do like the fact that the F77 has the numpad cluster right next to the alphanumeric section, and doesn't have the standalone navigation cluster between it, which is something I never learned to use even after all these years of having it on my past keyboards. The IBM XT and then AT keyboards were what I used for a long time, and when I moved to a Model M, I simply ignored that navigation cluster in the middle.

One of the other things I've been trying to get used to is putting those navigation keys on a layer in the normal alphanumeric section, to avoid taking my fingers off the home row. I figured if I need to put my function keys on a layer, why not go all out and put the navigation keys as well on a layer. So far though, it's just not working very well for me, and I'm beginning to realize why. For cursor navigation, the numpad is an ortholinear layout, but the alphanumeric section is row staggered. I never really thought about that until getting my F77, and it's really made me question a lot of things about "standard" keyboards. I have 35+ years of using the IBM numpad, in it's ortholinear layout, and that muscle memory is so engrained that I use it for editing without ever thinking about it at all. I'm beginning to think now that a split ergonomic ortholinear layout with IBM Model F, or even Beam Spring keys might be better, being I'm already committed to learning a new layout. Of course, such a keyboard doesn't exist, AFAIK.

[Muirium]

I use function keys a fair bit too, and 60%s are my daily drive. It's a simple remap in your mind from the number on the F key to the numrow. F1? Fn+1. F10? Fn+0. F12? Fn+=. It's second nature very quickly with practice.

Besides, the F77's don't even need to you relearn the arrow keys. That's the real qualifying exam for 60% pilots!

[Bjerrk]

I use function keys a fair bit too, and 60%s are my daily drive. It's a simple remap in your mind from the number on the F key to the numrow. F1? Fn+1. F10? Fn+0. F12? Fn+=. It's second nature very quickly with practice.

Agreed. Many laptops do the same thing, I always found that it became quite natural quickly.

My only "problem" is that I find myself attempting to do Caps Lock+2 for F2 when using other keyboards (I usually map Fn onto caps lock)

[depletedvespene]

Obligatory disclaimer: I continue to be a braindead idiot who doesn't know anything about anything, and still has the habit of presenting his own opinions as unquestionably unquestionable facts.


Fifteen months later, what's up with my F77?

During this time, I used it on a Windows PC, then for a few weeks on a Macintosh, then for a few months on a Linux machine, and is now back to be plugged to a Windows machine (a secondary PC).


Hardware-wise? It... just... works. It clacks and pings. It continues to be a bona fide Model F keyboard.


Software-wise? With QMK (sorry, I've never tried VIA or VIAL), I have toyed around with several layout changes and made a few experiments, with differing results (this was the reason I asked my F77 to have every splittable key split). For the stuff I've done, pandrew's QMK Configurator fork works flawlessly, to the point of invisibility (a good thing!). I have to admit that I haven't yet gone beyond — some of the programming and remapping that can be easily done with a Soarer's Converter, but requires complex macros or even writing C source code in QMK, is still on my to-do list.


Numpad? I was keen on trying the 5×3 block as a small numpad. To my surprise, I absolutely hated it — the missing fourth column (which my fingers kept looking for all the time) was just too much of an omission, and I ended up ceasing to use it entirely. At some point, when I flashed in some changes in the layout, I got rid of the numpad layer and the emulated Num Lock (which I had on the right-side key that corresponds to Backspace). Whenever I needed to type in numbers, I used a separate numpad, or typed in everything on the number row and suffered for it (until I decided to turn the key 6& into a homing key).

That said, the 5×3 block works perfectly as the nav cluster (with the supranav keys on row 3, not row 1), so I have not changed anything in this regard.


Now, my initial main gripe was the lack of a sixth row, and it continues to be so. The lack of proper function keys is rather problematic on a main driver on a Windows-based PC, although on MacOS and on a Linux telnet client this is diminished. But not entirely...

The clash of the Esc and the corner alpha (`~ in the English (USA); '" in the Iberoamerican layout) keys continued to be a problem, and I found the known workarounds (moving the corner alpha to the split backspace AND/OR the bottom row, "tap-dancing", using Fn-corner for Esc, etc.) to be all unfit. About three months ago, I decided to try a nutty option someone suggested to me: turn Caps Lock into the Esc key...

I love this. So much so, that I am now reprogramming ALL my keyboards in the same sense, something that I'll talk about at length in a separate post. The corner alpha can now be the corner alpha and nothing else, freeing up the left-side half of Backspace. Since the right-side half was already empty, that means that I have two available keys for macros, or special functions, or... to make them back into a 2.0U Backspace key, and reverting the TIE Enter into an ISO Enter. I would have done that already, but I'm afraid that if I open the keyboard with these thick, clumsy hands, I'll screw up something.

Meanwhile, the F77 continues in active usage.




I'll post a GOOD picture of the keyboard later. For now, a photato of the current messy environment, F77 included, should suffice:

What a mess.

MESSYdesktop.jpg (186.81 KiB) Viewed 7028 times

[marcuso]

I've not received my keyboard yet - but on my other boards I have mapped;

CapsLock to FN
PageUp/PageDown to FN+UP/FN+DOWN and Home/End to FN+LEFT/FN+RIGHT
Also, I've mapped DEL to FN+BACKSPACE and INS I never really use anyway.

This frees up 6 keys in the nav block.

I've gone a little further and moved BREAK to FN+C, PrintScreen to FN+P and I never use ScrollLock - there's another 3 function keys there.

In total, I have F1-F9 on the right hand side nav block.

I also plan to have ESC in the top left and FN+ESC for tick (I've not tried that yet as my current boards all have a tick key already)

It works a treat for me in Windows, Linux and OS/X - I'd strongly recommend it!

PS; Dedicated cut/paste keys!! (to the left and right of the up arrow key; and FN+CUT for copy)

[depletedvespene]

I've not received my keyboard yet - but on my other boards I have mapped;

CapsLock to FN
PageUp/PageDown to FN+UP/FN+DOWN and Home/End to FN+LEFT/FN+RIGHT
Also, I've mapped DEL to FN+BACKSPACE and INS I never really use anyway.

This frees up 6 keys in the nav block.

To each his own, of course. In my case, I frequently use all those keys with modifiers as well (Ctrl-Home to go to the start of the document, etc.), so using them as three-key chords (sometimes four-key chords) is a pest.

I also plan to have ESC in the top left and FN+ESC for tick (I've not tried that yet as my current boards all have a tick key already)

It works a treat for me in Windows, Linux and OS/X - I'd strongly recommend it!

Not in my case — the corner alpha produces the apostrophe and the quote sign, and relegating Esc to the Fn layer is a sin for those of us who use vi constantly — heck, I think that the idea of moving Esc to Caps Lock came from a vi user in the first place!

PS; Dedicated cut/paste keys!! (to the left and right of the up arrow key; and FN+CUT for copy)

Now, this COULD be something I could test, on the unused keys that go on Backspace.

[depletedvespene]

So this morning I updated my F77's layout yet again — this is how it's going now.

Layer 0 (base layer).

f77_mfarah_004_layer_0.png (44.91 KiB) Viewed 6916 times

Base layer: all alphas in the correct positions; Esc has been moved to Caps Lock, and Caps Lock is in the 1.5U key between the space bar and AltGr. Fn keys between each Ctrl and Alt key pair, The Windows (LGUI) key to the right of the split right Shift. The nav cluster has suffered no changes.

Note the two entirely unused keys above the 1.5U Backspace. If I weren't a clumsy coward, I'd have opened the keyboard and replaced a couple flippers with stabilizers and placed back a 2.0U Backspace key and the ISO Enter key.

OTOH... this gives me space for other experiments. I'm tempted to try marcusos's idea of placing COPY and PASTE there.

Layer 1 (GUI and Fn keys swapped back, for MacOS).

f77_mfarah_004_layer_1.png (44.63 KiB) Viewed 6916 times

Layer one: identical to the base layer, but swaps the Fn and GUI keys (the latter work as the "Command" ⌘ keys on Macintosh). This works nicely, as the reduced necessity of the Fn layer when the keyboard is plugged to a Macintosh makes it feasible to have just one Fn key.

Layer 2 (date-time numpad).

f77_mfarah_004_layer_2.png (33.8 KiB) Viewed 6916 times

A newly cooked-up version of the small numpad — instead of arrows and numbers and nothing else, let's try numbers and the signs needed for writing dates and times; the bottom row places a comma in the middle key; in the top row, Shift-., which in my national layout (and most European layouts) produces the colon sign.

Layer 3 (Fn).

f77_mfarah_004_layer_3.png (44.33 KiB) Viewed 6916 times

The Fn layer per se: volume controls in the leftmost column; F1..F12 in the first row, F13..F24 (because I want them available — I'm that whimsical) in the second row; the not really useful but always desirable option to disable and enable back the Win key in a quiet, out of the way area.

Fn-Enter selects the base layer; Fn-Backspace selects the MacOs layer; Fn-Caps Lock toggles on and off the numpad layer. They way I've set this up, things work transparently and as expected (it remains to be seen wether this numpad design is any good, but that's a different issue).

Fn-Scroll Lock produces Scroll Lock. Why? To be able to access it even if the numpad layer is active. Fn-Pause produces the TRUE Num Lock (because it needs to be accessible).



Here is the JSON file, in case anyone wants it:

f77_mfarah_004.zip

JSON file for my current F77 layout.

(795 Bytes) Downloaded 93 times

[BuGless]

Optimising the keyboard mapping turns out to be an art by itself (and still a work in progress). FWIW, here's my current take on it.
BTW, I love your idea about the homing marker on the normal 6/^. Due to lack of keys with a marker (at the moment) I have now opted to the use the keypad-5 (yes, not a perfect fit, I admit) in the position of the 6. It works, because I rarely look at the keyboard anyway.

These layers are vi-friendly.

Base layer (0)

BuGlessLayer0.png (54.17 KiB) Viewed 6856 times

• Esc/~ (Escape when pressed, ~ when pressed with shift). It covers muscle-memory high-escapes, and it also covers typing muscle-memory tildes. Backquotes I need rarely, so they can be obtained either directly below the enter key, or using the function layer (3).
• The top row keys are all configured to produce a non-repeating Fxx function key if held down for longer than 300ms. I.e. tapping them gives the regular key (numbers 0 to 9 and - and =), holding them results in the corresponding function key (using the QMK tapdance feature).
• Direct access to Insert/Delete/Home/End/PageUp/PageDown and F1, F2, F10, F11 and F12.
• Function key is on space-bar hold, it turns on Function layer 3 (for the duration of the hold). Autorepeat space is double-tap-hold.
• Tab also turns on Mousewheel layer 6. Autorepeat tab is double-tap-hold.
• The Caps-Lock position is used for the Escape key as well as the Control key on hold.
• Alt-left produces a ( paren on tap, Alt-right produces a ) paren on tap; on hold they function as regular Alt keys.
• Enter functions as Control on hold (for symmetry).
• Left to Alt-left we have a toggle to turn on/off the mouse-movement/media layer.

Numeric keypad overlay layer (1)

BuGlessLayer1.png (36.86 KiB) Viewed 6856 times

• Reached through the simulated numlock from the Function layer 3.
• ATM/Phone style, because I use those more often.
• Below the Right-shift, there is a layer activation key for the hex-overlay layer (2).
• This layer is indifferent to the state of the real Numlock key (as are all of these layers).

Hex overlay layer (2)

BuGlessLayer2.png (32.27 KiB) Viewed 6856 times

• Reached through the layer shift key on the numeric keypad layer.

Function layer (3)

BuGlessLayer3.png (62.65 KiB) Viewed 6856 times

• Reached via space-hold on the base layer.
• The tilde/backquote, just in case.
• Pause on S and Printscreen on P.
• Caps-Lock on right-shift, in case some clown pressed it.
• Cursor keys on the vi-navigation row.
• Scrollwheel using the cursor keys.
• Left to Alt-left activates the extended-movement layer while held (intended for alternate functions without moving the fingers of your right hand).
• Reset-to-default layer 0 on backspace.
• Simulated numlock toggle with the numeric-keypad layer 1.
• Enter is the layer-jump to the keyboard-system-layer 7.

Extended movement layer (4)

BuGlessLayer4.png (55.59 KiB) Viewed 6856 times

• Reached via left to Alt-left from the function layer.
• Provides alternate functions on the vi-movement-keys and the cursor keys.

Mouse movement/media layer (5)

BuGlessLayer5.png (66.46 KiB) Viewed 6856 times

• Reached through the left to Alt-left toggle key on the base layer.
• Reset-to-default layer 0 on backspace.

Mousewheel overlay layer (6)

BuGlessLayer6.png (46.13 KiB) Viewed 6856 times

• Reached through Tab-hold from the base layer.
• Mousewheel keys on the vi-movement keys and the cursor keys.

Keyboard system layer (7)

BuGlessLayer7.png (49.81 KiB) Viewed 6856 times

• Reached through Enter-hold from the Function layer.
• Reset-to-default layer 0 on backspace.

There currently is still one small snag, which is that if I try to configure all function keys F1 through F12 on the top row for delayed-hold-activation, the firmware kind of crashes (not completely, I can still make it enter bootloader mode by pressing space-enter-R).
In order to avoid this problem, I currently excluded F8, F9 and F10 from this special treatment, and that makes it work.
It almost seems as some part of the code is writing at a random offset into the data structures of the tap-dance code. The problem occurs only if the amount of static data required to store the tapdance functions exceeds a certain byte-count.

If someone wants to peruse it, unpack the attached default_bugless.zip. It contains both the json keymap, as well as the other supporting source files belonging to my QMK keyboard.

[depletedvespene]

Optimising the keyboard mapping turns out to be an art by itself (and still a work in progress). FWIW, here's my current take on it.
BTW, I love your idea about the homing marker on the normal 6/^. Due to lack of keys with a marker (at the moment) I have now opted to the use the keypad-5 (yes, not a perfect fit, I admit) in the position of the 6. It works, because I rarely look at the keyboard anyway.

In the the F77 keycap set, all keys are blanks, so I'm technically using the (blank) keypad-5 homing key, too.

For the XXK, back when I made the custom order at Unicomp, I needed two homing keys, but I figured it wouldn't hurt to get one more, just in case... which has now come in rather handy.

These layers are vi-friendly.

Holy shirt, that's a lot of layers! I guess that if the user IS comfortable with tap-dancing, then that does open a lot of possibilities (I'd rather keep the modifiers and layer selectors on the bottom row, on each side... so I have two Fn keys instead of distinct Fn1 and Fn2 keys).

BuGlessLayer0.png

Base layer:

• Esc/~ (Escape when pressed, ~ when pressed with shift). It covers muscle-memory high-escapes, and it also covers typing muscle-memory tildes. Backquotes I need rarely, so they can be obtained either directly below the enter key, or using the function layer (3).

This harkens back a bit at the inexcusably bad decision of having conflated a modifier (Esc) and an alpha (`~), on the grounds that "those two characters are barely used anyway", a criminally uninformed view from whichever gringo said so... Unix users, gringos and otherwise, would surely like to have a few choice words about this.

Worse yet, alpha assignments are dependent on national layout! It's a simple matter of taking a look at a few of them to discover that this conflation can be incredibly annoying (the Hungarian layout taking the crown on this issue). In my particular case, the corner alpha produces ' and " (plus ` and ¬), so mixing it with Esc was simply unsuitable.

[BuGless]

Holy shirt, that's a lot of layers! I guess that if the user IS comfortable with tap-dancing, then that does open a lot of possibilities (I'd rather keep the modifiers and layer selectors on the bottom row, on each side... so I have two Fn keys instead of distinct Fn1 and Fn2 keys).

Please note that the only thing in my setup that requires the QMK-tapdance-feature are those 300ms-delayed-functionkeys in the top row of the base layer.

Personally I noticed that I do not tend to activate the function layer from both sides of the space bar.
Then again, by making the spacebar itself the primary actor to activate the function layer, it becomes trivial to activate it, because you can use either thumb to hold it down.

But, yes, it's easy to move the Insert and Delete back into the keypad block and simply drop two of the function keys there, in order to achieve symmetry on the bottom row.

[BuGless]

I have to admit that having the function layer 3 activated by the space bar, creates some spurious F11 triggers when typing typical unix command lines like: "ls -l". As it turns out, I hit the dash before the space bar has been released sometimes.
A possible solution to this would be to require a (longer?) minimum delay time before the held space bar registers as a function layer activation. I'll have to dig into the QMK firmware to see if this can be easily tweaked.

[xxhellfirexx]

Then again, by making the spacebar itself the primary actor to activate the function layer, it becomes trivial to activate it, because you can use either thumb to hold it down.

I have to admit that having the function layer 3 activated by the space bar, creates some spurious F11 triggers when typing typical unix command lines like: "ls -l". As it turns out, I hit the dash before the space bar has been released sometimes.
A possible solution to this would be to require a (longer?) minimum delay time before the held space bar registers as a function layer activation. I'll have to dig into the QMK firmware to see if this can be easily tweaked.

Holding the spacebar to trigger a function layer is an interesting idea as it is easy to reach. However, it is important to make layer triggers more difficult to trigger accidentally. Holding the spacebar is also commonly used for panning a canvas or for scrolling down a page.

[BuGless]

I have to admit that having the function layer 3 activated by the space bar, creates some spurious F11 triggers when typing typical unix command lines like: "ls -l". As it turns out, I hit the dash before the space bar has been released sometimes.
A possible solution to this would be to require a (longer?) minimum delay time before the held space bar registers as a function layer activation. I'll have to dig into the QMK firmware to see if this can be easily tweaked.

Holding the spacebar to trigger a function layer is an interesting idea as it is easy to reach. However, it is important to make layer triggers more difficult to trigger accidentally. Holding the spacebar is also commonly used for panning a canvas or for scrolling down a page.

As it turns out, I rarely (if ever) use the auto-repeat functionality of the spacebar. Scrolling to the end of the page I typically tend to do using the "jump to the last page" key (like End, Shift-End or '>', depending on context). My autistic inner child probably chivers at the thought that having an auto-repeating spacebar doing the scrolling and then bumping into the end repeatedly until you notice you have reached it and finally release the spacebar; it feels so wasteful.

Which is not to say that my first attempt at coaxing QMK into requiring a minimum delay on the LT() layer activation has failed.
I tried setting TAPPING_TERM to 400 (ms), it seems to have zero effect on the LT() bindings. If anyone happens to know which magic incantation triggers this (I'm compiling from source): please step forward.

[Bjerrk]

My worry with SpaceFn is more that there are so many keyboards where holding down the spacebar for prolonged periods is not particularly pleasant. Try holding down the spacebar on an IBM F XT for a minute while, I dunno, mousing around or using arrows or whatever you've put on that layer

I usually program some key on the column just to the left of the alphas (the one typically containing Esc, Grv, Tab, CapsLock etc) as Fn, and then sometimes use LT(), depending on the key in question.

(Unfortunately I don't know the answer to setting the LT() tap times)

[BuGless]

My worry with SpaceFn is more that there are so many keyboards where holding down the spacebar for prolonged periods is not particularly pleasant.

Because of the typically stronger spring backforce in the spacebar, you mean?

[Bjerrk]

Because of the typically stronger spring backforce in the spacebar, you mean?

Exactly I have an Ellipse F77 as well as some old IBM ones, and I find it's nice to use the same layout (as much as it is possible, at least).

[BuGless]

Which is not to say that my first attempt at coaxing QMK into requiring a minimum delay on the LT() layer activation has failed.
I tried setting TAPPING_TERM to 400 (ms), it seems to have zero effect on the LT() bindings.

Found something, I think.
The magic incantations are:

#define IGNORE_MOD_TAP_INTERRUPT
#define PERMISSIVE_HOLD

Once enabled, they'll prevent spurious activation of the new layer for a fast typist (as long as the keys are being pressed within the TAPPING_TERM).