Incorrect control-A and control-E behavior with soft_wrap

[sethherr]

Check for existing issues

• [X] Completed

Describe the bug / provide steps to reproduce it

When editing a file that with soft wrapping:

• control-e goes to the end of the soft-wrap line
• control-a goes to the beginning of the soft-wrap line

These should go to the beginning and end of the line, not the soft wrapped character limit.

control-k behaves correctly, and deletes to the end of the line, rather than the soft-wrap line.

Environment

Zed: v0.97.5 (stable) OS: macOS 13.4.1 Memory: 32 GiB Architecture: aarch64

[failable]

I think that's desired behavior. If you want to go to the 'real' beginning/end of line, just ctrl a / ctrl e again.

[sethherr]

Oh, I didn't know about double pressing to go to the real beginning of the line. That's great @liebkne!

It seems a little surprising though, do other apps have that behavior?

Would it make sense to make ctrl + k do the same thing?

[notpeter]

I don't like Zed's handling of ctrl-e and ctrl-a with soft-wrap enabled. It is surprising that behavior changes depending on the width of my editor pane: "ctrl-e goes to the end of the line, unless your window is narrow and then you have to press ctrl-e twice".

So I took a survey:

Editors that ignore soft wrap when jumping to the beginning/end with ctrl-a/ctrl-e

• TextEdit
• EMacs
• VSCode
• Atom
• Sublime
• Native MacOS controls (e.g. this textbox in Chrome)
• Lapce (broken, but it tries)

Same as Zed (double tap when navigating thru a word wrap):

• GNU nano (esc $ to enable softwrap)
• Kate
• IntelliJ (kinda broken). First ctrl-e goes to the last non space at end of the soft-wrapped line. A second ctrl-e moves one character over after the trailing space. A third ctrl-e will jump you to the real end of the line.