Thanks in advance for your bug report!

• Have you reproduced issue in safe mode?
• Have you used the debugging guide to try to resolve the issue?
• Have you checked our FAQs to make sure your question isn't answered there?
• Have you checked to make sure your issue does not already exist?
• Have you checked you are on the latest release of Pulsar?

What happened?

In investigating the regression from #810, we discovered some strange things about how these commands behave.

Here are three commands and how they are mapped in macOS right now:

• Cmd+Backspace invokes editor:delete-to-beginning-of-line. It operates on the buffer line.

  • This is technically not standard behavior for macOS; non-code editors treat this as “delete to the beginning of the screen line.” But it is how most editors behave; VS Code and Sublime Text delete to the beginning of the buffer line, and only TextMate deletes to the beginning of the screen line.

• Cmd+Delete (harder to invoke unless you have a full-size keyboard) maps to editor:delete-to-end-of-line. It operates on the screen line.

  • I can’t tell if this is intentional or not. It seems logical to me that this should delete to the end of the buffer line. VS Code does this. Don't know if there's a macOS standard here; neither Notes nor TextEdit does anything on Cmd+Delete for me.

• Ctrl-K — an obscure shortcut on macOS, but one that is usually implemented in native apps — maps to editor:cut-to-end-of-line. It operates on the screen line.

  • This is not at all standard on macOS; in other apps, Ctrl-K deletes to the end of the buffer line.
  • I traced this back to its original checkin about 11 years ago; the commit message suggested it was to match Sublime Text’s keymap. But in Sublime Text in the year 2024, Ctrl-K deletes to the end of the buffer line, and so does VS Code.

So we have several problems:

• There's a lack of parallelism in the key bindings. Since Backspace and Delete (or, technically, Delete and Fn+Delete on lots of Mac keyboards) do the same thing in opposite directions, users could reasonably expect for Cmd+Backspace and Cmd+Delete to perform equivalent actions in opposite directions.
• Whether that's reasonable to believe or not, we still name these two commands in such a way that would lead anyone to believe that they perform equivalent actions in opposite directions.
• Despite that, one operates in buffer coordinates, and the other operates in screen coordinates.
• I don't think we necessarily have to copy all of VS Code’s or Sublime Text’s core movement commands, but those editors behave identically to each other for these commands, and differently from us, and it seems like that was more of an accident than a purposeful decision on Atom's part.
• I'd bet money that this confusion is a result of the underlying confusion of how the methods themselves are named in the TextEditor, Selection, and Cursor classes.

Which methods are affected?

Let's go down the rabbit hole and study what happens when you invoke each of these.

• Cmd-Backspace: Invokes command editor:delete-to-beginning-of-line
  • Maps to TextEditor#deleteToBeginningOfLine
  • Calls Selection#deleteToBeginningOfLine
  • Calls Selection#selectToBeginningOfLine
  • Calls Cursor#moveToBeginningOfLine, which moves to the beginning of the buffer line
• Cmd-Delete: Invokes command editor:delete-to-end-of-line
  • Maps to TextEditor#deleteToEndOfLine
  • Calls Selection#deleteToEndOfLine
  • Calls Selection#selectToEndOfLine
  • Calls Cursor#moveToEndOfScreenLine, which moves to the end of the screen line
• Ctrl-K: Invokes command editor:cut-to-end-of-line
  • Maps to TextEditor#cutToEndOfLine
  • Calls Selection#cutToEndOfLine
  • Calls Selection#selectToEndOfLine… our friend from above, which we’ve proven operates on the screen line

What do we do about it?

First of all, we need not change how any existing API method behaves. But we should add some new methods that are unambiguous about whether they refer to buffer lines or screen lines.

If you look through TextEditor, you’d be hard-pressed to find other methods that are ambiguous about which coordinate system they use. They were all renamed long ago to avoid this kind of confusion.

These operate on buffer lines:

• TextEditor#deleteToBeginningOfLine
• Selection#deleteToBeginningOfLine
• Selection#selectToBeginningOfLine
• Cursor#moveToBeginningOfLine

We should keep them that way, but deprecate them; they should be aliases for other methods in which Line is replaced with BufferLine.

(There are no TextEditor#cutToBeginningOfLine or Selection#cutToBeginningOfLine methods, and I think we should keep it that way.)

These operate on screen lines:

• TextEditor#deleteToEndOfLine
• TextEditor#cutToEndOfLine
• Selection#deleteToEndOfLine
• Selection#selectToEndOfLine
• TextEditor#cutToEndOfLine

We should keep them that way, but deprecate them; they should be aliases for other methods in which Line is replaced with ScreenLine.

Some of these methods exist already, though

Selection…

…has selectToBeginningOfLine and selectToEndOfLine (which operate on buffer and screen coordinates, respectively) but also selectToEndOfBufferLine. There is no corresponding selectToBeginningOfBufferLine.

It has cutToEndOfBufferLine already.

Cursor…

…is a special case. It already has moveTo(Beginning|End)OfScreenLine, but its corresponding buffer versions are just called moveTo(Beginning|End)OfLine. These latter two should be deprecated and aliases should be added called moveTo(Beginning|End)OfBufferLine.

In summary…

Create these methods:

• Selection#selectToBeginningOfBufferLine

• Selection#selectToBeginningOfScreenLine

• Selection#selectToEndOfScreenLine

• Selection#cutToEndOfScreenLine

• Selection#deleteToBeginningOfScreenLine

• Selection#deleteToEndOfScreenLine

• Selection#deleteToBeginningOfBufferLine

• Selection#deleteToEndOfBufferLine

• Cursor#moveToBeginningOfBufferLine

• Cursor#moveToEndOfBufferLine

• TextEditor#selectToBeginningOfBufferLine

• TextEditor#selectToBeginningOfScreenLine

• TextEditor#selectToEndOfBufferLine (Selection has this one * already, but TextEditor does not)

• TextEditor#selectToEndOfScreenLine

• TextEditor#cutToEndOfScreenLine

• TextEditor#deleteToBeginningOfScreenLine

• TextEditor#deleteToEndOfScreenLine

• TextEditor#deleteToBeginningOfBufferLine

• TextEditor#deleteToEndOfBufferLine

Deprecate and alias these methods:

• TextEditor#deleteToBeginningOfLine -> TextEditor#deleteToBeginningOfBufferLine

• TextEditor#deleteToEndOfLine -> * TextEditor#deleteToEndOfScreenLine

• TextEditor#cutToEndOfLine -> TextEditor->cutToEndOfScreenLine

• Selection#deleteToBeginningOfLine -> Selection#deleteToBeginningOfBufferLine

• Selection#deleteToEndOfLine -> Selection#deleteToEndOfScreenLine

• Selection#cutToEndOfLine -> Selection->cutToEndOfScreenLine

• TextEditor#selectToBeginningOfLine -> TextEditor#selectToBeginningOfBufferLine

• TextEditor#selectToEndOfLine -> TextEditor#selectToEndOfScreenLine

• Selection#selectToBeginningOfLine -> Selection#selectToBeginningOfBufferLine

• Selection#selectToEndOfLine -> Selection#selectToEndOfScreenLine
Selection

• Cursor#moveToEndOfLine -> Cursor#moveToEndOfBufferLine

What do we do about the command names?

We can use the same strategy: keep the old command names, keep them doing the same things they've always done, but introduce new command names that are unambiguous.

And what do we do about the macOS keybindings?

That's up for discussion. I don't have any problem with remapping Cmd+Delete and Ctrl+K to match VS Code and Sublime Text, even if it's a change in behavior. Any user that is negatively affected by this will have an easy workaround; we can even mention it in the changelog if we want to.

But I'd be more than happy to hear rebuttals.

Pulsar version

1.118 (and all previous versions)

Which OS does this happen on?

❓ Other(Please specify in the OS details field below)

OS details

all OSes

Which CPU architecture are you running this on?

None

What steps are needed to reproduce this?

.

Additional Information:

No response