[X] Have you used the debugging guide to try to resolve the issue?
[X] Have you checked our FAQs to make sure your question isn't answered there?
[X] Have you checked to make sure your issue does not already exist?
[X] 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-Kdeletes 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.
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)
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)
Thanks in advance for your bug report!
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+Backspaceinvokeseditor:delete-to-beginning-of-line. It operates on the buffer line.Cmd+Delete(harder to invoke unless you have a full-size keyboard) maps toeditor:delete-to-end-of-line. It operates on the screen line.Cmd+Deletefor me.Ctrl-K— an obscure shortcut on macOS, but one that is usually implemented in native apps — maps toeditor:cut-to-end-of-line. It operates on the screen line.Ctrl-Kdeletes to the end of the buffer line.Ctrl-Kdeletes to the end of the buffer line, and so does VS Code.So we have several problems:
BackspaceandDelete(or, technically,DeleteandFn+Deleteon lots of Mac keyboards) do the same thing in opposite directions, users could reasonably expect forCmd+BackspaceandCmd+Deleteto perform equivalent actions in opposite directions.TextEditor,Selection, andCursorclasses.Which methods are affected?
Let's go down the rabbit hole and study what happens when you invoke each of these.
Cmd-Backspace: Invokes commandeditor:delete-to-beginning-of-lineTextEditor#deleteToBeginningOfLineSelection#deleteToBeginningOfLineSelection#selectToBeginningOfLineCursor#moveToBeginningOfLine, which moves to the beginning of the buffer lineCmd-Delete: Invokes commandeditor:delete-to-end-of-lineTextEditor#deleteToEndOfLineSelection#deleteToEndOfLineSelection#selectToEndOfLineCursor#moveToEndOfScreenLine, which moves to the end of the screen lineCtrl-K: Invokes commandeditor:cut-to-end-of-lineTextEditor#cutToEndOfLineSelection#cutToEndOfLineSelection#selectToEndOfLine… our friend from above, which we’ve proven operates on the screen lineWhat 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#deleteToBeginningOfLineSelection#deleteToBeginningOfLineSelection#selectToBeginningOfLineCursor#moveToBeginningOfLineWe should keep them that way, but deprecate them; they should be aliases for other methods in which
Lineis replaced withBufferLine.(There are no
TextEditor#cutToBeginningOfLineorSelection#cutToBeginningOfLinemethods, and I think we should keep it that way.)These operate on screen lines:
TextEditor#deleteToEndOfLineTextEditor#cutToEndOfLineSelection#deleteToEndOfLineSelection#selectToEndOfLineTextEditor#cutToEndOfLineWe should keep them that way, but deprecate them; they should be aliases for other methods in which
Lineis replaced withScreenLine.Some of these methods exist already, though
Selection…
…has
selectToBeginningOfLineandselectToEndOfLine(which operate on buffer and screen coordinates, respectively) but alsoselectToEndOfBufferLine. There is no correspondingselectToBeginningOfBufferLine.It has
cutToEndOfBufferLinealready.Cursor…
…is a special case. It already has
moveTo(Beginning|End)OfScreenLine, but its corresponding buffer versions are just calledmoveTo(Beginning|End)OfLine. These latter two should be deprecated and aliases should be added calledmoveTo(Beginning|End)OfBufferLine.In summary…
Create these methods:
Selection#selectToBeginningOfBufferLineSelection#selectToBeginningOfScreenLineSelection#selectToEndOfScreenLineSelection#cutToEndOfScreenLineSelection#deleteToBeginningOfScreenLineSelection#deleteToEndOfScreenLineSelection#deleteToBeginningOfBufferLineSelection#deleteToEndOfBufferLineCursor#moveToBeginningOfBufferLineCursor#moveToEndOfBufferLineTextEditor#selectToBeginningOfBufferLineTextEditor#selectToBeginningOfScreenLineTextEditor#selectToEndOfBufferLine(Selectionhas this one * already, butTextEditordoes not)TextEditor#selectToEndOfScreenLineTextEditor#cutToEndOfScreenLineTextEditor#deleteToBeginningOfScreenLineTextEditor#deleteToEndOfScreenLineTextEditor#deleteToBeginningOfBufferLineTextEditor#deleteToEndOfBufferLineDeprecate and alias these methods:
TextEditor#deleteToBeginningOfLine->TextEditor#deleteToBeginningOfBufferLineTextEditor#deleteToEndOfLine-> *TextEditor#deleteToEndOfScreenLineTextEditor#cutToEndOfLine->TextEditor->cutToEndOfScreenLineSelection#deleteToBeginningOfLine->Selection#deleteToBeginningOfBufferLineSelection#deleteToEndOfLine->Selection#deleteToEndOfScreenLineSelection#cutToEndOfLine->Selection->cutToEndOfScreenLineTextEditor#selectToBeginningOfLine->TextEditor#selectToBeginningOfBufferLineTextEditor#selectToEndOfLine->TextEditor#selectToEndOfScreenLineSelection#selectToBeginningOfLine->Selection#selectToBeginningOfBufferLineSelection#selectToEndOfLine->Selection#selectToEndOfScreenLineSelectionCursor#moveToEndOfLine->Cursor#moveToEndOfBufferLineWhat 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+DeleteandCtrl+Kto 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