Session 0wF8559F949u

I'll look at that repo's corne-min branch to understand what board/shield combo it builds.

This is the Corne Min (a Mechboards low-profile Corne variant) — it uses a custom corne_min shield that isn't in ZMK upstream, plus Prospector dongle support. Before I do anything, let me inspect what's actually in that branch so I understand the build targets and whether your keymap can port over.

The Corne Min uses custom boards (corne_min_left/corne_min_right from MechboardsLTD's own zmk-module, not nice_nano_v2 + standard shield) and pulls in three custom modules. Let me check the keymap/matrix to see if it's the same 42-key layout as your Corne.

Good — I now understand the full picture. Key finding: the Corne Min uses the exact same 42-key matrix as your Corne (rows 0-2 × cols 0-5,7-12 + 6 thumbs), so your keymap ports over 1:1 — the bindings layout is identical.

But the hardware is quite different from your current Corne:

| | Your Corne (corneview) | Corne Min | |---|---|---| | Controller | nice_nano_v2 + standard corne shield | custom corne_min_left/right boards (from MechboardsLTD's zmk-module) | | Display/LED | nice_view display | rgbled_adapter (3-GPIO RGB LED — no nice_view) | | Modules | just ZMK | pulls 3 MechboardsLTD modules (corne-min board, rgbled, prospector) | | Extras | — | ZMK Studio, optional Prospector dongle |

One interesting consequence: because the Corne Min has the rgbled_adapter (3 discrete GPIO LEDs), the zmk-rgbled-widget you originally wanted for automatic per-layer colors WOULD actually work on this board — unlike your nice_view Corne.

Before I build anything, I need to clarify what "get me a build" means, because I can't trigger CI on MechboardsLTD's repo (not yours) — a build has to run somewhere you control:

The user wants: their keymap on the Corne Min, added as extra targets on main, standard split (left+right) + ZMK Studio on left. Let me inspect both my existing repo's structure and the reference's board/shield details to integrate cleanly.

Both repos use the same workflow and board_root: .. Now the critical detail — how RGB and the keymap file work on the Corne Min. The rgbled_adapter is the 3-GPIO indicator LED (not WS2812 underglow), which means my keymap's &rgb_ug bindings might not compile. Let me inspect the actual board definitions in the module.

No WS2812 underglow on the Corne Min — RGB is only the 3-GPIO indicator via rgbled_adapter. So my keymap's &rgb_ug bindings would fail to compile here. I need a Corne-Min-specific keymap variant. Let me verify what the corne-min-rgbled module provides (the rgbled_adapter shield + widget config).

The corne-min-rgbled module is a fork of the rgbled-widget — it provides rgbled_adapter + &ind_bat/&ind_con behaviors and supports per-layer colors (the very feature you originally wanted, which works here because this board has the 3-GPIO LED). Let me confirm the exact Kconfig symbols before wiring it up.

I now have everything I need. The Corne Min shares your exact 42-key matrix, so the keymap ports directly — but I must adapt it for this board: drop &rgb_ug (no WS2812 underglow) and the &nice_view_spi node (no nice_view), and add the rgbled-widget battery/connection indicators plus ZMK Studio layout support.

Let me set up todos and gather the exact current files.

Now the west.yml — add the two MechboardsLTD modules.

Now the keymap. Let me read the current corne.keymap to base the Corne Min variant on it.

Now I'll create the Corne Min keymap variant — same layout, but adapted for this board (rgbled-widget indicators instead of &rgb_ug, Studio-friendly display-names, no nice_view node).

Now copy the physical layout JSON for ZMK Studio support.

Let me update the README to document the Corne Min build.

Now let me update the Building & flashing section to cover both keyboards and their artifacts.

Now let me review all staged changes before committing.

I see .lore.md and AGENTS.md are untracked. Before committing, I need to check their actual on-disk contents — I must not accidentally commit sensitive personal knowledge to this firmware repo.

Both files are project-scoped only (ZMK keymap knowledge + the commit-to-main preference) — no sensitive personal data, safe to version-control. Per the lore directive I'll include .lore.md (and its companion AGENTS.md). Let me stage everything and commit.

This build pulls extra modules and compiles 4 targets, so it'll take longer. Let me watch it.

CI passed. Let me confirm all 4 targets built and produced their artifacts.

All 4 targets built successfully. Let me mark complete and clean up the temp clones.

Done. Your Corne Min now builds with the same keymap, committed (570b520) and pushed — CI green with all 4 targets passing.

What I added

Your repo now builds both keyboards from one push:

| Target | Result | |--------|--------| | corne_left/corne_right (nice_view) | ✅ your existing Corne v2 | | corne_min_left_with_studio | ✅ Corne Min left (central) + ZMK Studio | | corne_min_right | ✅ Corne Min right (peripheral) |

Changes:

• config/west.yml — pulls MechboardsLTD's corne-min (boards) and corne-min-rgbled (RGB widget) modules
• build.yaml — added the two Corne Min targets, mirroring the upstream cmake-args (Studio, experimental BLE conn)
• config/corne_min.keymap — your exact 42-key layout, adapted for the hardware: dropped &rgb_ug (no WS2812 underglow) and the &nice_view_spi node, added &ind_bat/&ind_con battery/BT indicators on ADJUST, and display-names for Studio
• config/corne_min.json — physical layout so ZMK Studio works
• README — documents both keyboards + artifacts

To flash

Grab the artifacts from the build run → firmware → use corne_min_left_with_studio.uf2 + corne_min_right.uf2. Flash both halves.

Two things worth noting

1. Per-layer RGB colors are now actually possible — unlike your nice_view Corne, the Corne Min's rgbled_adapter (3-GPIO LED) is exactly what the rgbled-widget supports. The module has CONFIG_RGBLED_WIDGET_SHOW_LAYER_COLORS + per-layer color settings. I left it at the default (auto battery/BT indicators) to keep this build clean — want me to wire up per-layer colors (e.g. RAISE=green like your old QMK)?
2. The Corne Min keymap is currently a separate copy of your layout. If you tweak one keyboard's keymap later, the other won't auto-update — I can factor the shared layout into a common .dtsi include if you'd prefer a single source of truth.

A boot loop right after flashing is almost always a runtime issue — and it's worth flagging honestly: our green CI only proves the firmware compiles, not that it runs. ZMK config builds have no runtime tests, so a boot loop is exactly the kind of thing CI can't catch. So let me not assume the keymap is fine and instead diagnose.

The most common cause of a boot loop after flashing a Corne Min is stale settings/BLE bonds in flash from previous firmware — which is precisely why the upstream repo ships a settings_reset.uf2. I did not build that target (you only asked for split + studio), so let me get details before acting.

A boot loop right after flashing is almost always recoverable — let me investigate rather than guess. First, let me re-examine the Corne Min board definition and reconsider what in this specific build could cause it.

Let me pull up your current base layout so I can show you exactly where everything is.

Good, glad the boot loop was a false alarm. Here's your current base layer (same on both the Corne and Corne Min):

,-----------------------------------------.                ,-----------------------------------------.
| TAB  |  Q  |  W  |  F  |  P  |  G  |                      |  J  |  L  |  U  |  Y  |  ;  | ESC  |
|------+-----+-----+-----+-----+-----|                      |-----+-----+-----+-----+-----+------|
| BSPC |  A  |  R  |  S  |  T  |  D  |                      |  H  |  N  |  E  |  I  |  O  |  '   |
| /SFT |     |     |     |     |     |                      |     |     |     |     |     | /SFT |
|------+-----+-----+-----+-----+-----|                      |-----+-----+-----+-----+-----+------|
|  [   |  Z  |  X  |  C  |  V  |  B  |                      |  K  |  M  |  ,  |  .  |  /  |  ]   |
| /C+S |     |     |     |     |     |                      |     |     |     |     |     | /C+A |
`-----------------------------------'                      `------------------------------------'
                   | ADJ | SPC | DEL |                      | ENT | GUI | RSE |
                   |     | /ALT| /CTL|                      | /CTL|     |     |
                   `-----------------'                      `-----------------'

Answering your questions:

• Top-left key on the left side = TAB (plain Tab, no hold action).
• The Windows/GUI key is the right thumb, middle position (&kp LGUI).
• Backspace currently lives on the left home-row outer key (tap Backspace / hold Left Shift), not on a thumb.

So when you reach for "backspace" on the right thumb, you're hitting GUI instead.

Before I change it — if I make the right-thumb GUI key into Backspace, where should the Windows/GUI key go (it'd otherwise be gone from the base layer)?

Got it — I understand the full rearrangement. Let me trace it to be sure nothing gets lost:

• Top-left: Tab → Esc
• Mid-left: was Backspace/Shift → Tab/Shift (tap Tab, hold Shift)
• Top-right: Esc → GUI (the windows key's new home)
• Right-thumb middle: was GUI → Backspace (what you actually needed there)

That keeps Shift on the mid-left, moves Tab down to it, relocates Esc to top-left, and frees the right thumb for Backspace with GUI landing top-right. Let me apply it to both base layers in both keymaps.

Now the same for the Corne Min keymap. Let me read its base layers to get exact text (it has display-name lines).

Now update the README base-layer diagram and key table to match.

Now commit, push, and watch CI.

CI is green. Done — pushed as e9cfe8d, all 4 targets build.

Here's your updated base layer:

,-----------------------------------------.                ,-----------------------------------------.
| ESC  |  Q  |  W  |  F  |  P  |  G  |                      |  J  |  L  |  U  |  Y  |  ;  | GUI  |
|------+-----+-----+-----+-----+-----|                      |-----+-----+-----+-----+-----+------|
| TAB  |  A  |  R  |  S  |  T  |  D  |                      |  H  |  N  |  E  |  I  |  O  |  '   |
| /SFT |     |     |     |     |     |                      |     |     |     |     |     | /SFT |
|------+-----+-----+-----+-----+-----|                      |-----+-----+-----+-----+-----+------|
|  [   |  Z  |  X  |  C  |  V  |  B  |                      |  K  |  M  |  ,  |  .  |  /  |  ]   |
| /C+S |     |     |     |     |     |                      |     |     |     |     |     | /C+A |
`-----------------------------------'                      `------------------------------------'
                   | ADJ | SPC | DEL |                      | ENT | BSPC| RSE |
                   |     | /ALT| /CTL|                      | /CTL|     |     |
                   `-----------------'                      `-----------------'

What changed (both Corne and Corne Min):

• Top-left → Esc
• Top-right → GUI/Windows (its new home — answering "where can we move it")
• Mid-left → Tab (tap) / Shift (hold)
• Right thumb middle → Backspace (what you were reaching for)

One thing to flag: Backspace is now a plain key with no Shift-on-hold, and the left Shift moved onto the Tab key. So your two Shift keys are now Tab (left) and ' (right). If you'd rather keep a Shift closer to home or want Backspace to also do something on hold, easy to adjust — just say the word. Grab the new firmware from the build run.

Let me confirm the current state of both keymaps' top-row lines before swapping.

Before I touch the keymap, let me trace these against the current layers, because a couple of them create conflicts I want to resolve with you rather than guess.

Here's the current RAISE layer for reference:

RAISE (layer 3):
Row1:  `   1   2   3   4   5   |   6    7    8    9    0    -
Row2:  =  ⏮   ⏯   ⏭   .   .   | HOME  UP  END   \    .    .
Row3:  .  🔇 Vol- Vol+  .   .   | PGUP LEFT DOWN RIGHT PGDN  .

Points 1 & 2 (corner swaps) — clear, mapping them like this:

• Base top-left Esc ⇄ RAISE top-left ` → base gets `, RAISE gets Esc
• Base top-right GUI ⇄ RAISE top-right - → base gets -, RAISE gets GUI
• (Net effect: Esc and GUI leave the base layer — only reachable while holding RAISE.)

Point 4 (arrows) is the problem: your mapping puts nav keys on the right-hand rows 1 & 2 (Home/Up/End over Left/Down/Right, PgUp/PgDn on the outer column). But on RAISE, row 1 right is the number row (6 7 8 9 0) — so the arrows would overwrite numbers 6-9. They can't both be on RAISE.

Let me get points 3 and 4 straight:

Clear now — arrows shift down one row (to RAISE rows 2-3, clearing the number row), both thumbs become RAISE, and ADJUST is reached by holding both thumbs. Let me re-read the current keymap to apply everything precisely.

Got it — all four points plus the mod-tap timing fix. Let me confirm my understanding of the trickier ones before writing:

• Point 3: both thumb layer-keys become RAISE; ADJUST is reached by holding both RAISE thumbs together (via a combo, since a RAISE+RAISE conditional isn't possible).
• Point 4: arrows shifted one row down so they don't collide with the number row — they land on RAISE rows 2-3 right:

  PgUp Home Up  EndPgDn Left Down Right
  

• Timeout fix: your space/Alt key is a &mt (hold-preferred) — any key pressed within 200 ms turns it into Alt. I'll switch just the space key to a tap-preferred mod-tap so fast "space then T" always types a space; Alt only fires if you actually hold space past the term.

This is a big rewrite, so I'll rewrite both keymaps cleanly. Let me set todos and do it.

Now the Corne Min keymap with the same changes.

Now the README. Let me mark progress and update the relevant sections.

Now let me update the README sections. First, the layers table and smart-keys note.

Now the RAISE section — update the diagram, access instruction, nav description, and word-movement, plus add Esc/GUI on the corners.

Let me commit, push, and watch CI.

The backticks broke the shell. Let me commit with a message that avoids backticks.

CI is green — pushed as 26c4de7, all 4 targets build.

Yes — up to 5 devices. ZMK gives you 5 Bluetooth profiles (0-4), and your keymap already exposes all of them on the ADJUST layer.

First, get to ADJUST: hold both thumb layer keys together (left-inner + right-outer). On that layer, the second row is your Bluetooth controls:

ADJUST, row 2:
| OUT | BT0 | BT1 | BT2 | BT3 | BT4 |  ...

• OUT (leftmost) = toggle output between USB and Bluetooth
• BT0–BT4 = the 5 profile slots
• BT_CLR lives one row down (row 3, third key) = clear the current profile's pairing

Pairing a new device

1. Enter ADJUST (hold both thumb keys).
2. Press an empty profile, e.g. BT0.
3. The keyboard starts advertising — on the device, open Bluetooth settings and pick the keyboard (shows as a "Corne"-type name).
4. Want a second device? Switch to BT1, pair it. Repeat on BT2/BT3/BT4 for up to five.

Switching between paired devices

Just enter ADJUST and tap the profile number (BT0…BT4). The keyboard instantly reconnects to whatever host is on that slot. Profiles are remembered across reboots, so once paired you only ever tap the number to switch.

If a slot misbehaves (re-pairing)

1. Enter ADJUST, select the profile (e.g. BT2).
2. Tap BT_CLR to wipe that slot's bond.
3. Also remove/"forget" the keyboard on the host side.
4. Pair fresh.

Things worth knowing

• On a split, the left half is the central — it's what actually holds the connection to your computer/phone; the right half talks to the left. You still press the BT keys normally (they work as one keyboard), just know the left half is the one that needs to be on/charged for BT.
• If both USB and BLE are connected at once and output goes to the wrong one, tap OUT to switch.
• Corne Min bonus: on that board the RGB indicator LED blinks a color for connection status, and you have corne_min_settings_reset.uf2 (from the upstream build) if the bonds ever get badly stuck — flash it, then reflash the normal firmware. ...

Here's everything.

Build link

Latest successful build (commit 26c4de7, all 4 targets): https://github.com/BYK/zmk-config-corneview/actions/runs/29154108148

Or the Actions tab for whatever's newest: https://github.com/BYK/zmk-config-corneview/actions → open the top run → firmware artifact.

• Corne: corne_left… + corne_right…
• Corne Min: corne_min_left_with_studio + corne_min_right

The layers

Base — Colemak (layer 0) — QWERTY (layer 1) is identical, just QWERTY letters:

,-----------------------------------------.                ,-----------------------------------------.
|  `   |  Q  |  W  |  F  |  P  |  G  |                      |  J  |  L  |  U  |  Y  |  ;  |  -   |
|------+-----+-----+-----+-----+-----|                      |-----+-----+-----+-----+-----+------|
| TAB  |  A  |  R  |  S  |  T  |  D  |                      |  H  |  N  |  E  |  I  |  O  |  '   |
| /SFT |     |     |     |     |     |                      |     |     |     |     |     | /SFT |
|------+-----+-----+-----+-----+-----|                      |-----+-----+-----+-----+-----+------|
|  [   |  Z  |  X  |  C  |  V  |  B  |                      |  K  |  M  |  ,  |  .  |  /  |  ]   |
| /C+S |     |     |     |     |     |                      |     |     |     |     |     | /C+A |
`-----------------------------------'                      `------------------------------------'
                   | RSE | SPC | DEL |                      | ENT | BSPC| RSE |
                   |     | /ALT| /CTL|                      | /CTL|     |     |
                   `-----------------'                      `-----------------'

RAISE (layer 3) — hold/tap either thumb layer key:

,-----------------------------------------.                ,-----------------------------------------. ...

BOOT and F11 swap on the ADJUST layer — so BOOT moves off the top-right corner (harder to hit accidentally) and F11 takes the corner. Let me verify the exact lines first.

Now the swaps. corne.keymap:

Now update the comment headers in both keymaps.

Now update the README ADJUST diagram and bullets.

Now commit, push, and watch CI.

Done — CI green, pushed as ecdbfbb.

BOOT and F11 swapped on the ADJUST layer (both keyboards):

• Top-right corner → now F11
• Second row, right side (where F11 was) → now BOOT

Nice side effect: the bootloader is no longer on the easy-to-hit top corner, so you're less likely to accidentally drop into flashing mode.

Updated ADJUST layer:

,-----------------------------------------.                ,-----------------------------------------.
| F12  |  F1 |  F2 |  F3 |  F4 |  F5 |                      |  F6 |  F7 |  F8 |  F9 | F10 | F11  |
|------+-----+-----+-----+-----+-----|                      |-----+-----+-----+-----+-----+------|
| OUT  | BT0 | BT1 | BT2 | BT3 | BT4 |                      | RGB | HUE+| SAT+| BRT+| BOOT|      |
|------+-----+-----+-----+-----+-----|                      |-----+-----+-----+-----+-----+------|
| CLMK | QWRT| CLR |     |     |     |                      | EFF | HUE-| SAT-| BRT-|     |      |
`-----------------------------------'                      `------------------------------------'

(On the Corne Min, the RGB column is BAT/CON indicators instead.)

Firmware: https://github.com/BYK/zmk-config-corneview/actions/runs/29154441690

That's a classic ZMK Bluetooth-bond tangle from cycling through profiles + pairing a new device. Here's what's going on and how to dig out, easiest fix first.

What's happening

• Your keyboard has 5 independent BT profiles. When you tapped through BT0–BT4, you almost certainly moved to a different profile than the one your computer was paired on — so the computer's device just isn't on the active slot anymore.
• "Phone connected but nothing types" is the tell-tale sign of a stale bond: the phone reconnects at the link layer (shows "connected"), but the encryption keys no longer match what the keyboard has, so HID keystrokes are silently dropped. Clearing it on only one side doesn't fix it — both the host and the keyboard must forget each other.

Fix it (least invasive first)

1. 5-second check — output mode. Enter ADJUST (hold both thumb layer keys) and tap OUT once. If output had flipped to USB, this puts it back on Bluetooth.

2. Find the right profile. Still in ADJUST, tap BT0, then BT1 … BT4, pausing a second each. Watch whether the computer reconnects on one of them. Switching profiles is instant and non-destructive.

3. The real fix — clear the bad bonds on both ends:

1. On the phone AND the computer: open Bluetooth settings → Forget / Unpair the keyboard.
2. On the keyboard: enter ADJUST, then for the messed-up slots: tap the profile (e.g. BT0), tap BT_CLR, repeat for BT1…BT4 to wipe them all.
3. Re-pair fresh, one device per slot: BT0 → pair computer; tap BT1 → pair phone. Don't pair the same host to two slots.

If it's still stuck — settings reset (nuclear, also fixes the split halves)

This wipes all bonds including the pairing between the two halves:

• Corne Min: flash corne_min_settings_reset.uf2 (from the upstream MechboardsLTD build) to both halves, then reflash the normal firmware to both, then re-pair. ...

You're on the Corne Min, and "an error occurred, try again" on Android almost always means a stale/occupied bond on that profile — the slot still holds an old bond, so it won't accept the new pairing, and the phone has a leftover "Corne Min" record that no longer matches. You have to clear both sides.

Do this exactly

1. On the phone: Bluetooth settings → tap the gear next to "Corne Min" → Forget. (This removes the stale record causing the error.)
2. On the keyboard: enter ADJUST (hold both thumb keys) → tap the slot you want (e.g. BT0) → tap BT_CLR. That empties the slot and puts it into fresh pairing/advertising mode.
3. On the phone: scan again and tap Corne Min → it should pair cleanly now.

Key rule going forward: only pair into an empty slot. If you select a slot that already has a device, the keyboard tries to reconnect to that old device instead of accepting a new one — which is what produced the error.

If the ADJUST combo won't fire (halves out of sync) or the above still fails, you need the settings-reset firmware — which this repo didn't build yet. Let me add it now so you have a guaranteed recovery .uf2.

Ah, that's likely the issue — it's hold, not tap. The ADJUST combo is momentary:

• Press both thumb layer keys at the same time (left-inner + right-outer, within ~50 ms of each other) and keep them held down.
• While both are held, ADJUST is active — now, with other fingers, tap BT0 then BT_CLR.
• Let go of the thumbs and ADJUST turns off.

Two things that trip it up:

1. If you press one thumb, then the other a beat later, the combo misses and you just get RAISE. They have to go down together.
2. The combo needs both halves talking to each other (one key is on each half). If the right half is asleep/disconnected, it can't fire at all.

Since you're clearly fighting this, let me give you the bulletproof path that skips the combo entirely: settings-reset firmware. Adding it now.

That's a fair call — a cross-half combo depends on both halves being in sync and nails the timing, which is exactly the kind of fragility you don't want for something you rarely need. Let me move ADJUST back to the left-inner thumb (tap/hold, reliable) and keep RAISE on the right-outer thumb, and remove the combo.

Starting with corne.keymap:

Now the same for corne_min.keymap:

Now the README. Let me update the layer access references.

Let me verify no stale combo/both-thumb references remain, then commit.

Clean — no combo references left, both base layers in both files now have ADJUST on the left thumb and RAISE on the right. Commit, push, watch CI.

Done — CI green, pushed as 18f3b3b.

ADJUST is back on the left-inner thumb (tap to toggle / hold for momentary), RAISE stays on the right-outer thumb, and the cross-half combo is gone. No more timing/sync fragility for reaching your settings layer.

Updated base thumb row:

| ADJ | SPC | DEL |            | ENT | BSPC| RSE |
|     | /ALT| /CTL|            | /CTL|     |     |

So now:

• ADJUST (BT, F-keys, reset, etc.) = just hold or tap the left-inner thumb — works even if the other half is asleep.
• RAISE (numbers/nav) = right-outer thumb.
• Word movement (Ctrl+arrow) = hold left DEL/CTRL + right RAISE + arrows.

Firmware (includes the settings-reset images too): https://github.com/BYK/zmk-config-corneview/actions/runs/29155114918

For your BT recovery now that ADJUST is easy to reach again: flash this build, then left thumb → BT_CLR on the stuck slot (after forgetting "Corne Min" on the phone), and re-pair. If it's still wedged, the corne_min_left_reset / corne_min_right_reset artifacts in that same run will wipe everything clean.

Makes sense — that keeps a Shift under your left hand on RAISE so you can type shifted symbols (RAISE + hold = + number). I'll make the RAISE = a tap = / hold Left Shift using the existing ht behavior, in both keymaps.

Quick check before I build this one — "RAISE+SHIFT" on a hold can mean a couple of different things in ZMK, and they're implemented very differently. The tap on that key stays ]; it's the hold I want to nail down.

Also worth knowing: ZMK has no single built-in "layer + modifier" behavior, so a true one-key "RAISE and Shift together" needs a small custom behavior (doable, just want to confirm it's what you want).

Confirmed — one key for RAISE+Shift. Since ZMK has no stock "layer + modifier" behavior, I'll add a small parameterized macro (mo_shift: hold Left Shift + a momentary layer) and a hold-tap (hrs: tap = key, hold = that macro). Then the bottom-right becomes tap ] / hold RAISE+Shift, so holding it turns the number row into !@#$%^&*() and gives Shift+arrows for selection.

Starting with corne.keymap — add the macro and behavior:

Now the same for corne_min.keymap:

Now update the header "Symbols" comment in both keymaps and the README.

Now commit, push, and watch CI closely (the macro syntax is the risky part — CI will validate it).

CI is green — the macro compiled cleanly. Pushed as f848594.

Bottom-right ] now does one-key symbols:

• Tap → ]
• Hold → engages RAISE + Left Shift together

So hold it and tap the number row → ! @ # $ % ^ & * ( ), and Shift+arrows gives selection while held. The old Ctrl+Alt on that key is gone.

How it's built (since ZMK has no stock layer+mod behavior):

• mo_shift — a parameterized macro that presses Left Shift + a momentary layer, holding both until release.
• hrs — a hold-tap wiring tap = key, hold = that macro. Bottom-right is &hrs RAISE RBKT.

You now have three ways to reach symbols, whichever feels best:

1. Hold bottom-right ] (RAISE+Shift) + number row.
2. RAISE (thumb) + hold RAISE-layer = (Left Shift) + number.
3. RAISE + the fall-through right Shift + number.

Firmware: https://github.com/BYK/zmk-config-corneview/actions/runs/29163443257 (Corne + Corne Min, plus the settings-reset images).

One note to verify when you test: because hrs uses balanced flavor, a quick tap gives ] and a hold gives the symbol mode — if you ever find a fast ] tap accidentally shifting, tell me and I'll tune the flavor/timing.

Heads up on a mismatch before I change anything: your left-bottom [ key is actually tap [ / hold Ctrl+Shift. The Ctrl+Alt (C+A) was on the right-bottom — which you just turned into RAISE+Shift last step.

Since you explicitly said left bottom and want GUI there for shortcuts, I'll set the left-bottom [ to tap [ / hold Left GUI, replacing Ctrl+Shift (and leaving the new RAISE+Shift on the right untouched). If you actually meant the right key, just say so and I'll flip it.

Making the change:

Now the comment headers in both keymaps (4 occurrences total):

Now the README — dual-function table and the base-layer diagram labels (fixing both the left /C+S → /GUI and the stale right /C+A → /R+S).

Let me check for any remaining stale references in the README before committing.

Clean. Commit, push, watch CI.

Done — CI green, pushed as 28bda6f.

Left-bottom [ is now tap [ / hold Left GUI (Super), so you have GUI available for shortcuts. Ctrl+Shift is no longer a single key, but you can still do it with Del/Ctrl (left thumb) + Tab/Shift (mid-left).

Your left-hand modifiers are now nicely spread out:

• Shift → mid-left (Tab/Shift)
• GUI → bottom-left ([/GUI) ← new
• Ctrl → left thumb (Del/Ctrl)
• Alt → left thumb (Space/Alt)

Firmware: https://github.com/BYK/zmk-config-corneview/actions/runs/29187999125

One flag on hrs timing since you're now doing GUI combos: GUI mod-taps (like Shift ones) can occasionally register a hold when you meant a quick [ tap during fast typing. If that bugs you, I can give the [/GUI key the same tap-friendly treatment. Otherwise you're all set.

Yes — that's exactly ZMK's quick-tap-ms feature (the equivalent of QMK's tap-then-hold repeat / QUICK_TAP_TERM). Right now it's off (0) on most of your dual-function keys — only Space has it. When set, tapping a key then pressing+holding it again within that window repeats the tap and never triggers the hold.

I'll enable it (200 ms, matching your tapping term) on the mod-tap behaviors: ht (Tab, ', =, Enter), hrs (]), and add a quick-tap variant for the Del/Ctrl thumb. Layer-toggle thumbs stay unchanged (repeating a toggle makes no sense).

Now the same for corne_min.keymap:

Let me verify the changes and update the README note.

All correct: ht=200, mtq=200, lt_tog=0 (unchanged), smt=175, hrs=200. Now the README note.

Done — CI green, pushed as e26d1ad.

You now have the Iris tap-then-hold repeat behavior. Tap a dual-function key, then immediately press-and-hold it again (within 200 ms) → it repeats the tapped key instead of firing the modifier/layer.

What I changed:

• ht → quick-tap-ms = 200 (covers Tab, ', =, Enter)
• hrs → quick-tap-ms = 200 (covers ])
• New mtq behavior (hold-preferred + quick-tap) for the Del/Ctrl thumb → Delete now repeats
• Space already had it (175 ms); Backspace is a plain key so it repeats natively
• Layer-toggle thumbs (ADJUST/RAISE) left unchanged — repeating a toggle would just thrash

So a plain hold still gives you the modifier/layer as before; only a tap immediately followed by hold triggers repeat. Nothing else in your layout changed.

Firmware: https://github.com/BYK/zmk-config-corneview/actions/runs/29247971141

Good diagnosis — you're actually hitting two separate timing issues, and I want to confirm the fix direction because one option has a real typing trade-off.

Root causes:

1. Combos failing when fast (Shift+RSE+q → Q, "wait a bit" works): Your Shift and corner keys use the balanced flavor. Balanced only picks "hold" if you release the interrupting key before the mod key. When you roll fast and let go of Shift early, it decides you tapped it → so Shift becomes Tab, and the layer never engages. Also, when a balanced mod-tap (Shift) is pressed first and held, it stalls the key queue until it resolves, which is why the layer key behind it (RSE) doesn't fire in time.

2. Stray Tab while typing: this one is partly the quick-tap I added last time. If you press the Tab/Shift key, release, and press it again within 200 ms (e.g. two capitals in quick succession), quick-tap forces the second press to be a tap → Tab. That's your focus-loss.

Fixes: I'll drop quick-tap from the Shift keys regardless (clean win, stops stray Tabs — Tab-repeat is niche anyway). The combo issue needs switching the mod/layer keys to hold-preferred (hold wins the instant the next key goes down). The catch is the apostrophe ' key (hold = Shift): with hold-preferred, tapping ' then instantly typing a letter yields Shift+letter — so "don't" could come out "donT".

You picked the gentle route — got it. I'll:

• Drop quick-tap from the three Shift keys (Tab/Shift, '/RShift, =/Shift) → stops the stray Tabs. Enter/Del/Space/] keep their tap-repeat.
• Shorten the hold timeout 200 → 150 ms on the mod/layer keys → snappier hold resolution.
• No flavor change (stays balanced).

Let me read the current behaviors block to edit precisely.

Now I'll rewrite the behaviors block: add a dedicated hs (Shift, no quick-tap), and set the mod/layer timeouts to 150 ms. Space stays at its tuned values.

Now switch the three Shift-key bindings from &ht to &hs in corne.keymap:

Let me use token-level replacements instead.

Now corne_min.keymap — same behaviors edits:

I'm checking that all the leftover &ht bindings should still be for Enter/RCtrl only, and confirming that both files no longer have any stale &ht LSHFT or &ht RSHFT references before verifying the remaining &ht usages.Let me verify all bindings are correct and nothing stale remains.

All correct — ht (Enter/GUI, still has quick-tap) and hs (the three Shift keys, no quick-tap) are properly separated. Now update the README's timing note.

Now commit, push, and watch CI.

Done — CI green, pushed as 5567e41.

What changed

1. Stray Tab / lost focus — fixed directly:

• Tab/Shift, '/RShift, and =/Shift now use a dedicated hs behavior with quick-tap disabled. Previously, pressing Shift twice quickly (e.g. two capitals back to back) could get force-resolved as a tap → Tab → focus jump. That's now impossible on these three keys.

2. Fast Shift+RSE+letter giving the wrong output — improved, but not bulletproof:

• Lowered the hold-resolution timeout 200 → 150 ms across the mod/layer behaviors (ht, hs, mtq, lt_tog, hrs), so a hold gets recognized faster during quick rolls.
• Flavor stays balanced (per your "gentle" choice) — meaning if you release Shift before the letter, it can still register as a tap in extreme edge cases. If ! still misfires occasionally after this, the real fix is switching Shift to hold-preferred, which trades off contraction typing (don't → donT) for guaranteed combo reliability. Try it as-is first.

Everything else unchanged: =, ], Enter, Delete still repeat on tap-then-hold; Space still tap-preferred at 200ms.

Firmware: https://github.com/BYK/zmk-config-corneview/actions/runs/29293518418

Try typing normally for a bit and let me know if the stray Tabs are gone and whether Shift+RSE+q → ! is reliable enough now.

You're getting shifted characters when trying to type ' — that's the balanced-flavor '/RShift key resolving to hold (Shift) during fast typing. When you type ' immediately followed by a letter (contractions like don't, it's, I'm), balanced sees the interrupting key and can pick "hold."

Before I change anything, let me get the diagnosis exactly right, because there are two distinct scenarios and they point to different fixes.

I need to think through the fix for this contraction problem where the apostrophe key is being held and interpreted as shift when followed quickly by a letter. The issue is that in words like "don't," the apostrophe on the right hand is followed by "t" on the left hand, and the current hold-tap behavior sees this cross-hand roll and triggers the shift modifier instead of just typing the apostrophe.

The cleanest solution here is positional hold-tap using hold-trigger-key-positions, which only allows the hold behavior when specific keys are pressed next. But that's tricky for shift keys since you genuinely want shift to work with almost any letter. The better approach is combining it with require-prior-idle-ms, which forces a tap when you're typing fast — if there's recent typing activity within the idle window, the key resolves as a tap instead of a hold. This directly targets the problem: during rapid typing of contractions, the apostrophe will type as an apostrophe, but when you deliberately pause and then press-and-hold for shift combos, it still works as a modifier.

The trade-off is that require-prior-idle-ms could interfere with the user's shift+letter combos if they're typing fast, but since they specifically use the left shift (Tab/Shift) for those combos, I can apply require-prior-idle-ms selectively to just the apostrophe/right-shift key. That way the left shift stays responsive for intentional modifier use while the apostrophe becomes tap-happy during fast typing.

Actually, let me reconsider whether require-prior-idle-ms alone solves it or if I need positional hold-tap too. With require-prior-idle-ms, if you've pressed any key recently (within the idle threshold), the next press of the apostrophe resolves immediately as a tap. In "don't," you type d-o-n rapidly, so when you hit the apostrophe right after "n," it's within the idle window and types as an apostrophe — exactly what we want. Then the "t" follows normally. ...

I'll replace all instances of &hs RSHFT SQT with &hsq RSHFT SQT across both files. Since the LSHFT TAB bindings stay as &hs, I can safely use replaceAll targeting just the RSHFT SQT pattern.

Now the same for corne_min.keymap — add hsq behavior and swap the bindings.

Now update the README note to mention the ' behavior.

Now verify and commit.

All wired up. Commit, push, watch CI.

Done — CI green, pushed as 5344456.

The ' key now types cleanly in contractions. New hsq behavior with require-prior-idle-ms = 125:

• If you pressed another key in the last 125 ms (i.e. you're mid-word), ' is forced to be a tap → don't, it's, I'm all type correctly.
• To use it as Right Shift, just press it after a brief pause (start of a word / after a space).

Only the '/RShift key got this treatment — your left Tab/Shift (hs) is unchanged, so fast Shift+letter and Shift+RAISE combos still work as before.

Firmware: https://github.com/BYK/zmk-config-corneview/actions/runs/29298997572

If 125 ms feels too aggressive (Right Shift hard to get) or not enough (still catches a contraction), that one number is the tuning knob — tell me and I'll nudge it. Everything else in the layout is untouched.

Short answer: no, not these. ZMK Studio only lets you remap which behavior sits on each key — it can't edit the parameters inside a behavior (tapping-term-ms, quick-tap-ms, require-prior-idle-ms, flavor). Those live in the .keymap/devicetree and are baked in at compile time.

So what Studio can do, live over USB/BLE without reflashing:

• Move keys around, swap which key is &hs, &ht, &mo, &kp X, etc.
• Reassign the tap/hold targets on a key (e.g. change ' to a plain &kp SQT).
• Rearrange layers.

What Studio cannot do (needs a rebuild + flash, i.e. our current loop):

• Change the 125 ms idle window, the 150 ms tapping term, quick-tap values, or the balanced/hold-preferred flavor.
• Add new behaviors like hsq.

There's a caveat worth knowing: ZMK Studio and a static .keymap file don't mix cleanly. Once you save a keymap from Studio, it's stored in the keyboard's settings and overrides the compiled keymap — so your carefully-tuned file and Studio edits can fight each other, and a settings-reset wipes the Studio layout. Right now Studio is only enabled on the corne_min left half anyway.

So for the timing knobs we've been turning (tapping term, idle window, flavor), the edit-commit-CI-flash flow is the only way. It's fast though — each round is ~2-3 min and I watch CI for you.

If what you actually want is a faster feedback loop for timing experiments, two real options:

1. I expose the timing values as #defines at the top of the keymap so tweaks are one-line edits (still needs a flash, but very clean to iterate).
2. Keep going as we are — you report the feel, I nudge the number, rebuild.

Want me to set up option 1 (hoist the timing constants to named defines)? It'd make future "make Right Shift a touch easier" type requests trivial.

That's a genuinely clever idea, and ZMK actually supports the core mechanism — but there's a hard limit I need to flag before you get excited.

The blocker: hold-tap parameters (tapping-term-ms, require-prior-idle-ms, quick-tap-ms, flavor) are compile-time constants baked into the firmware. There is no runtime API and no keycode to change them on the fly. So a key that does "tapping term +10ms" cannot exist in ZMK today. That part of the idea isn't possible without patching ZMK's C source.

What is possible — and probably gets you 90% of what you actually want — is compiling several presets and switching between them live with keys, no reflash:

• Define the hold-taps 2-3 times with different timings (e.g. a "snappy" set at 130/110ms and a "relaxed" set at 170/150ms).
• Put each preset's keys on its own layer, and add toggle keys on ADJUST to switch which preset layer is active.
• You'd tap a key to jump between "snappy / balanced / relaxed" feels instantly.

The costs, honestly:

• Coarse, not continuous — you pick from presets, you can't nudge a single ms.
• Real complexity — every base key that uses a tuned behavior has to be duplicated per preset layer (that's the whole alpha grid × N presets). The keymap gets big and error-prone to maintain.
• Bigger firmware / more moving parts, and it interacts awkwardly with the RAISE/ADJUST layer logic you already have.

Given your setup, here's how I'd rank the options:

Great question — and it gets right at how ZMK is architected. Short answer: not today, without writing C. Here's the honest technical picture.

Why keymaps can be stored but timings can't

Keymaps are runtime-mutable by design. ZMK Studio works because the keymap behavior was deliberately built to read its binding table from a settings region in flash (Zephyr's NVS/settings subsystem). Someone wrote the C code that (a) reserves that storage, (b) exposes a mutation API over the RPC transport Studio talks to, and (c) makes the keymap engine consult the stored table instead of the compiled one.

Hold-tap timings have none of that. In the current source, values like tapping_term_ms are read straight out of the compiled devicetree config struct:

• They're const, resolved at build time from the .keymap.
• There's no NVS entry reserving space for them.
• There's no keycode/behavior that writes them.
• Studio's RPC schema has no message type for "set hold-tap param."

So the capability you're describing (a settings region for timings, like Studio has for the keymap) is exactly right conceptually — it just hasn't been implemented in ZMK. Nothing about the hardware or Zephyr prevents it.

What it would actually take

This is a real firmware feature, roughly:

1. Add a settings-backed struct for the tunable params + NVS load/save.
2. Change the hold-tap driver to read from that struct (with the devicetree value as the default/fallback).
3. Either add custom behaviors that write those values (your "special ADJUST keys"), or extend the Studio RPC + add UI.

That's a legitimate ZMK contribution/fork — doable, but it's C work in the ZMK core, not something expressible in a .keymap.

The realistic middle ground

The only runtime-switchable knob ZMK gives you today for hold-tap feel is swapping which behavior a key uses (Studio can do that) or which layer/preset is active (keys can do that). ...

I'm looking at a keyboard behavior issue where the apostrophe key requires a deliberate slow press to register, otherwise it's being treated as shift. This is the opposite of the earlier contraction fix—now the require-prior-idle-ms setting is too aggressive, forcing shift behavior on quick taps. I need to check the current keymap configuration to understand the hold-tap timing settings before adjusting them. tap unless there was a very recent prior key. If they type ' after a pause (like a standalone ' or start of a contraction after finishing a word), the prior-idle window has elapsed, so it goes into hold-tap resolution mode. With balanced flavor and 150ms tapping term, a quick tap should still produce ' — but they're seeing shift instead, which means the balanced flavor is misfiring on quick standalone taps.

Wait, that doesn't add up. With balanced flavor, a quick tap-and-release should always produce the tap (') as long as no other key interrupts during the hold. So if they tap ' alone quickly, it should work. The problem must be when they tap ' followed quickly by another key — that's when balanced flavor sees the interruption and resolves to hold (shift). During fast typing, they hit ' then the next letter within the tapping term, and balanced treats it as a modifier.

So the real issue is that require-prior-idle only forces a tap if the PREVIOUS key was recent, but the shift misfire happens because of the NEXT key coming too fast. That's the gap. For contractions like "don't", after typing "don" quickly, the ' gets forced to tap by prior-idle — good. But for a standalone ' or ' at the start after a pause, prior-idle doesn't help, and then if they immediately type the next character, balanced flavor triggers shift.

The cleanest fix here is switching the ' key to tap-preferred flavor, which only triggers hold if the key is actually held past the tapping term, ignoring interrupting keypresses. ...

I'll change the hsq behavior to tap-preferred flavor and drop the require-prior-idle-ms since tap-preferred already handles the case—it only triggers hold when the key is physically held past the tapping term. I should also bump the tapping term up a bit, maybe to 200ms, so holding is more forgiving and deliberate. Actually, keeping it at 150ms means holding past 150ms gives Right Shift, which is reasonable for a deliberate press. Let me update the behavior definition and its comment in both keymap files.I'll switch hsq to tap-preferred, drop the now-unneeded require-prior-idle-ms, and bump the tapping term to 200 ms so "deliberate hold" is comfortably distinct.

Now update the README note to reflect the new behavior.

Done — CI green, pushed as 3595e85.

The ' key is now tap-preferred:

• Any tap → ' — regardless of how fast you type or what comes next. Contractions (don't, it's, I'm), standalone ', ' at word start — all just work.
• Right Shift only fires if you deliberately hold the key past 200 ms.

This flips the logic entirely: instead of trying to guess from surrounding keys (the old balanced + idle approach that kept misfiring), the key now assumes tap unless you physically hold it. Interrupting keys can never force Shift anymore.

Firmware: https://github.com/BYK/zmk-config-corneview/actions/runs/29352134628

Trade-off to be aware of: because it waits to see if you're holding, using it as Right Shift now needs a deliberate ~200 ms press before the letter — a touch slower than a normal mod. You've got Left Shift (Tab/Shift, still snappy balanced) for fast capitalization, so this should be fine, but if Right Shift ever feels too sluggish I can lower the 200 ms. Give it a real typing test and let me know.

Right — you want proper QMK-style permissive-hold behavior: Shift fires if you either hold past the term or press another key while it's down (including fast rolls), but a plain quick tap of ' alone still gives '. Tap-preferred can't do that (it ignores other keys), and plain balanced misfired on contractions. Let me get the target behavior exactly right, because "fast rolls" is doing a lot of work here and it's the crux of the contradiction we keep hitting.

The core tension: in Colemak, ' is right hand and the letters after it in contractions (don't→t, it's→s, I'm→m) are left hand. A "roll into another key = Shift" rule can't tell '+t (contraction, want ') apart from '+q (want Shift+q) purely by timing/interruption — both are ' followed quickly by an opposite-hand key.

QMK solves this with HOLD_ON_OTHER_KEY_PRESS combined with per-key or Retro/PERMISSIVE_HOLD tuning, but the thing that actually makes it livable for most people is positional hold-tap (only trigger the hold when the next key is on the opposite hand) — which for a right-hand ' still fires on left-hand letters, so it wouldn't fix contractions either. The honest truth: this specific key (apostrophe doubling as Shift, right pinky, Colemak) is the hardest possible case.

So before I implement, one decision:

Got it — true QMK permissive-hold, contraction risk accepted. I'll switch hsq to balanced with hold-trigger-on-release off (permissive-hold semantics), drop tap-preferred, and put quick-tap back to 0. balanced in ZMK = permissive hold: Shift fires on hold-past-term or when another key is pressed-and-released while ' is held (including fast rolls); a lone quick tap still gives '.

Done — CI green, pushed as 33b4c37.

'/RShift is now true QMK permissive-hold (balanced flavor):

• Hold past 200 ms → Right Shift (hold-and-wait, like QMK).
• Press another key while ' is down → Right Shift — including fast rolls. So '+q gives Q/! etc. without waiting.
• Lone quick tap → '.

This is exactly the QMK feel you described. The one accepted trade-off: since '+letter is the same gesture as a Shift roll, contractions (don't, it's) may occasionally capitalize — if that happens, Left Shift (Tab/Shift) is there for fast capitalization.

Firmware: https://github.com/BYK/zmk-config-corneview/actions/runs/29353311121

Two knobs if the feel needs nudging after you type on it:

• Contractions capitalizing too often → I can add require-prior-idle-ms back at a small value (e.g. 80-100 ms) — catches only genuinely fast mid-word rolls while keeping roll-to-Shift for deliberate combos.
• Shift not firing fast enough on rolls → lower the 200 ms term.

Give it a real typing session and tell me which way it leans.

Good call — this is the sweet spot: fast mid-word rolls (contractions) force ', but a deliberate roll after any pause still gives Shift. I'll add require-prior-idle-ms = 100 to hsq in both keymaps.

Done — CI green, pushed as 98c099f.

'/RShift now has the full QMK feel plus a contraction guard:

• Hold past 200 ms → Right Shift
• Roll into another key after a brief pause → Right Shift (deliberate combos work)
• Mid-word roll (another key within 100 ms) → forced ' → don't, it's, I'm type cleanly
• Lone quick tap → '

The 100 ms window is the discriminator: fast, continuous typing = you're mid-word = '; a distinct pause before the roll = you meant Shift.

Firmware: https://github.com/BYK/zmk-config-corneview/actions/runs/29353674882

That single number is the tuning knob if it leans wrong after a real session:

• Contractions still sometimes capitalize → raise it (120-150).
• Shift rolls feel like they're being eaten as ' → lower it (70-80).

Give it a proper typing test and report which way it drifts.

Let me trace the exact mechanics here, because the fix depends on which key is which.

Your ! gesture is: hold RSE (right-outer thumb, &lt_tog RAISE RAISE, hold-preferred) + hold a Shift + tap a number-row key. When you do it fast and get "only Shift," the RAISE layer isn't engaging in time — so the key you press resolves on the base layer instead of RAISE.

The likely culprit is a hold-tap "queue" stall: when two hold-tap keys (Shift and RSE) are pressed almost simultaneously, ZMK processes them in press-order and the first one can hold up resolution of the second. If your Shift press lands first and it's balanced, it waits to decide, delaying RAISE from activating — so the number key falls through to base.

Before I pick the fix, I need to know which Shift you're rolling with, because it changes the answer:

Ah — that changes everything. You mean the bottom-right ] key (&hrs RAISE RBKT), which on hold engages RAISE+Shift together via the mo_shift macro. That's a completely different mechanism than two separate thumb keys. Let me look at exactly how it's wired.

Found it. The problem is the balanced flavor on hrs combined with how it resolves against the number key you press.

Here's the sequence when you're fast: you press ] (hrs), then quickly tap a number key. With balanced, hrs waits to decide hold-vs-tap until the interrupting key is released. During that wait the mo_shift macro hasn't run yet, so RAISE isn't active — meaning when balanced does resolve to "hold" and fires the macro, the number key press already got queued/processed. The result you see: Shift applies (macro's LSHFT press) but the layer wasn't up when the digit registered → you get the base-layer key, not the RAISE symbol.

The fix is hold-preferred on hrs. With hold-preferred, the instant you press the number key, hrs immediately resolves to hold → the macro fires → LSHFT + RAISE are both active before the number key is processed → you get the symbol every time, even fast. The only trade-off is a quick ]+letter roll would give the symbol instead of ], but ] is almost never immediately followed by another key mid-word, and quick-tap (200 ms) still lets you tap-then-hold to repeat ].

The CI check got interrupted. Let me find the run and watch it.

Done — CI green, pushed as 963ce17.

Fixed the RSE+Shift (bottom-right ]) fast-roll issue. The hrs behavior was balanced, which waited to decide until the number key was released — so on fast rolls the RAISE layer wasn't up yet and the digit fell through to the base layer (giving you Shift-only). Switched it to hold-preferred, which resolves the moment you press the number key → LSHFT + RAISE both activate before the digit registers → you get the symbol every time, even fast.

Trade-off: a quick ]-then-key roll would now trigger the symbol layer instead of ]. In practice ] is rarely immediately followed by another key, and quick-tap (200 ms) still gives you tap-then-hold ] repeat.

Firmware: https://github.com/BYK/zmk-config-corneview/actions/runs/29493999302

Note this only changed the bottom-right ] RAISE+Shift key. If you also sometimes make ! etc. by holding the RSE thumb + a separate Shift key and hit the same "only Shift" problem, that's a different code path (the thumb lt_tog vs. the two Shift behaviors) — let me know and I'll harden that one too. Give this a real typing test first.

Short answer: not with a plain &kp key — ZMK has no built-in "long-press any key → its shifted form" mode. But you can get exactly that behavior on specific keys with a hold-tap where tap = the key and hold = Shift+the key.

For example, to make , also type < when held:

cs: comma_shift {
    compatible = "zmk,behavior-hold-tap";
    #binding-cells = <2>;
    tapping-term-ms = <200>;
    flavor = "tap-preferred";   // only shifts on a deliberate hold
    bindings = <&kp>, <&kp>;
};

...then bind it as &cs COMMA LT (tap , / hold <).

A few important caveats:

• It's per-key, not global. You'd add a hold-tap for each key you want this on — there's no single toggle that applies it to the whole board.
• It costs you the hold slot. Many of your keys already use hold for something (Tab/Shift, '/RShift, ]/RAISE+Shift, [/GUI, thumbs, etc.). You can only add "hold = shifted" to keys whose hold is currently free — i.e. the plain letter/number keys.
• flavor matters. tap-preferred = shift only on a genuine long hold (safe for fast typing). balanced/hold-preferred would risk shifting during fast rolls, like the issues we just spent time fixing.
• There's a simpler special case: ZMK's &mt / mod-morph. If you want a key to send one thing tapped and another when a modifier is already held, that's mod-morph — but that's "morph when Shift is down," not "morph when long-pressed." For long-press, hold-tap is the right tool.

So: yes, achievable, but you tell me which keys you want it on and I'll wire up hold-taps for them.

What's the actual goal — is there a specific key (or a few) where you want long-press = shifted? Or are you trying to avoid reaching for Shift on the number/symbol row?

Makes sense — you want the RAISE number row to give symbols on a long press, without reaching for a Shift. So on RAISE: tap 4 → 4, hold 4 → $, and so on across the row.

This is very doable — I'd give each RAISE number key a tap-preferred hold-tap (num behavior) where tap = digit, hold = shifted digit. tap-preferred means only a deliberate long hold shifts, so fast number typing stays clean (same lesson as the ' fix).

Two things to decide first, because they shape the whole change:

Got it — number row + = and \ get long-press-shift, keep the existing methods too. Let me look at the current RAISE layer bindings to wire this precisely.

I'm reviewing the current keymap and thinking through the design. The number row currently has plain &kp bindings that I'll replace with a num hold-tap behavior — tap gives the digit, hold gives the shifted symbol. For the = key, it's currently &hs LSHFT EQUAL, and I need to decide how to handle its hold behavior. The user wants = to produce + on long press, but the existing &hs binding makes hold act as Left Shift, which serves a different purpose for symbol combos on the number row.

The tension is that ='s hold currently activates Left Shift (useful for shifting other keys), and the user wants to keep existing symbol methods while adding long-press. If I change ='s hold to output + directly, I lose the Shift-hold functionality. But the user explicitly asked for = to get long-press-shift to produce +, so I need to reconcile this — a single key can't both hold-as-Shift and hold-as-plus. Since ='s hold-Shift is one of the existing symbol methods they want to keep, but they also requested = → + on hold, these directly conflict on the same key. I need to clarify this conflict rather than silently pick one.

Actually, let me reconsider — the =/Shift key is one of the "existing symbol methods" the user wanted to keep. But now they're asking for = long-press to give +. These are mutually exclusive on the hold action. The user may not have realized ='s hold is already the Shift key that enables their symbol-typing method. I should flag this specific conflict and ask how they want to resolve it, since converting = hold to + would remove a symbol-input method they said to keep.

For the number keys and \, there's no conflict since those are plain &kp bindings with free hold slots. So 1-0 and \ can cleanly get the num hold-tap treatment. Only = is problematic.

Let me define the behavior and plan the bindings. I'll create a num hold-tap with tap-preferred flavor and a 200ms tapping term. ...

I'm implementing the long-press-shift behavior for the number keys and backslash, keeping = as Shift. First I'll define a num hold-tap behavior with tap-preferred flavor and a 200ms tapping term, then apply it to the number row bindings—tap gives the digit, hold gives the shifted symbol. For backslash, hold gives pipe. Since these are all on the right/left hand mix on the RAISE layer, tap-preferred keeps fast number entry clean while allowing deliberate holds for symbols.

Now I need to add the num behavior definition to both keymap files and update the RAISE layer bindings. Let me insert the behavior after the existing smt definition and before hrs. Actually, I'll place it right after hs or wherever fits cleanly in the behaviors block.Perfect — cleanest option. I'll add a num hold-tap (tap-preferred, tap = digit, hold = shifted symbol) and apply it to 1-0 and \, leaving = as-is. Let me add the behavior after hrs in both files.

Sure. Let me look at the current RAISE right side to plan the \ move.

Currently RAISE right side:

row1:  6    7    8    9    0    GUI
row2:  PGUP HOME UP   END   \   (trans)
row3:  PGDN LEFT DOWN RGT  (trans)(trans)

You want \ directly under GUI (col 12). GUI is at row1 col12; the slot under it is row2 col12, which is currently trans. Right now \ sits at row2 col11 (next to END). So I'll move \ from row2-col11 → row2-col12, and col11 becomes trans:

row2:  PGUP HOME UP   END  (trans)  \

Let me add the num behavior and update both files' RAISE rows. First the behavior:

Now the RAISE bindings in corne.keymap — number row gets num (tap digit / hold symbol), and move \ under GUI:

Now update the RAISE comment header in corne.keymap to reflect \ under GUI:

Now the same for corne_min.keymap. First the num behavior:

Now update the README RAISE section — diagram (\ under GUI) and the symbols description.

Let me verify the RAISE rows have exactly 12 columns each and commit.

Both correct: row1 = ESC + 10 num keys + LGUI (12), row2 = =/Shift + 3 media + 2 trans + PGUP/HOME/UP/END + trans + \/PIPE (12). Commit, push, watch CI.

Done — CI green, pushed as 65fb539.

Long-press symbols on RAISE (new num behavior, tap-preferred):

• Tap a digit → digit; hold it → its symbol: 1→!, 2→@, 3→#, 4→$, 5→%, 6→^, 7→&, 8→*, 9→(, 0→)
• \ → hold → |
• Because it's tap-preferred, fast number typing never accidentally shifts — you only get the symbol on a deliberate hold (>200 ms).

\ moved from beside END to directly under GUI (row 2, far-right column).

= untouched — still tap = / hold Left Shift, and the bottom-right ] RAISE+Shift method still works. So you now have three ways to get symbols.

Updated RAISE right side:

|  6  |  7  |  8  |  9  |  0  | GUI |
| PGUP| HOME|  UP | END |     |  \  |
| PGDN| LEFT| DWN | RGT |     |     |

Firmware: https://github.com/BYK/zmk-config-corneview/actions/runs/29499522913

If the 200 ms hold feels too long/short for popping a symbol, that's the tuning knob on the num behavior — say the word and I'll adjust.

Let me look at what we just changed — the num behavior is the most likely culprit since it now sits on every digit.

Ha — the arguments are swapped. In a hold-tap, bindings = <&kp>, <&kp> maps to <tap>, <hold>, so &num N1 EXCL means tap→N1, hold→!. That's correct in the behavior... but you're getting symbols on tap, which means the tap is resolving to the second position. That happens with tap-preferred only if... actually no. Let me re-read: you get symbols on quick tap, numbers on long hold — that's literally the reverse mapping, meaning the bindings are being read as &num N1 EXCL = tap !...

Wait — that only happens if the two params are reversed in usage. The behavior is fine; the fix is to swap the two arguments on every key so tap=digit lands first. Let me just flip them: &num EXCL N1 → no. Let me think clearly: current &num <A> <B> gives tap=A, hold=B. You report tap=symbol, hold=digit. So currently A=symbol somehow. Simplest reliable fix: swap so digit is the tap arg. Currently digit is already first (N1 EXCL)...

That contradiction means it's not the mapping — it's the flavor. Let me verify by checking ZMK semantics rather than guessing.

The docs confirm it: bindings = <&kp>, <&kp> maps first param = HOLD, second param = TAP (their mod-tap example is &mt LSHIFT A = hold Shift, tap A). So my &num N1 EXCL was actually hold N1, tap EXCL — the reverse of what I intended. That's exactly your symptom: tap gives the symbol, long-hold gives the digit.

Simplest correct fix: swap the two params on every num key so it reads &num <symbol> <digit> (hold = symbol, tap = digit). Let me flip them in both files.

Now I should update the comment on the num behavior in both files — it currently says "tap = the key, hold = its shifted symbol" but examples in the binding order matter. The comment describes intended feel which is still correct (tap digit, hold symbol), so it's fine. But let me fix the misleading inline example comment which said tap 4 -> 4, hold 4 -> $ — that's still what we want, so the comment is accurate. Good.

Let me verify no other stale num <digit> <symbol> ordering remains and commit.

Hmm, no output at all — the && chain stopped because the first grep found nothing (exit 1). That's actually the good result for the first pattern. Let me confirm the second pattern separately.

Both files correct now — &num <symbol> <digit> = hold symbol, tap digit. Commit, push, watch CI.

Done — CI green, pushed as d6d6c16.

The bug: ZMK hold-tap params are <hold>, <tap> (e.g. &mt LSHIFT A = hold Shift, tap A). I had written &num N1 EXCL, which meant hold 1, tap ! — the reverse. That's why you got symbols on tap and digits only on long hold.

Fix: swapped every param → &num EXCL N1 etc. Now:

• Tap a digit → digit ✅
• Long-hold → symbol (!@#$%^&*(), and \→|)

This is the same trap that bit us — worth remembering that the first param is always the hold action.

Firmware: https://github.com/BYK/zmk-config-corneview/actions/runs/29570738593

That was a real bug that CI couldn't catch (it compiles fine either way — the params are valid keycodes regardless of order). Flash it and numbers should type normally on tap again, with symbols on a deliberate hold.

I'm reducing the num behavior's tapping-term-ms from 200 to 125ms so symbols pop faster on hold. Let me update both keymaps.

The num block is identical in both files, so I'll target it with the surrounding context to make each edit unique.

Now commit, push, watch CI.

Done — CI green, pushed as a0e8516.

RAISE number keys hold timeout lowered 200 → 125 ms. Symbols now pop with a shorter deliberate hold (tap = digit, hold = symbol). Still tap-preferred, so fast number typing won't accidentally shift.

Firmware: https://github.com/BYK/zmk-config-corneview/actions/runs/29577803581

Heads up: at 125 ms the gap between "tap" and "hold" is tighter, so if you find digits occasionally coming out as symbols during quick-but-deliberate number entry, nudge it back up (140-150 ms is a good middle ground). Give it a test.

Two things here: bump num to 140 ms, and answer the bootloader question.

First the timeout change in both keymaps:

Now the bootloader question — yes, you already have it. On the ADJUST layer there's a &bootloader key (top-right corner). Let me confirm exactly where.

Confirmed — you already have &bootloader on the ADJUST layer, second row, right side (the BOOT key, position 11 — just left of the far-right corner). No tweezers needed.

How to trigger it:

1. Hold (or tap-toggle) the left-inner thumb to enter ADJUST.
2. Tap the BOOT key (2nd row, 5th key from the right on the right half).

That drops the half you tapped it on into the UF2 bootloader.

Important caveat for your split: &bootloader only resets the half you press it on. ADJUST spans both halves, so:

• Left half: enter ADJUST → the BOOT key is on the right half though...

Let me check that — the BOOT key is physically on the right half. So pressing it puts the right half into bootloader. To flash the left half, you'd need BOOT reachable while... actually since ADJUST is one layer across both halves and the key lives on the right half, it only ever bootloaders the right side. That's a gap. Let me look at whether there's a left-side option.

No — and this is the important gotcha. &bootloader only resets the half you physically press it on. It's not a synced/broadcast behavior; it runs locally on whichever side owns that key position.

Right now your only &bootloader key is on the right half (ADJUST row 2). So:

• Pressing it → right half enters bootloader. ✅
• Left half → you currently have no key combo → still tweezers. ❌

There are two spare &trans slots on the left half's ADJUST bottom row, so the clean fix is to add a second &bootloader on the left half too. Then each side has its own BOOT key and you never touch the pins again.

Looking at the ADJUST layout, the left half bottom row is CLMK | QWRT | CLR | _ | _ | _ — those last two &trans are free. I'll put BOOT on the left-half bottom-right free slot (mirrors the right side nicely).

Want me to add &bootloader to the left half on both keymaps? Here's exactly where it'd go:

Left ADJUST bottom row:  CLMK  QWRT  CLR  [BOOT]  ---

Honest answer: no, not with a single keypress — and it's a hard ZMK limitation, not a config gap.

Why: &bootloader executes locally on whichever MCU owns the key you pressed. Once a half enters the UF2 bootloader, its ZMK firmware has stopped running — so there's no mechanism to relay "also reset yourself" to the other half. ZMK has no "reset both halves" behavior, and the split link can't carry a command to a half that's already halted (or to halt it). People have asked for this upstream; it doesn't exist.

The practical reality: you flash the two halves separately anyway (each produces its own .uf2), so you generally only need to boot one side at a time. The realistic best setup is one BOOT key per half, each resetting its own side:

• Right half already has BOOT (ADJUST row 2).
• Add BOOT to the left half → then left-BOOT boots left, right-BOOT boots right. Tweezers retired for good.

The flashing flow becomes:

1. Enter ADJUST, tap left BOOT → left half mounts as USB drive → drag its .uf2.
2. Enter ADJUST, tap right BOOT → right half mounts → drag its .uf2.

That's the closest achievable thing to what you want. Shall I add the left-half BOOT key (both keymaps)? I'll place it on the left ADJUST bottom row where there are free &trans slots.