Repository: ianstormtaylor/slate
File: packages/slate-react/src/components/editable.tsx (TypeScript)

Code before:
                    Transforms.move(editor, { reverse: !isRTL })
                  } else {
                    Transforms.collapse(editor, { edge: 'start' })
                  }

                  return
                }

                if (Hotkeys.isMoveForward(nativeEvent)) {
                  event.preventDefault()

                  if (selection && Range.isCollapsed(selection)) {
                    Transforms.move(editor, { reverse: isRTL })
                  } else {
                    Transforms.collapse(editor, { edge: 'end' })
                  }

                  return
                }

                if (Hotkeys.isMoveWordBackward(nativeEvent)) {
                  event.preventDefault()

                  if (selection && Range.isCollapsed(selection)) {
                    Transforms.move(editor, { unit: 'word', reverse: !isRTL })
                  } else {
                    Transforms.collapse(editor, { edge: 'start' })
                  }

                  return
                }

                if (Hotkeys.isMoveWordForward(nativeEvent)) {
                  event.preventDefault()

                  if (selection && Range.isCollapsed(selection)) {
                    Transforms.move(editor, { unit: 'word', reverse: isRTL })
                  } else {
                    Transforms.collapse(editor, { edge: 'end' })
                  }

                  return
                }

                // COMPAT: Certain browsers don't support the `beforeinput` event, so we
                // fall back to guessing at the input intention for hotkeys.
                // COMPAT: In iOS, some of these hotkeys are handled in the
                if (!HAS_BEFORE_INPUT_SUPPORT) {
                  // We don't have a core behavior for these, but they change the
                  // DOM if we don't prevent them, so we have to.
                  if (

Review comment (suggestion):
I like this change, but a simple collapse isn't _quite_ how the range selection scenario works, at least on macOS. It collapses and then moves.

```suggestion
                  if (selection && !Range.isCollapsed(selection)) {
                    Transforms.collapse(editor, { edge: 'start' })
                  }
                  
                  Transforms.move(editor, { unit: 'word', reverse: !isRTL })
```

Some apps collapse to the focus rather than the start, which is how I prefer to do it, but there is no consistency even amongst Apple apps so that's more of a personal choice.

Code after:
                    Transforms.move(editor, { reverse: !isRTL })
                  } else {
                    Transforms.collapse(editor, { edge: 'start' })
                  }

                  return
                }

                if (Hotkeys.isMoveForward(nativeEvent)) {
                  event.preventDefault()

                  if (selection && Range.isCollapsed(selection)) {
                    Transforms.move(editor, { reverse: isRTL })
                  } else {
                    Transforms.collapse(editor, { edge: 'end' })
                  }

                  return
                }

                if (Hotkeys.isMoveWordBackward(nativeEvent)) {
                  event.preventDefault()

                  if (selection && Range.isExpanded(selection)) {
                    Transforms.collapse(editor, { edge: 'focus' })
                  }

                  Transforms.move(editor, { unit: 'word', reverse: !isRTL })
                  return
                }

                if (Hotkeys.isMoveWordForward(nativeEvent)) {
                  event.preventDefault()

                  if (selection && Range.isExpanded(selection)) {
                    Transforms.collapse(editor, { edge: 'focus' })
                  }

                  Transforms.move(editor, { unit: 'word', reverse: isRTL })
                  return
                }

                // COMPAT: Certain browsers don't support the `beforeinput` event, so we
                // fall back to guessing at the input intention for hotkeys.
                // COMPAT: In iOS, some of these hotkeys are handled in the
                if (!HAS_BEFORE_INPUT_SUPPORT) {
                  // We don't have a core behavior for these, but they change the
                  // DOM if we don't prevent them, so we have to.
                  if (
                    Hotkeys.isBold(nativeEvent) ||
                    Hotkeys.isItalic(nativeEvent) ||