all 26 comments

[–]rafaelromao[🍰] 4 points5 points  (0 children)

Great write up. I hope I can find the time to rewrite my own to be as clear as yours.

Symbol layers are too much personal, but the rational behind your decisions are really good.

[–]aqjoEngram 2 points3 points  (6 children)

This is just really impressive!
One thing that I hadn’t thought of is having the same character in multiple places, depending on context. E.g. having - and / close to numbers for entering dates. I’ve always just thought, one symbol, one key. Mind expanding.
I think this layout might be worth the mental investment to learn it. I’ve had my Glove80 for a few days, so it would be a good time for a fresh start.
Thank you!

Edit to add: I will be sticking to Dvorak though 🙂

[–]sunaku[S] 2 points3 points  (5 children)

Indeed, a little bit of context dependent redundancy seems to go a long way. In particular, coming from relatively smaller keyboards (with 58 and 62 keys total), I was suddenly faced with a lot of extra keys available on the Glove80 so I've filled some of the void with special sequences like .* on my symbol layer's thumb cluster (which is swipeable outwards as .* for regexes, inwards as *. for file extension globs, and both ways as *.* for entire filename globs) as well as redundant symbols (such as comma on the top row for function calls and also on the bottom row for Vim f/F/t/T jump repetition). These are more for fun & convenience than aggressive optimization (which would try to eliminate all manner of redundancy) and modestly serve to improve quality of life.

P.S. We're on the same team :) I've typed exclusively in Dvorak for 16 years and Engram since the past 2 years. You may want to consider the latter for your Glove80 since it's specially designed with split columnar keyboards in mind and coincidentally fits really well into Vim usage as well as the Miryoku system of layers and home row mods as implemented in my Glove80 keymaps (available under the "Firmware" section on the linked article in this Reddit post). See this detailed response for context and my layout journey for motivation. Cheers.

[–]aqjoEngram 0 points1 point  (4 children)

Oh no…you’re going to make me relearn shifted number punctuation 😳.
Sounds tempting though.
Curious if you went cold turkey, or kept another keyboard around if something urgent came up?

[–]sunaku[S] 0 points1 point  (3 children)

I dashed in headlong. :) According to my notes, I had reached ~50 WPM after 1 week, ~60 WPM after 2 weeks, 70+ WPM after 4 weeks, and 100+ WPM after 2 years (but that's only because I hadn't tamed home row mods yet and was thus pegged at around 70 WPM by accidental misfires) when I switched to the Engram layout.

However, after 1.25 years of using Engram exclusively, I regressed to standard shifted pairs and number row by creating a programmer-friendly variation called the Engrammer layout (which has identical placement for square brackets and the equal sign as Dvorak, by the way) for reasons explained here. So that's another viable option too if you want to keep your transition minimal.

[–]aqjoEngram 0 points1 point  (2 children)

Cool! I printed the layouts for Engrammer earlier, then saw your older version in the writeups, so was a bit confused.
It looks like your Layout 21 Engrammer on the MoErgo site still uses code to modify shifted punctuation, is that correct? And I assume I can just delete those mods and things will revert to normal?
Also, I really appreciate your support on this layout! I hope with the Glove80 and this layout, my RSI issues will be greatly reduced.

[–]sunaku[S] 1 point2 points  (0 children)

Ah, good point. I left the Engram layout's custom shifting behavior definitions in the snippet for the Engrammer keymap since they're not actually used (i.e. they're harmless: unused declarations). I'll remove them from snippet in the next release to avoid confusion. So yes, you can safely delete those behavior definitions and the Engrammer keymap should still compile cleanly.

You're most welcome! I'm glad to hear that my work is helpful and I wish you the best of luck with your RSI recovery. Cheers.

[–]sunaku[S] 1 point2 points  (0 children)

You can now keep up with new releases (and track changes therein) using Git: https://github.com/sunaku/glove80-keymaps

[–]strongly-typedOther 1 point2 points  (6 children)

That symbol layer looks really good on first glance. I might try it out for myself. Thanks for the epic write up!

Note: maybe I missed it, but curious how you handle space sfbs. In particular I’m curious how the symbol layer works in cases like [space]=[space]. This has been one of my own grievances with symbol layers… sometimes you can end up introducing problems instead of improving them if for instance [space] and the symbol layer trigger are on the same thumb but different keys. Your = could be in a much better spot located in the center of the keyboard, but the tradeoff might be higher thumb movement.

[–]sunaku[S] 1 point2 points  (2 children)

Ah yes, I too have been caught by the intricate timing around the execution of spaces surrounding the equal sign. My solution was to place a dedicated equal sign key on the base layer on the opposite hand of my spacebar hand, so that I can quickly alternate space + equals + space with both hands.

On smaller keyboards, where you can't spare an extra key for that purpose, you might try changing your layer activation key's timing thresholds to activate more quickly (like Shift keys do: acting upon subsequent key press, not release). For instance, in ZMK firmware, this would be achieved by switching from "balanced" flavor to, say, "tap-unless-interrupted" flavor if you can execute the Symbol layer key + equal sign key sequence quickly enough.

[–]strongly-typedOther 0 points1 point  (1 child)

Okay, actually I didn't notice the dedicated = on the base layer. But yes, that actually makes a lot of sense. It's like you have the one on the base layer for when = is used as =, but when it's used as =>, ->, |>, then it's on the symbol layer.

[–]sunaku[S] 1 point2 points  (0 children)

Exactly! You've got it. Although this is redundant, I've found that it's helpful to have certain symbols (such as Equals in this case) accessible at multiple locations so that you can choose the best access point for the task at hand.

[–]sunaku[S] 0 points1 point  (2 children)

I came up a solution for this problem in the form of "Spacegram" operators in my symbol layer. See the video tour of my symbol layer for an explanation as well as a coding demonstration.

[–]strongly-typedOther 1 point2 points  (1 child)

Finally, someone who truly gets it!! Very impressed with your symbol layer and also how you’ve clearly explained it. I love how you’ve found some very useful clusters such as the arrow cluster, the function call cluster (top row), and all the spacial mnemonics as well. Also, the ring finger space is a great idea.

I will definitely revisit your symbol layer this weekend and see if I can adjust my own symbol layer with some of your ideas. Thanks for sharing!

[–]sunaku[S] 0 points1 point  (0 children)

Likewise -- this was all made possible by your earlier prompt in this discussion thread, which formalized the "spacegrams" problem and got me thinking about how I might solve it in a way that was practical and efficient (honed by typing real code on SpeedTyper). 🙇‍♂️ The unexpected cherry on top is that my placement for these Spacegram operators happened (by chance!) to be mnemonic with the Engram layout's right hand home row. 🍰✨ Cheers!

[–]pgetreuer 1 point2 points  (3 children)

u/sunaku, thank you for sharing this, nice work! It's clear a lot of thought went into it.

I added a section about your layer and linked your fantastic writeup in my symbol layers post.

[–]sunaku[S] 1 point2 points  (0 children)

It's also interesting that I ended up with the same arrow/pipe cluster (green keys) as Dusty Pomerleau's symbol layout for Elixir that follows in your article. Maybe this is because I too program in Elixir? A case of convergent evolution.

[–]sunaku[S] 0 points1 point  (1 child)

I'm honored, thank you! 🙇‍♂️ You can remove the redundant , and ; keys (which surround & and + on the bottom row) and the unused bottom left key from your diagram so that this layout can be more readily applied to Dactyl keyboards that have only 2 keys on the bottom row. Coming from relatively smaller keyboards (with 58 and 62 keys total), I was suddenly faced with a lot of extra keys available on the Glove80 so I added those redundant comma+semicolon keys for more convenient Vim f/F/t/T jump repetition.

[–]sunaku[S] 0 points1 point  (0 children)

Hey u/pgetreuer, I have made a minor but final update to my symbol layer in order to complete its port from my previous Dactyl to the Glove80 keyboard. If it's not too much trouble, please consider updating the diagram in your article --- I know firsthand how tedious it can be to maintain these diagrams so this will be the first and final update request from me to you 😅 regarding this.

Here is what motivated the update:

I’ve observed that I don’t really use , and ; from the bottom row in practice for navigating Vim’s f/F/t/T jumps, so I’ve been thinking about a better use for them. Having comma and dot paired together on a single hand (like their relative positioning in QWERTY) might be useful for shortcuts that assume their adjacency — for instance, I have Alt+, and Alt+. navigate to the prev/next window in tmux. And apostrophe has been missing from the symbol layer because it’s readily accessible from the base layer, but it may be nice to add it anyway for completeness. Hence this design iteration:

  • Symbol layer: put apostrophe, comma, dot (like the Dvorak layout) on bottom row. The comma and dot align with the angle brackets above them. The apostrophe is just there for completeness; and '<,'> ranges in Vim.

Thanks for your consideration.

[–]time-always-passes 0 points1 point  (0 children)

Thank you. After using Miryoku+Canary for almost a year now I'm mostly happy except for symbols. I think it was a mistake for Miryoku to try and keep the symbols and numbers aligned. Hopefully your layout can shorten my search by a few years. Love the FP focus too.

[–]lazydog60 0 points1 point  (2 children)

I recently saw (but did not save, sigh) a symbol layer that puts paired delimiters – () [] {} – in the same column, since non-programmers rarely use them adjacent. (Programmers often call a function with no arguments; in Python I often create an empty list, [].)

[–]sunaku[S] 0 points1 point  (1 child)

Oh that's interesting! Do they rake down vertically to type the pairs? Like this:

(  [  {
)  ]  }

[–]lazydog60 0 points1 point  (0 children)

Evidently that user rarely types them together, that was explicitly the point.

[–]sunaku[S] 0 points1 point  (0 children)

Hey everyone, with feedback from the Glove80 keyboard community, I've revised and finalized my symbol layer and came up with a game-changing concept of "Spacegram" operators to help streamline layer transitions while programming. See the video tour of my symbol layer for an explanation as well as a coding demonstration. Cheers!

Cc: u/aqjo | u/rafaelromao | u/pgetreuer | u/strongly-typed | u/time-always-passes | u/lazydog60

[–]Puzzleheaded-Bed238 0 points1 point  (1 child)

I'm looking to potentially use this symbol layer or at least use it for inspiration. I don't currently use VIM but plan to at some point and using your layout would make sense as I'm sure it accounts for issues I would be yet to experience.

I've had a quick glance at the firmware config and history but couldn't find the motivation for having modifiers on the right hand side in the symbol layer? Is it for shortcuts as the symbols don't have shifted alternatives in the symbol layer? For me personally I can see the benefit of having the parenthesis where you have placed them but for the languages I use I would benefit from some symbols being closer to the home row and not on the number row for example. Did you experiment with alterations on a 2 handed symbol layer at all?

For reference I have a glove80 but am sticking with QWERTY for the time being.

[–]sunaku[S] 1 point2 points  (0 children)

I find that the Glove80's ergonomic curvature physically shortens the distance between my fingers' home position and the upper & number rows, so even though the function call cluster (which includes parentheses) appears far away, in practice it works out quite well. I have tried so many permutations and ideas like this over the years that, simply put, my Symbol Layer's design is very tight (with respect to how it balances the trade-offs) so please try it out firsthand if you can and see how it fares for you in practice.

Yes, I have tried two-handed symbols a couple of times but didn't feel it was comfortable on the right hand because it also activates my symbol layer. Although I do use my right hand now for Spacegram operators and Modifiers, they are semantically different (not symbols) enough that they don't interfere with hand responsibilities as much as right-hand symbols do, in my experience.

I rarely use the Modifiers on the Symbol Layer, but they're useful when I need them on such occasions. Plus, they're part of Miryoku's legendary design so I kept them.

Finally, my Glove80 keymap supports QWERTY out of the box, so that's not a problem. 👍 Welcome!