Unconventional C-a,C-e shortcut key behavior on word wrap

[mattmc3]

Summary

CTRL-A and CTRL-E don't behave properly in Zed on a Mac.

Steps to trigger the problem:

1. On macOS, type a really long long line with word wrapping on
2. Go to the beginning of the line
3. Hit CTRL-E to attempt to go to the true end of the line
4. Similarly, go to the end of the line and hit CTRL-A to attempt to go to the true start of the line

Actual Behavior:
C-a and C-e improperly behave like ⌘-LEFT and ⌘-RIGHT respectively. They go to the beginning/end of the soft wrap line, not the true line.

Expected Behavior:
Every Mac app (Notes, Pages, Safari, etc) makes C-a go to the true beginning of the line and C-e to the true end, not the soft wrap boundaries. ⌘-LEFT and ⌘-RIGHT are the shortcuts for softwrap begin/end. Zed should not by default be doing this differently.

Zed Version and System Specs

Zed: v0.173.8 (Zed)
OS: macOS 15.3.1
Memory: 64 GiB
Architecture: aarch64

[SomeoneToIgnore]

Unfortunately, it's not very clear from the macOS keymap json, but that action has a way to be configured:

zed/assets/keymaps/linux/emacs.json

Lines 27 to 28 in 10a6cd0

	"ctrl-a": ["editor::MoveToBeginningOfLine", { "stop_at_soft_wraps": false }], // move-beginning-of-line
	"ctrl-e": ["editor::MoveToEndOfLine", { "stop_at_soft_wraps": false }], // move-end-of-line

to jump to the end of the real line.

[mattmc3]

Thank you for pointing me in the right direction. Would you accept a pull request to change those booleans to a more standardized default behavior to conform with other Mac apps? Not sure if the Zed project values the Principal of Least Surprise, but this, in my view, is a clear case where the non-standard use should be the configuration change, not the other way around.

[SomeoneToIgnore]

to conform with other Mac apps

We seem to use different macOS apps it seems: I have just rechecked Sublime Text, VSCode and RustRover and neither of them jump to the end of the wrapped line when cmd-right is pressed, navigating at the line break first.

So, to me this works exactly as it should be.
Others may think differently though, so the PR has a chance to be accepted.

[mattmc3]

Respectfully, can you check again. CMD-left and CMD-right are working correctly in Zed - namely stopping at the soft wrap. It's C-a and C-e that behave differently. I verified in VSCode, Pages, Notes, Safari, SublimeText, and multiple others before submitting this issue.

[SomeoneToIgnore]

Oh, sorry, the emacs bindings, now I finally understand.
Yes, that makes total sense as this is what emacs is doing, thank you for pointing out.

[SomeoneToIgnore]

Happy to merge the PR after #25385 (comment)

[notpeter]

I believe @nathansobo wants to maintain the default behavior of ctrl-a stopping at the indent as an intentional deviation from the behavior of macos/vscode, but matching the behavior of Atom. Previously this behavior was mixed with stop_at_soft_wraps, but I've created a PR which separates this into it's own stop_at_indent option.

zed/assets/keymaps/default-macos.json

Line 95 in 1e12285

"ctrl-a": ["editor::MoveToBeginningOfLine", { "stop_at_soft_wraps": false, "stop_at_indent": true }],

PR:

• Add stop_at_indent for MoveToBeginningOfLine #25428

See previously:

• Revert "Match VSCode behavior for ctrl-a/ctrl-e on MacOS" #16246

[mattmc3]

Is it fair to say that personal preference and legacy Atom behavior aren't convincing reasons to deviate from the default expected behavior of other Mac apps? Are there other good reasons to use a non-standard behavior for C-a I'm not considering?

The common use case where I discovered the issue was multi-cursor editing multiple lines. Since Macs don't have a dedicated home button, ⌘-left and C-a having distinct and predictable behaviors is a big plus.

EDIT: Oh, I think I see now. There's a desire for C-a to stop at the first indent instead of going to the true start of a line? Regardless, I think the point can still be made that the C-a behavior seen in Apple apps (eg: XCode, Notes, Pages) and non-Apple Mac apps (Sublime, Emacs, VSCode) is the better default and configuring different behavior from that should be possible, but not the standard.

[notpeter]

I believe that the previous behavior of ctrl-a / ctrl-e was counter-intuitive (keyboard behavior should not change based on the width of the window or soft wrap settings) which is why I created and merged #15981) which was reverted in #16246.

I absolutely understand your position, but when looking into this issue I noticed it is not as cut and dry as I had assumed. Notably there are significant divergences in behaviors so necessarily there must be design choices as to which behavior(s) Zed decides to adopt/emulate. Some apps have the same behavior for all three inputs (e.g. home/ctrl-a/cmd-left behave identically) and many have divergent behaviors. Notably macOS and VSCode have the same behavior for ctrl-a / ctrl-e but diverge for home/end and cmd-left/right.

• Safari/Chrome:
  • home scrolls the document to top/bottom
  • cmd-left respects softwraps but cannot navigate past them
    • two presses of home on a softwrap line will not bring you to column 0
  • ctrl-a does not respect softwraps or indent
• VSCode (home/cmd-left have identical behavior, ctrl-a diverges)
  • home/cmd-left respects indent and softwrap
    • two presses on a softwrapped non-indented line == column 0
    • three presses on a softwrapped indented line == column 0
    • repeated presses on an indented line == toggles between column 0 and the indent
  • ctrl-a does not respect softwrap or indent
• JetBrains (all three have identical behavior)
  • respects softwraps or indents
  • two presses on a goes to non-character space prior to softwrap hangover
  • three presses on a softwrapped non-indented line == column 0
  • four presses on a softwrapped indented line == column 0
  • repeated presses on an indented line == toggles between column 0 and the indent
• Atom macOS (all three have identical behavior)
  • respects indented lines
  • respects softwraps but cannot navigate past them
  • repeated presses on an indented line == toggles between column 0 and the indent
• SublimeText
  • home scrolls the document to the top bottom
  • cmd-left respects indent and softwrap
    • two presses on a softwrapped non-indented line == column 0
    • three presses on a softwrapped indented line == column 0
    • repeated presses on an indented line == toggles between column 0 and the indent
  • ctrl-a does not respect softwrap or indent
• Emacs (ctrl-a/home identical; no cmd-left)
  • does not respect softwrap or indent
  • distinct key (meta-m) for jump to indent
• Nano (ctrl-a/home identical; no cmd-left)
  • respects softwraps
• Readline (bash/zsh/etc) - only ctrl-a/e work by default
  • successive ctrl-a navigates past continuations to the beginning of previous lines

    echo foo bar \
    baz jazz \
    twiz fizz
    # press enter, then press up into your command history
    

To be clear the decision point is whether in Zed, in the default keymap, ctrl-a should always go to column 0 (your PR, current main) or whether ctrl-a should instead bring you to the beginning of code at the indent point/column 0 with no indent (identical to previous Zed behavior with soft-wrap disabled). I'll touch base with @nathansobo to discuss further and will update this issue to reflect our thinking and how we decided to proceed with this PR:

• Add stop_at_indent for MoveToBeginningOfLine #25428

Thanks for your PR to improve the default keymap, I had identical changes in my user keymap and then later adopted the emacs keymap so haven't experienced that friction in a long time.