# Gestures

> Spacebar cursor and numpad swipes, swipe-down-to-hide, the hint flick, backspace word-delete, and volume-key cursor control.

URL: https://wmkeyboard.pages.dev/typing/gestures/
Section: Typing

Past tapping and long-pressing single keys, WM Keyboard has a few drag gestures that move across or along a key. The spacebar, backspace and the volume rocker each do something different when you swipe instead of tap. This page covers what those drags do once they're moving. Where a gesture belongs to another page, it links there rather than repeating it.

## Which swipe fires: quick vs hold

Typing / Gestures

The spacebar has two independent swipe slots: **Quick swipe on the spacebar** (default **Language**) and **Press and hold, then swipe** (default **Cursor**). Which one a drag resolves to depends on *when* it starts relative to the long-press delay, not on how far it travels. If a quick swipe sometimes counts as a hold, raise **Hold delay** on the same page: it gives the spacebar a delay of its own, from 50 to 1500 ms. The full timing engine, the language-switch behavior and the hold-drag picker list all live on [Switching languages](https://wmkeyboard.pages.dev/languages/switching/). This page covers the other two things a slot can be set to: **Cursor** and **Numpad**.

space-swipe — A spacebar swipe resolves to whichever action its slot is set to.

Each slot's options are **Nothing**, **Language**, **Cursor**, **Numpad** or **Keyboards**. Keyboards opens Android's own "Choose input method" list, for changing to a different keyboard app. On **Press and hold, then swipe** it needs no swipe: holding the spacebar past the hold delay opens the list. On the quick swipe it opens as soon as the drag starts. A tap with no movement always types a space, whatever either slot is set to.

**Space swipe distance** sets how far your finger has to move sideways before a press on the spacebar counts as a swipe: 12 dp by default, from 6 to 60 dp. Raise it if your thumb slides a little on its way to a space and switches the language or moves the cursor.

Setting **Press and hold, then swipe** to Cursor or Numpad costs one thing: holding the spacebar no longer opens the [hold-drag language picker](https://wmkeyboard.pages.dev/languages/switching/#holding-to-drag-through-the-list). A hold can only mean one thing, and that slot is where you said what it means. The picker is still on the 🌐 key's long press and on a quick swipe set to Language.

## Moving the cursor with a spacebar swipe

  typing/spacebar-cursor-swipe — Dragging the spacebar moves the text cursor a character at a time.

Set a slot to **Cursor** and the drag moves the text cursor instead of typing. The caret steps one character for every 16 dp of horizontal travel, in whichever direction you drag. That distance is a slider of its own, **Cursor speed**, which sits under the two swipe pickers and runs 4–32 dp. Shorter moves the caret faster. Any composing text in progress (a word mid-transliteration, say) commits first, without autocorrect, so the cursor lands where you can see it rather than jumping past a word that was still being corrected.

Typing / Gestures / Speed up long cursor swipes

**Speed up long cursor swipes** (off by default) makes a long drag cover more text. The first 48 dp of travel move at your Cursor speed, so a short nudge of a few characters stays exact. After that, each character costs less travel, and by 240 dp the cursor is moving at **Top cursor speed**, 4× by default (2× to 16×). It keeps that pace for as long as you keep dragging the same way, the way a mouse's middle-button scroll does. Turn back and the cursor drops to Cursor speed again and builds up from there, so fixing an overshoot is as exact as a short nudge. A small wobble the other way doesn't count as turning back. With the 2-D cursor touchpad on, up and down movement speeds up the same way, on its own, one line at a time.

**Move the cursor directly** (off by default) changes what a swipe sends. Normally each step is a left or right arrow key, which is what a hardware keyboard would send and what every editor understands. A few fields read an arrow as something else: a search box with a dropdown steps through its suggestions, and some file managers put the cursor back at the start of a name being renamed. With this on, the swipe places the cursor by moving the selection instead, and the app sees no key at all. It needs the app to have told the keyboard where the cursor is; when one hasn't, the arrow keys are used as before. With the 2-D cursor touchpad on, the same goes for up and down in a one-line field like a search box or a file name: up puts the cursor at the start of the text and down at the end, where an up or down arrow would have stepped into the box's suggestions or out of the field. In a field with several lines, up and down stay arrow keys so the cursor follows the app's own line wrapping. Selection mode and a held shift stretch the selection the same direct way, so a search box sees no Shift+arrow either.

**Keep moving while held** (off by default) is for the line that outruns the spacebar. The cursor keeps going by itself, about eight characters a second, in two cases: at once when your finger is past either end of the spacebar, and after a pause of about half a second when you hold your finger still at least a fifth of the spacebar's width away from where the swipe began. Lift your finger and it stops. A short swipe, or settling the finger near where you started, never sets it off.

Once the cursor is going by itself, the drag works like a joystick. Draw your finger back towards where the swipe began and the cursor slows down instead of stepping back, down to about a sixth of its speed close to the start; move out again and it speeds back up. It stops while your finger is back over the starting point, and turns round only once you cross it and go out on the other side.

**Whole keyboard as touchpad** (off by default) hands the drag the whole key area once a swipe has turned into a cursor drag, the way SwiftKey's does. The keys dim, and a second finger landing on them types nothing until you lift. Your finger could always wander off the spacebar mid-drag; what changes is that the edges Keep moving while held uses are the sides of the keyboard instead of the ends of the spacebar, and its hold-still reach is a fifth of the keyboard's width. When the drag also moves up and down (the 2-D cursor touchpad, or Swipe up for the touchpad), the keyboard's top and bottom edges keep the cursor moving between lines the same way.

Typing / Gestures / 2-D cursor touchpad

**2-D cursor touchpad** (off by default) turns the same drag into a touchpad. A vertical component now steps the cursor up and down through the text too, on the same Cursor speed distance. Both axes send real arrow-key events rather than computing a raw text offset, so vertical movement follows whatever line-wrapping the app is doing instead of guessing at it. Move the cursor directly changes that in one-line fields, where up and down go to the start and end of the text. Only movement that is mostly up or down counts toward a line step: the small wobble of a sideways drag drains away instead of adding up into a jump to another line. The toggle only appears once one of the two swipe slots above is set to Cursor, or Swipe up for the touchpad is on, and Cursor speed appears beside it.

Typing / Gestures / Swipe up for the touchpad

**Swipe up for the touchpad** (off by default) opens the 2-D touchpad from a swipe up, with no hold first. Swipe up from the spacebar, keep your finger down, and the cursor follows it left, right, up and down until you lift. The finger has to travel 80 dp up, and more up than sideways, before the touchpad opens, so a tap that rolls a little still types a space and there is room left below to move the cursor down. You feel a tick when it opens. For the length of your long-press delay after that, the cursor stays put, so the swipe that opened the touchpad doesn't move it. After that, the rest of the upward swipe still doesn't move the cursor a line up: pause for a moment or move down first, and from then on up and down move the cursor too. Sideways swipes are untouched: they still run the two slots above, so the default quick swipe keeps switching the language. This works whatever the slots are set to and whether the 2-D cursor touchpad switch is on, and every cursor setting on this page applies to the drag. With **Keep moving while held** and **Whole keyboard as touchpad** both on, the touchpad scrolls by itself at every edge of the keyboard: the sides keep the cursor moving along the line, and the top and bottom 24 dp keep it moving up or down, about five lines a second, until you move back or lift. The band the drag started in doesn't count, so starting on a spacebar near the bottom edge never sets it off.

Typing / Gestures / Swipe up for the number pad

**Swipe up for the number pad** (off by default) opens the number pad from a swipe up the spacebar, at any speed, the way SwiftKey does. Like the touchpad it waits for a short way up, so a tap that slides still types a space, and sideways swipes keep their own actions. With both swipe-up switches on, the touchpad wins.

Typing / Gestures / Cursor magnifier

**Cursor magnifier** (on by default) shows the line of text around the cursor, enlarged, in a bubble over the text while the drag moves the cursor. It comes up once the drag has resolved to Cursor and goes when you lift your finger. With **Press and hold, then swipe** set to Cursor it comes up sooner, the moment the hold is long enough, with a short vibration, so you know the next swipe moves the cursor before you start it. With the magnifier off, the vibration alone says so. The bubble is the keyboard's own drawing of the text the app hands it, not a zoomed picture of the screen, so it uses the keyboard's colours and font. It sits above the cursor, or below it when the cursor is too close to the top of the screen, for apps that tell the keyboard where their cursor is, which most do. For an app that doesn't, or when the cursor is scrolled out of sight or hidden behind the keyboard, it sits just above the keyboard instead. In a password field it shows dots, never the password. It never takes a touch and it goes the moment you lift your finger. It appears beside Cursor speed, and the [trackpad](https://wmkeyboard.pages.dev/tools/trackpad/) has a separate switch for the same bubble.

The same drag selects text instead of moving through it while selection mode is on, on either axis. Turn the mode on from the toolbar's [Selection mode](https://wmkeyboard.pages.dev/tools/text-editing/#selection-mode) tool, or hold that tool down and scrub the spacebar with your other thumb. A Shift you pressed yourself does it too, lock included, exactly as [Shift+Arrow](https://wmkeyboard.pages.dev/tools/text-editing/#hold-shift-to-select) would: lock Shift, then scrub. A Shift the keyboard armed by itself at a sentence start doesn't count, so an ordinary drag never selects behind your back.

## Swiping in from the edge to go back

Typing / Gestures / Swipe in from the edge to go back

Android's own back gesture, a swipe in from the side of the screen, works over the keyboard on most phones. Some phones keep it off the keyboard, so it has to start above it, which is half a screen up. With this setting on, a swipe that starts within the outer 16 dp of the keyboard's left or right edge and moves at least 40 dp inward, more across than up or down, does what Back does: it closes the open panel (the voice panel with its recording, a search, the emoji panel), or the keyboard when nothing is open. It acts when you lift your finger, and the key it started on types nothing.

It's off by default. A glide that starts right at the edge and heads inward looks exactly the same, so with this on, start glides on the edge keys a little way in. A second finger on the keys while the swipe starts means typing, and the swipe is left alone.

## Swiping down to hide the keyboard

Typing / Gestures / Swipe down to hide the keyboard

A straight downward drag on the spacebar dismisses the keyboard, once it clears a short threshold and is steeper than it is wide. It's off by default, so a stray vertical wobble mid-drag never closes the keyboard on you. Turning it on changes nothing about holding the spacebar: with both swipe slots set to Nothing, a hold still repeats the space and never opens the language picker.

The 2-D cursor touchpad, when it's on, claims the vertical axis ahead of this only once a drag has actually resolved to the Cursor action. Hold time decides that resolution, same as any other spacebar swipe. With the defaults (quick swipe = Language, press and hold then swipe = Cursor), a downward flick fast enough to clear the hide threshold before the long-press delay elapses still belongs to the quick-swipe slot, so it dismisses the keyboard. Only a drag held past that delay hands the vertical axis to the touchpad.

There's a second, separate **Swipe down to hide** toggle for the toolbar strip, under Appearance → Toolbar. Two words shorter in the settings list, and a different element it acts on: a downward swipe on the toolbar, not on the spacebar. The two are independent switches, and both ship off.

## Swiping down on a key for its hint

Typing / Gestures / Swipe down to type the hint

Every key with press-and-hold characters shows the first of them in its corner: the 1 on q, the accents on a vowel, the currency signs on $. With this on, a short, quick swipe straight down on the key types that corner character outright, with no hold to wait out. It's the same character the popup would put first, on any key that has one, on every layer. Off by default.

The swipe has to be all five things at once: down (within about 30° of straight down), short (between half a key's height and two of them), straight, quick (under a quarter of a second from touch to lift), and, with glide typing on, not lifted on another letter. A swipe that ends in the middle of another letter key is a word like "ok", so glide typing gets it; the narrow seams between keys don't count, so a flick that overshoots onto the row below still types the hint. A drag that misses any of those is whatever it always was, so a slow pull down is still a glide and a tap that drifts is still a tap. The keys with a drag of their own keep it: the spacebar's swipes, backspace's delete swipe, the modifier and ?123 drags, and a [flick key's](#flick-keys) arms.

The one real cost is with [glide typing](https://wmkeyboard.pages.dev/typing/glide-typing/). A very fast glide of a short word that lifts on the seam between two keys rather than on the second letter can still read as a flick and type the hint instead. Ending on the letter, the way a glide usually does, keeps the word. On a layout whose rows line up without the usual half-key stagger, the key straight below is a whole key, so a flick there has to stop short of the next row.

## Swiping up on a letter for its capital

Typing / Gestures / Swipe up for a capital

The same flick the other way. With this on, a short, quick swipe straight up on a letter types its capital, so a single capital in the middle of a word or a name needs no trip to Shift. With [two-thumb typing](https://wmkeyboard.pages.dev/typing/glide-typing/#typing-with-both-thumbs) on, the capital joins the word your thumbs are building instead of standing alone. On a key that has a shifted character of its own, such as a number-row key with a symbol above it, the swipe types that character instead. Keys whose Shift changes nothing (a digit with no shifted twin, a script without capitals) don't take the swipe. It doesn't touch Shift either: a Shift you armed is still armed for the next letter. Off by default.

The rules are the ones the hint flick uses, pointed up: within about 30° of straight up, between half a key's height and two of them, straight, and under a quarter of a second. When [Words on the keys](https://wmkeyboard.pages.dev/typing/words-on-the-keys/) shows a word on the key, a swipe up still takes that word, as it always has. The glide rule is the mirror image too: with glide typing on, a swipe that lifts in the middle of another letter, "de" from d to e for instance, is the word, and only one that ends between keys can type a capital instead. With glide typing off there is no word to make, so a flick up off a middle-row letter types its capital even when it ends on the key above.

## Flick keys

Typing / Gestures / Show flick arms on keys

Some keys carry more than one character. A tap types the one in the middle; a short swipe from the key in one of eight directions types the one at that edge or corner instead. The [Japanese Flick](https://wmkeyboard.pages.dev/languages/cjk/#japanese-input) pad has always worked this way, with four arms, and the shipped **English flick (3×3)** layout takes it further in the MessagEase manner: all twenty-six letters on nine big keys, with `o` in the middle carrying q, u, p, c, b, g, d and j around it. Enable it under Languages like any other layout. Bangla has the same board twice, typing through Avro or Khipro: **Avro flick (3×3)** and **Khipro flick (3×3)**. Any key of any layout can be given arms of its own in the [layout editor](https://wmkeyboard.pages.dev/languages/custom-layouts/#editing-a-key), and an arm can run an action, such as moving the cursor, as readily as it types.

Each key draws its arms small, in the hint colour, at the edge or corner you swipe towards, so you can see what a swipe will type before you make it. **Show flick arms on keys** turns that drawing off, which leaves the face to the centre character the way the kana pad looked before. A layer can differ: in the [layout editor](https://wmkeyboard.pages.dev/languages/custom-layouts/), **Show flick arms here** on a layer with flick keys (or on the Numpad's panel editor) shows or hides them for that layer alone, so the number pad can keep its arms while the kana pad goes without. Once your finger moves towards an arm, or rests on the key for a quarter of a second, a **Flick popup** over the key shows the centre and every arm in a 3×3 cross, with the one your finger is heading for lit. A quick tap types the centre without it popping up; turn it off if the arms on the face are enough and you'd rather nothing covered the keys around it. The arm lights up with a short buzz the moment it is chosen.

**Flick distance** is how far the finger has to travel from where it landed before the press reads as a flick rather than a tap, 22 dp by default. Past that, the swipe's direction picks the nearest arm the key actually has, so a key with only four edge arms still has the generous quarter-circle each of them always had, a key with all eight gets a 45° sector for each, and a swipe towards an edge or corner that carries nothing types the centre character, as a drifting tap always did.

Two more things a flick key does, both borrowed from FlickBoard and Thumb-Key. Swipe out to a letter and back again to where you started, and the swipe types that letter's capital: `q` from a swipe up-left on `o`, `Q` from the same swipe brought more than halfway back. That only applies to an arm that has a capital of its own (or a **with Shift** form set in the editor); on a kana arm, an action arm or an arm whose shift changes nothing, coming back to the centre cancels to a plain tap, exactly as before. And a held flick key still opens its press-and-hold alternates, since the hold only starts once the finger has stayed inside the flick distance.

A flick key can also be all swipes, with nothing in the middle: turn on **Swipes only** for it in the [layout editor](https://wmkeyboard.pages.dev/languages/custom-layouts/#editing-a-key), or import an Unexpected Keyboard layout that has keys like that. A tap on a swipe-only key types nothing. **Tap a swipe-only key to see its swipes** makes that tap bring up the key's flick popup for a moment instead, so you can check what each swipe types; it works even with **Flick popup** off. It's off by default.

With glide typing on, a letter with flick arms shares each swipe with the glide. That matters most on a layout with characters on every corner, such as one brought over from Unexpected Keyboard. Nothing is taken from the key while the swipe could still be a flick. It becomes a glided word once it can't be one: it turns, it reaches the middle of another letter in a direction no arm points, or it travels past **Flick reach**, 141% of the key's diagonal by default. A swipe that lifts before any of that types its arm, even when it overshot into the next key, which a corner flick on a phone-sized key nearly always does. So "er" from an `e` whose arms are all on its corners glides as soon as your finger reaches `r`, "the" glides once it turns at `h`, and a flick up-right off `d` types its é even if it ends inside `r`.

**A flick onto a letter glides a word** settles the one case that is left: a short straight swipe from a letter onto its neighbour, along the way an arm points. Off, the default, it types the arm, so you tap those two-letter words. On, lifting inside the neighbour types the word, and a flick has to stop short of the next key. Until the keyboard has decided, a glide that starts on one of these keys can show the flick popup and buzz for the arm for a moment.

### Flicks off the edges and off special keys

Flicks belong to keys, not to the edges of the keyboard. A swipe down off the bottom row, up off the top row or outward off the first or last key in a row is that key's arm in that direction, so it does something only where you have given the key an arm in the [layout editor](https://wmkeyboard.pages.dev/languages/custom-layouts/#editing-a-key). Nothing is reserved for an edge on its own.

The special keys take arms too: Enter, Shift, ?123, ABC, the globe, the emoji key, the space bar and the rest, keys set to repeat while held included. An arm on one of them types text or runs an action, and the tap is still the key's own. Enter with `?` on its flick up types one `?`, without sending and without a new line. ⌫ takes arms and keeps its swipe and its repeat: forward delete on its flick up is the usual one, and it repeats while your finger stays out on the arm. A direction with an arm belongs to the arm, the delete swipe keeps the others, and a press held still until the repeat starts is a hold, not a flick. The arrow keys work the same way: word left and right on the side flicks of ← and →, page up and down on ↑ and ↓, and a still hold still moves the cursor over and over. That goes for the keys of the arrow keys row too, and for any key you set to repeat while held. The space bar takes arms on the same terms: put [No space](https://wmkeyboard.pages.dev/typing/glide-typing/#the-space-after-a-glided-word) on its flick up and it sits under your thumb, while the directions without an arm keep the spacebar's swipes. With an arm on one side, a swipe the other way still moves the cursor or switches language, and the hold is unchanged. A down arm takes the place of **Swipe down to hide**, and an up arm the place of **Swipe up for the touchpad**. A swipe waits for the flick distance before it starts, so it never runs off with a flick.

Changing a key's action in the layout editor clears its text arms, so a letter turned into Shift doesn't keep typing the letter's arms. Flicks off the edges stay a key's own.

Where two gestures could claim the same swipe, the rule is fixed rather than guessed, and the layout editor says so under the flick pad of a key where an arm takes something over:

- **An arm on Shift, Ctrl, Alt or Meta replaces [dragging from that key](#dragging-from-a-modifier-key).** On a key with arms the swipe is the arm; a modifier key without arms keeps the drag.
- **An arm on ?123 or ABC replaces the drag that peeks at the other layer.** Holding ?123 still and tapping a key, the [symbol chord](#chords-with-123), is a hold and not a swipe, so it works either way. So do the other still holds: ?123 held for the number pad and the globe held for the language picker.
- **A key with text arms gives up [Swipe down to type the hint](#swiping-down-on-a-key-for-its-hint).** Its own down arm, if it has one, is what a swipe down types.
- **A capital stays out-and-back.** On a top-row letter with an up arm, a flick up types the arm, and swiping out to it and back again types the arm's capital, the same as any other arm.
- **Glide typing never starts on a special key**, so arms there cannot cost you a word. On a letter, the arm and the glide share the swipe by the reach rules above.

## Swiping to add 's

Typing / Gestures / Swipe to add 's

The apostrophe is rarely a key of its own, so a possessive usually costs a long press and a tap. Pick a key here, comma, full stop or a real apostrophe key if the layout has one, and a short straight swipe from that key to s adds `'s` to the word before the cursor: "developer" becomes "developer's". Off by default.

The same swipe to another letter adds a contraction instead:

| Swipe to | Adds | Example |
|---|---|---|
| s | `'s` | what → what's |
| t | `'t` | don → don't |
| d | `'d` | she → she'd |
| m | `'m` | I → I'm |
| l | `'ll` | we → we'll |
| r | `'re` | they → they're |
| v | `'ve` | you → you've |

`'t` only goes on a word ending in n, so "what" never becomes "what't". A word that already has an apostrophe isn't extended again, and a word in capitals gets its suffix in capitals: "WHAT'S".

While you swipe, a line runs from the key to your finger, the same line a [modifier drag](#dragging-from-a-modifier-key) draws, so you can see the swipe is being read.

It's a gesture in its own right, not a glide-typing feature. It works after a tapped word, after a glided one, and on the word you're still typing, with glide typing on or off. A space after the word moves behind the `'s`, so you get "developer's " and never "developer 's". The chosen key still types its own character when you press it. Holding it still opens its long-press popup as usual, but once your finger starts to move the swipe owns the stroke, so a slow swipe no longer opens the popup and types `!`. A stroke that isn't the swipe types the key if you lift back on it, and nothing if you lift anywhere else. A short flick down still types the hint when [Swipe down to type the hint](#swiping-down-on-a-key-for-its-hint) is on.

The shape is what separates it from a glide: short and straight, its path no more than 1.6× the straight line between the two keys. A real word glided from the same key to one of those letters wanders further than that, so it decodes as a word. The spacebar can't start this swipe, since a stroke off the spacebar is always a spacebar swipe. It only extends English words: any word on an English layout, and on another language's layout with English among its secondary languages (Banglish on Avro, for one), a word spelled in Latin letters. A word still being typed on Avro counts when its preview shows it in English. Glide typing and handwriting never start from the chosen key, so the swipe works even on a layout that puts that key right beside a letter.

## Opening the numpad with a swipe

Set a slot to **Numpad** and the [numeric keypad panel](https://wmkeyboard.pages.dev/tools/text-editing/#the-numeric-keypad) opens the moment your drag crosses the initial touch slop. There's no further distance to cover. The swipe triggers the panel and then goes inert until you release, and the release types nothing. It's the same panel that ?123's long-press and the toolbar's Numpad tool open. See [Text editing](https://wmkeyboard.pages.dev/tools/text-editing/) for what's on it.

## Your own keys on the spacebar long press

Typing / Gestures / Spacebar long press keys

Type the characters you want into this field, with a space between each one, and holding the spacebar opens them in the same popup a letter key's accents use. Emoji, punctuation, a signature character, anything you can type into the box. Leave the field blank (the default) and nothing changes.

The field is deliberately blunt about what it costs: keys you put here take the spacebar's long press over completely. The [hold-drag language picker](https://wmkeyboard.pages.dev/languages/switching/#holding-to-drag-through-the-list) no longer opens, and neither does the space repeat. Both of those are still reachable elsewhere. The 🌐 key opens the picker on a hold and cycles on a tap, a spacebar swipe still switches language, and a second tap still types a second space. Clear the field to get the hold back.

Swipes are untouched. The popup only opens on a hold that stays still, so a quick swipe, a hold-then-swipe and the swipe down to hide all behave exactly as they did.

Once the spacebar carries keys, it draws the first one small in its top right corner, the same corner hint every other key uses. That hint is the one thing on the keyboard that says the long press changed, so leave **Press and hold hints** on if you want it. It lives on the [Key press](https://wmkeyboard.pages.dev/reference/settings/keypress/) screen and ships on.

A layout can carry its own set instead. Open a layout in the [layout editor](https://wmkeyboard.pages.dev/languages/custom-layouts/), tap the spacebar, and the alternates fields are there like on any other key. The setting comes first in the popup, and the layout's own keys follow it.

## Deleting more than a character with backspace

Key press / Delete keys

  typing/backspace-word-swipe — Dragging backspace to the left deletes text a word at a time instead of a character at a time.

**Swipe to delete** (on by default) lets a leftward drag on ⌫ take out more than the one character a press does. Backspace treats tap, hold-to-repeat and this swipe as one gesture. A press that stays still starts the normal hold-to-repeat once **Time before a key repeats** has elapsed, exactly as described on [Keys & typing basics](https://wmkeyboard.pages.dev/typing/basics/#multi-touch-and-key-repeat). Moving left past a small slop cancels that repeat and switches to the swipe. Backspace owns the whole stroke: glide typing, handwriting and the floating-word flick never start from it, even though the key sits right beside the bottom letter row, so neither a swipe nor a held, repeating backspace that drifts onto the letters types a word on top of what it deletes. That holds with **Swipe to delete** off too, and the same goes for ⌦.

**Swipe deletes** picks what one step of that swipe takes off:

- **Words** (the default) clears a sentence in one pull.
- **Characters** walks back a letter at a time, which is the finer tool when the fix is inside a word rather than at the end of it. A whole multi-part emoji, or a whole conjunct in a script that asks for it, still counts as one character, the same as a backspace press does.

Each step costs a certain amount of leftward travel. In Words mode the cost shrinks as you go, so clearing a whole sentence is one long pull rather than a series of flicks. The first word costs the most: **Word delete distance**, 72 dp by default and adjustable 32–120 dp in the same Delete keys group. Every word after it costs less, on a fixed curve derived from that one number, down to a floor past which extra words get no cheaper. In Characters mode there is no curve at all: every character costs the same **Character delete distance**, 20 dp by default and adjustable 8–48 dp, so the count stays easy to follow.

### Seeing what the swipe will delete

**Show what you will delete** (on by default) makes the swipe select the text instead of deleting it as the finger passes over it. The highlight grows a word or a character at a time, so you can see exactly how far the gesture has got, and the delete happens when you lift your finger. The highlight is not a selection you made, so the selection actions bar stays away while it is up.

While the highlight is up the swipe is still undoable: dragging back to the right shrinks it a step at a time, and dragging all the way back to where the swipe started leaves the text alone entirely. The gesture retraces its own steps, so a word that cost a short pull on the shrinking curve gives itself back for the same short pull.

Turn the setting off to get the older behaviour, where each word or character goes the moment the swipe passes it. Deleted text cannot be given back, so dragging right only re-anchors the gesture, and the next word costs the full first-word distance again instead of picking up where the shrinking curve left off. A few editors cannot hold a selection while the keyboard drives it, and a search box drawn by the keyboard itself (emoji search, for one) has no cursor to select with. The swipe falls back to deleting as it goes in both cases, with no setting to change. It does the same over a word that is still being converted, such as pinyin or Vietnamese Telex, so what is left of the word is still read as one.

### Swiping up to clear everything

**Swipe up to clear all** (off by default) empties the whole text box from a swipe straight up on ⌫. Once your finger has gone as far up as the first word of a sideways swipe costs (the **Word delete distance**, 72 dp by default), every bit of text in the box is selected, and lifting deletes it. Bring your finger back down below halfway before you lift and the selection goes away with nothing deleted. The text is always selected first, whatever **Show what you will delete** is set to, because a whole message is a lot to lose to a stray flick.

The swipe has to be steeper than it is wide, so a leftward word swipe that drifts upward stays a word swipe. It works in the keyboard's own text boxes too. A text box that shows the keyboard only part of a long text can't be selected whole, and there the swipe does nothing rather than leave the rest behind. A backspace key you gave a flick up in the [layout editor](https://wmkeyboard.pages.dev/languages/custom-layouts/) keeps its flick.

### Swiping up or down to delete lines

**Swipe up or down to delete lines** (off by default) turns the two vertical swipes on ⌫ into line deletes. A swipe up deletes back to the start of the line the cursor is on. With the cursor already at the start of a line, it deletes the whole line above, so each swipe up takes one more line. A swipe down deletes to the end of the line, then the line below. Keep your finger out after the swipe and it goes on a line at a time, the way holding delete repeats. With **Swipe up to clear all** on as well, the swipe up still clears everything and only the swipe down deletes lines. A delete key your layout already gave an up or down swipe keeps its own. The same two steps are **Delete line** and **Delete line forward** in the layout editor's actions, for any key or swipe.

### Holding delete to clear words

Key press / Timing

**Holding delete clears words** (off by default) changes what the hold does, not what the swipe does. With it on, a delete key that stays still under your finger starts taking one whole word per repeat once **Time before a key repeats** has elapsed, instead of one letter. A single press is untouched and still deletes one character, so nothing you do quickly changes.

Word clearing gets its own speed, **Word delete interval** (140 ms by default, adjustable 60–500 ms), which only appears while the setting is on. It is deliberately slower than **Delete repeat interval**: at the letter speed of 50 ms a held key would empty a paragraph before you could lift your finger.

The words come off exactly as a swipe step takes them, so the whitespace next to the cursor goes with the word beyond it, and a run of punctuation counts as a word of its own. Holding still stops on its own once there is nothing left to delete.

## Deleting forward with ⌦

Key press / Delete keys

⌦ is not on any built-in typing layout. Add one to a row, to a key's press-and-hold alternates, or to the [text-editing pad](https://wmkeyboard.pages.dev/tools/text-editing/) in the [layout editor](https://wmkeyboard.pages.dev/languages/custom-layouts/), and it gets the same three gestures backspace has, each pointed the other way: a press deletes the character *after* the cursor, a hold repeats, and **Swipe on forward delete** (on by default) lets a rightward drag take whole words or characters ahead of the cursor.

The finger travels the way the deletion travels, which is the only difference in the gesture. Everything that shapes it is shared with backspace rather than doubled: **Swipe deletes**, **Show what you will delete**, **Word delete distance** and **Character delete distance** all govern both keys, so tuning the pull on one tunes it on the other. **Holding delete clears words** covers ⌦ too, clearing the words after the cursor.

Where you put a delete key does not change what it is. The text-editing pad's own ⌫ and ⌦ are these keys, not a weaker copy of them: the swipe, the preview, the word-clearing hold and the delete repeat interval all apply there exactly as they do on the letters row.

One step deletes any trailing whitespace plus the run of same-kind characters behind the cursor, where letters and digits count as one kind and punctuation as another. That's what stops a step from stalling on a run like `...` or a string of dashes. It also means a word glued to punctuation (a contraction, a trailing comma) can take more than one step to clear, since the letters and the punctuation are different kinds and each gets its own step.

A few things a word-delete step does specially, rather than falling back to plain character deletion:

- If there's an active text selection, one step clears the whole selection instead of doing word math.
- If a word is still mid-composition (a transliteration buffer, for a phonetic layout), one step clears the entire composing word in one go.
- Inside a panel's own search box (emoji, clipboard or dictionary search, a plugin's text field, the typing-test box) or mid-stroke on a handwriting panel, word deletion steps down to one character at a time. Word-deleting the field hidden behind the overlay would be invisible and wrong, so it doesn't try.

See [Sound & vibration](https://wmkeyboard.pages.dev/typing/feedback/) for the **Vibrate on delete swipe** haptic that ticks on each word this gesture removes.

## Dragging from a modifier key

Drag from Shift onto a letter and lift, and you get the capital: one movement instead of a shift tap and then the letter. A band stretches from the key you started on to your fingertip while you drag, drawn in the [glide typing](https://wmkeyboard.pages.dev/typing/glide-typing/) trail's colour and width. It stays a straight line rather than tracing the path your finger took, because the chord is the two keys at its ends and the route between them means nothing. While you drag from Shift the letters turn to capitals, and the key under your finger lights up the way a pressed key does, so you can see which capital the lift will type. The same light follows your finger from Ctrl, Alt and Meta, on any key that has a combination to send.

Ctrl, Alt and Meta keys work the same way, and send the combination to the app: Ctrl to C copies, Ctrl to Z undoes, Ctrl to Enter sends the message in the apps that bind it. Shift does that too on any key that isn't a letter, so Shift to Enter is a real Shift+Enter and Shift to Tab tabs backwards.

A capital dragged out of Shift is typed, not sent as a key press, so the word still gets its suggestions, its autocorrect and its spot in the learned words. Shift's own tap, double-tap for caps lock, and press-and-hold all still work exactly as they did.

Every layout has a Shift key. None of the shipped ones have a Ctrl, Alt or Meta key, so add one from the [layout editor](https://wmkeyboard.pages.dev/languages/custom-layouts/#editing-a-key), or import a layout that already carries a modifier row.

A few rules keep the drag from firing when you didn't mean it:

- Lift outside the key grid and nothing happens. That's the slide-away cancel every key has.
- Wander off the modifier and back onto it, and it acts like a plain tap: Shift arms, Ctrl arms, and a second tap locks either.
- Keys that only change what the keyboard shows have no combination to send, so landing on ?123, the emoji key or the globe does nothing. Nor does Shift onto Ctrl, or either onto itself. (Dragging *from* ?123 is a gesture of its own, below.)
- A letter your device's keyboard map can't name (Bengali letters, currency signs, combining marks) sends nothing under Ctrl rather than typing itself. Shift is unaffected by this, since it types the character rather than sending a key press.

## Dragging from ?123 or ABC

Drag off ?123 and the symbols come up under your finger. Lift on one and it types, and the letters are back before you've moved your hand. It's the quick way to drop in a single symbol or a piece of punctuation without two trips through the layer key, and it's the gesture the stock Android keyboards have had for years.

ABC works the same way in the other direction. Drag off it and the letters show for as long as you hold, so a layer of your own can type one letter without leaving. Starting from the ?123 key of the first symbols page reaches the second one, where the arrows and the maths signs live, exactly as a tap on it would.

The drag works from a panel too. Put ?123 or ABC on the text editing pad, the Numpad or any other [panel layout](https://wmkeyboard.pages.dev/languages/custom-layouts/#panel-layouts), drag off it, and that layer shows over the panel for as long as you hold. Lift and the panel is back, with the emoji or clipboard list still where you left it. A panel isn't one of the keyboard's layers, so ABC on a panel always shows the letters.

While you drag, the key under your finger lights up the way a pressed key does, and a straight band stretches from the key you started on to your fingertip, the same one the [modifier drag](#dragging-from-a-modifier-key) draws.

Hold still over a key and its press-and-hold popup opens. Slide onto the character you want, lift, and that's what you get. This popup always follows your finger, whatever **Choose without lifting** is set to, because lifting is what ends the gesture: a popup waiting for a separate tap could never be answered here.

Letters arrive lowercase, since the Shift key is back on the layer you came from. **Shifted letter on press and hold** (Key press → Press and hold shortcuts, off by default) puts each letter's capital at the end of its popup, which is how you get one out of this gesture.

Nothing about the keyboard's own layer changes while you hold. A tap on ?123 still switches layer and stays there, and a press that never travels is a tap.

A few rules keep the drag from firing when you didn't mean it:

- Lift outside the key grid and nothing happens, the same slide-away cancel every key has.
- Lift on a key that only moves the keyboard around, such as the ABC key now sitting where you started, Shift, the emoji key or the globe, and nothing is typed. Sliding back to where you began is how you cancel.
- An ABC key on the letters layer has no other layer to show, so a drag off it does nothing at all.
- If you held the key long enough to open its own popup first (a ?123 key with alternates of its own), that popup keeps your finger and the layer stays where it is.

## Swiping with several fingers

Typing / Gestures / Multi-finger swipes

Put two, three or four fingers on the keys and swipe them the same way together, and the keyboard runs an action instead of typing. Each finger count has its own four directions, so there are twelve swipes to bind. Out of the box only two-finger swipes do something:

| Swipe | Does |
| --- | --- |
| Two fingers up | Selects all the text |
| Two fingers left | Undo |
| Two fingers right | Redo |
| Two fingers down | Paste |

Tap any of the twelve rows to change it. The list is the same one the [layout editor](https://wmkeyboard.pages.dev/languages/custom-layouts/#editing-a-key) offers for a key, so a swipe can do anything a key can: type a piece of text, open a tool or a panel, run a text-editing step, switch to a layer or another keyboard app, send Tab or an arrow, or fire a broadcast for an automation app. **No action** empties a slot, default or not, and **Reset swipe actions** at the end of the list puts all twelve back.

A line follows each finger while the swipe is on, in the [glide typing](https://wmkeyboard.pages.dev/typing/glide-typing/) trail's colour, width and length, and fades once you lift.

The swipes also work on the keys under a tool that types into a box of its own, such as [Translate](https://wmkeyboard.pages.dev/tools/translate/), a search box or a note. There select all, copy, cut, paste and undo act on that box's text, the way its own selection bar does, and not on the app behind the keyboard. Redo has nothing to undo back in those boxes, so it does nothing there.

Fast typing is never mistaken for a swipe. Nothing is decided until every finger on the keys has travelled about 28 dp, all of them the same way. A typist rolling from one key to the next lifts long before that, and the keys type as they always did. Lifting any finger before the swipe is recognised hands the whole touch back to the keys.

## Chords with ?123

Typing / Gestures / Chords with ?123

Hold ?123 still with one finger and tap a key with another, and the keyboard runs the action you gave that key instead of typing it. Let go of ?123 afterwards and you're still on the letters. Out of the box there's one chord: ?123 and L switches to your next language.

Hold ?123 a moment and every key with a chord shows it in a small label at the top of its face, so you can see what's bound before you tap.

**Add a chord** asks for the key, as the one character it types, then offers the same list of actions as a [multi-finger swipe](#swiping-with-several-fingers): a piece of text, a tool or panel, a text-editing step, a layer, another keyboard app, Tab or an arrow, or a broadcast for an automation app. Tap a chord's row to change it, or pick **No action** to remove it. **Reset chords** puts the list back to the default.

A few things keep chords out of your way:

- A key with no chord types as it always did, even with ?123 held.
- The chord needs ?123 to be down first and held for a moment. Tapping ?123 and rolling straight onto the next key is too quick to count, so the layer switch works as before.
- [Dragging off ?123](#dragging-from-123-or-abc) still shows the symbols. Only a still ?123 is a chord.
- Once a second finger lands, ?123's own press and hold (its popup, or the number pad) stays shut for that press. Held on its own, it opens exactly as before. A ?123 with nothing to open on a hold now switches layer when you let go, rather than partway through the hold.
- Chords are off during a [typing test](https://wmkeyboard.pages.dev/tools/utilities/#testing-your-typing-speed).

Chords suit [two-thumb typing](https://wmkeyboard.pages.dev/typing/glide-typing/#typing-with-both-thumbs) in particular. There, flick characters on a letter stop a swipe starting on it, and a hold on a letter fires when a thumb rests there while the other types. A key held still is never part of a swipe, so one thumb on ?123 and a tap from the other is a shortcut that never collides with typing.

## Swipes on keys

Typing / Gestures / Swipes on keys

[Flick keys](#flick-keys) are built into a layout, one layout at a time, in the layout editor. Swipes on keys are the same short swipes set up once here and laid over whichever layout is on screen. Put `1` up and to the right of Q and it is there on QWERTY, AZERTY, Colemak and every other layout with a Q, the way Unexpected Keyboard keeps its numbers on the top row's corners.

**Add a key** asks for the key, as the one character it types, then shows its eight directions around it. Tap a direction to pick what a short swipe that way does: a piece of text, or any action a [multi-finger swipe](#swiping-with-several-fingers) can run, such as copy, undo, a tool or an arrow. **No action** clears it. Each key with swipes gets a row of its own that lists them, and tapping the row brings the directions back.

**Add a preset** merges a ready-made set into yours:

| Preset | Puts |
|---|---|
| Numbers | 1 to 0 up and to the right on the top row |
| Symbols | `! @ # $ % ^ & * ( )` up and to the left on the top row |
| Editing shortcuts | Select all, copy, paste, cut, undo and redo down and to the left on A C V X Z Y |

A preset replaces only the directions it fills, so your other swipes on those keys stay. **Remove all key swipes** takes every one off, and turning **Swipes on keys** off keeps them stored but off the keys.

Once a key has swipes it behaves like any other flick key. Its swipes are drawn small on its face (unless **Show flick arms on keys** is off), the flick popup and **Flick distance** apply, and glide typing shares the stroke by the same rules: a swipe that turns, reaches the middle of another letter where no swipe points, or passes **Flick reach** glides a word. Three things to know:

- The layout comes first. If a layout already has a swipe in a direction, that swipe stays and yours for the same direction is ignored there, so the English 3×3 board and the Japanese flick pad are not rewritten by a preset meant for QWERTY.
- Only the letters page gets them. The symbols pages keep their keys as they are.
- A key with swipes gives up [Swipe down to type the hint](#swiping-down-on-a-key-for-its-hint) and the slide to select, since the flick owns that key's stroke. A key whose layout makes its hold repeat or run an action is left without swipes, so it keeps that hold.

## Volume keys as a cursor control

Typing / Volume keys

**Volume keys move the cursor** (off by default) repurposes the hardware volume rocker while the keyboard is on screen: volume down moves the cursor one character left, volume up moves it one character right. Holding a volume key repeats for free, riding Android's own hardware key-repeat rather than a separate timer. Both the press and the release are swallowed, so the app underneath never sees a stray volume keypress. It applies only while the keyboard is actually shown. Once it closes, the volume keys go back to controlling volume. With [Selection mode](https://wmkeyboard.pages.dev/tools/text-editing/#selection-mode) on, or with a Shift you pressed yourself still up, each press selects a character instead of stepping past it, so the rocker drags a selection out.

  typing/volume-cursor-control — With Volume cursor control on, the hardware volume keys move the text cursor instead of the volume.

**Release the keys while audio plays** (on by default) hands the volume keys back to ordinary volume control the instant something is playing: music, a video, a podcast. Typing a reply never costs you the ability to turn the sound down. The keys return to the cursor the moment playback stops. This is re-checked on every key press rather than latched once, so starting or stopping playback mid-typing takes effect immediately. Turn it off if you'd rather the volume keys always moved the cursor while the keyboard is open, playback or not.

## Gestures that live on other pages

A few more drags belong to features big enough to have their own page, so they're only linked here:

- **Language switching** (the spacebar's Language swipe, the hold-drag picker list, and the globe key's tap-vs-long-press) is fully covered on [Switching languages](https://wmkeyboard.pages.dev/languages/switching/).
- **Swiping across the letters** to write a whole word, or to draw handwriting instead, is one setting with two outcomes. See [Glide typing](https://wmkeyboard.pages.dev/typing/glide-typing/) for the default word-swipe mode and [Handwriting](https://wmkeyboard.pages.dev/tools/handwriting/#handwriting-without-opening-the-panel) for drawing ink over the keys.

A printable table of every gesture on one page lives at [Gesture cheat sheet](https://wmkeyboard.pages.dev/reference/gestures/).

## Options

Typing / Gestures

| Setting | Default |
| --- | --- |
| Quick swipe on the spacebar | Language |
| Press and hold, then swipe | Cursor |
| Space swipe distance | 12 dp (6–60 dp) |
| 2-D cursor touchpad | Off |
| Cursor speed | 16 dp (4–32 dp) |
| Speed up long cursor swipes | Off |
| Move the cursor directly | Off |
| Keep moving while held | Off |
| Whole keyboard as touchpad | Off |
| Swipe up for the touchpad | Off |
| Swipe up for the number pad | Off |
| Top cursor speed | 4× (2–16×) |
| Cursor magnifier | On |
| Swipe in from the edge to go back | Off |
| Swipe down to hide the keyboard | Off |
| Swipe down to type the hint | Off |
| Swipe up for a capital | Off |
| Show flick arms on keys | On |
| Flick popup | On |
| Tap a swipe-only key to see its swipes | Off |
| Flick distance | 22 dp (8–48 dp) |
| Flick reach | 141% (80–200%) |
| A flick onto a letter glides a word | Off |
| Swipe to add 's | Off |
| Arrows on the spacebar | On |
| The spacebar shows | Language |
| Spacebar text | Blank (live language name) |
| Typing speed on the spacebar | Off |
| Swipe to delete (backspace) | On |
| Swipe deletes | Words |
| Show what you will delete | On |
| Word delete distance | 72 dp (32–120 dp) |
| Character delete distance | 20 dp (8–48 dp) |
| Swipe on forward delete | On |
| Holding delete clears words | Off |
| Word delete interval | 140 ms (60–500 ms) |
| Volume keys move the cursor | Off |
| Release the keys while audio plays | On |
| Multi-finger swipes | On |
| Two fingers up / left / right / down | Select all / Undo / Redo / Paste |
| Three and four fingers, any direction | Nothing |
| Chords with ?123 | On |
| ?123 + L | Next language |
| Swipes on keys | On, with no keys set |

Open the **Typing** tile in settings, or search "Gestures", "Delete keys" or "Volume keys". The last two rows live under Typing / Key press rather than Delete keys, and Word delete interval only appears while Holding delete clears words is on. Cursor speed and Cursor magnifier only appear while a swipe slot is set to Cursor. Swipe deletes, Show what you will delete and the two step distances only appear while Swipe to delete is on, and the two distances are one setting each: Words mode shows Word delete distance, Characters mode shows Character delete distance. The Gestures group's language-switching settings (Arrows on the spacebar, The spacebar shows, Spacebar text, Typing speed on the spacebar) are covered on [Switching languages](https://wmkeyboard.pages.dev/languages/switching/#swiping-the-spacebar) instead of here. For the field-by-field breakdown see [Typing settings](https://wmkeyboard.pages.dev/reference/settings/typing/).

## Details & edge cases

- **Numpad is a discrete action, not a distance-based one.** Cursor keeps stepping for as long as you keep dragging. A swipe assigned to Numpad only needs to clear the initial slop once: the panel opens immediately and the rest of the drag does nothing.
- **A flick key keeps its stroke until the stroke can't be a flick.** Handwriting, the floating-word flick and the hint and capital flicks leave a key with flick arms alone, whichever way the finger goes. Glide typing watches instead of taking over at the edge of the key: a swipe that turns, reaches another letter where no arm points, or passes the flick reach is a glided word, and anything shorter and straighter is the arm, overshoot included. This holds with two-thumb typing too. A key whose arm moves the cursor or deletes keeps the whole stroke, since a held arm has already done its work by the time the finger wanders off. On the English 3×3 board glide typing never starts at all, which is by design: the letters are on the arms, not under a glide path.
- **A hint flick is judged when the finger lifts, never while it's moving.** Nothing is claimed early, so a downward stroke that turns out to be longer, slower or bendier than a flick is decoded as the glide or read as the tap it always was. The one stroke it does take from glide typing is a fast, straight, short one that lifts off any other letter, so a short glided word that ends on its last letter never qualifies.
- **The 's swipe is judged at the lift too, and never claims a stroke a glide could want.** Glide typing doesn't start strokes on punctuation keys, so a stroke off the comma or full stop is never a word in the first place, whether glide typing is on or off. Only a swipe that actually changed the field keeps the lift; one with nothing behind the cursor to extend lands as the key's own tap.
- **Two settings hide the keyboard on a downward swipe, two words apart.** "Swipe down to hide the keyboard" lives here under Typing → Gestures and applies to the spacebar. "Swipe down to hide" under Appearance → Toolbar applies to the toolbar strip. They don't affect each other, and both are off out of the box.
- **The 2-D cursor touchpad only takes precedence over swipe-down-to-hide once a drag has resolved to Cursor.** Hold time decides which slot governs a drag. With the defaults (quick swipe = Language, press and hold then swipe = Cursor), a fast downward flick inside the long-press delay belongs to the quick-swipe slot and dismisses the keyboard instead of moving the cursor down through lines.
- **A held delete key and a swiped one can disagree about the unit, and that's on purpose.** Holding delete clears words is a Key press setting about the repeat; Swipe deletes is a Delete keys setting about the drag. One can be Words while the other is Characters.
- **Swiping the wrong way on a delete key cancels the repeat and does nothing else.** Either key claims a drag past the slop in either direction, so the hold stops as soon as your finger travels. Only travel in the key's own direction takes text: leftward on ⌫, rightward on ⌦.
- **Backspace's word-delete acceleration resets on a reversal, not on release.** Dragging right mid-swipe doesn't bring back a deleted word. It only means the *next* leftward word costs full travel again instead of the shrunk amount.
- **A multi-finger swipe takes the whole touch once it is recognised.** A word you had started gliding with the first finger is dropped, a key press under any of the fingers types nothing, and a chord or layer drag fires nothing at the lift. The swipe is counted by the most fingers that were down at once, so a third finger that lands a moment late still makes it a three-finger swipe.
- **Not inside a typing test, and not over a panel without typing keys.** The test counts every keystroke in order, so it keeps the keys to itself; a panel such as emoji or the numpad has no letters to swipe on.
- **Two-finger swipes stand aside while [two-thumb typing](https://wmkeyboard.pages.dev/typing/glide-typing/) is on.** There two thumbs moving together are two halves of a word, so only three and four finger swipes run. The two-finger rows say so.
- **A swipe that leans more than about 35° off straight up, down, left or right is no swipe at all**, and neither is one where the fingers head different ways, such as a pinch. Those fall through to the keys.
- **Volume-key cursor control re-checks "is audio playing" on every key press**, not once at the start of the drag, so control passes back and forth live as playback starts and stops.
- **A drag off ?123 or ABC is never read as a word either**, for the same reason as a modifier drag: ?123 sits against the bottom row beside the spacebar, and a touch that starts there belongs to the layer drag.
- **A drag off a modifier or Shift key is never read as a word.** Glide typing and handwriting both measure where your finger landed, and a touch that started on one of those keys belongs to the chord drag. Shift is the one you may notice: it sits against the bottom letter row, so a glide that used to be startable from its inner edge now capitalizes instead. Start the word one key further in.
- **A stroke from the spacebar is never read as a word either.** Glide typing, handwriting and the floating-word flick all leave it alone, so a language or cursor swipe is always that swipe. Glide typing used to decide by distance to the nearest letter, measured in key widths, and on a phone turned sideways the keys are twice as wide as a row is tall, so the whole spacebar counted as "near a letter" and a language swipe glided a word instead.
- **Caps lock is not a drag source.** It's a state you leave switched on, so holding it for one key means nothing, and Shift is one key away for anyone who wants that.
- **Ctrl to A, C, V or X goes through the same route as the toolbar's copy and paste.** Those four reach text fields that a raw key event doesn't, such as web views and Compose fields. **Ctrl shortcuts as raw key events**, under Typing / Key press, opts back out of that for terminal apps. Ctrl+V sends the real key anyway when the clipboard holds a picture or anything else that isn't text, so a web page with its own paste handler can take it. Whether the page accepts it is up to the page.
- **Word deletion falls back to character-by-character inside overlay search boxes** (emoji, clipboard or dictionary search, a plugin text field, the typing-test box, or an in-progress handwriting stroke), since word-deleting the real field hidden behind the overlay would be invisible and wrong.

See [Keys & typing basics](https://wmkeyboard.pages.dev/typing/basics/) for tap and long-press behavior on single keys, [Switching languages](https://wmkeyboard.pages.dev/languages/switching/) for the spacebar's Language swipe and the hold-drag picker, [Glide typing](https://wmkeyboard.pages.dev/typing/glide-typing/) for swiping across the letters, and [Text editing](https://wmkeyboard.pages.dev/tools/text-editing/) for the numpad panel and the other cursor tools.