Ctrl-Delete should not delete the word after whitespace.

[RaymondLim]

1. Open a CodeMirror demo page in a browser.
2. Set the cursor before some whitespaces.
3. Hit Ctrl-Delete.

Result: Not only all the whitespaces are deleted, but the word immediately after the whitespaces is also deleted. Expected: Like other editors on Windows, only the whitespaces are deleted.

[marijnh]

Please see the thread at https://groups.google.com/d/topic/codemirror/WOoqlDuIbaY/discussion for background, especially Peter Flynn's message. What CodeMirror does by default corresponds to Sublime Text. There's also a built-in command (delWordAfter) that implements the Emacs approach.

You appear to want something else, but the word "should" is not something that belongs in this discussion. Different editors do different things. Any chance you can implement this in external code?

[marijnh]

Oh, interesting. It seems that ST actually behaves differently when it sits in front of a single space, compared to what happens when multiple space characters follow the cursor. The intrigue deepens.

[peterflynn]

I'm not super familiar with the semantics of Ctrl+Del in various editors, but a few notes for added color:

1) CodeMirror doesn't appear to fully follow the notes in that earlier discussion thread -- in particular the bit that says "the start & end of each line is always a stopping point."

For example:

body {
    color: red;
}

If you place the cursor after "{" and press Ctrl+Right, most editors will move the cursor to col 0 on the next line. CodeMirror moves the cursor to the end of the word "color" instead.

Assuming Ctrl+Del follows the same "stopping point" logic as Ctrl+Right, fixing this would fix the bug adobe/brackets#6860 as originally reported.

2) But in some editors at least, Ctrl+Del stops earlier than Ctrl+Right would. In the above code, put the cursor at col 0 of the middle line. In Sublime, Ctrl+Right jumps to the end of "color" but Ctrl+Delete removes chars only up to the start of "color." I'm guessing in this case Ctrl+Delete is driven by the select-word logic (i.e. the range that would get selected if you double-click -- sans the part to the left of the cursor).

If that's truly a behavior common across most editors (and not just some Sublime thing), then maybe this could be fixed by changing Ctrl+Delete to use select-word as its boundary guide rather than the Ctrl+Right stopping points.

[marijnh]

I don't think there is a 'behavior common across most editors' here, we should just give up on that concept.

But if the goal is to do what Sublime Text does (which isn't unreasonable), attached patch should address the issues raised here. By-group motion will now always stop after newlines, and consider runs of more than a single whitespace character their own "group", and stop after them.

Deletion and movement in CodeMirror use the same algorithm. I really would like to keep it that way (easier to predict, less code).

[peterflynn]

@marijnh I wouldn't say imitating Sublime is my goal, personally. In the original forum thread where I did the research, there was remarkable consistency among "modern"/GUI-based editors: IntelliJ/WebStorm, Eclipse, Visual Studio, Notepad++, Sublime, ACE/Cloud9, and Coda all follow the stop-at-newlines behavior I described above, iirc.

Thanks for the speedy patch, in any event! The new behavior definitely feels nicer to me. I could imagine the differing treatment of 1 space vs. 2+ spaces feeling weird for some users (I'm not aware of other editors that use that heuristic). So far it hasn't seemed too noticeable in my usage, but on the other hand I don't tend to work with e.g. column-aligned code where multiple spaces between tokens are common. I guess just something to keep an eye on...

Thanks again!

[peterflynn]

Or rather, I should say -- I'm not aware of editors where 1 space vs. 2+ spaces makes a difference for Ctrl+Left/Right navigation. As you pointed out though, those cases do differ for Ctrl+Delete, at least in Sublime (i.e. Ctrl+Delete and Ctrl+Right don't behave the same). I'm not sure if that Ctrl+Delete behavior is consistent with any other editors.

[peterflynn]

Fwiw, I looked at a view editors and there's a bit of a split:

• Sublime, Coda, TextMate -- Ctrl*+Delete behaves differently for 1 space vs. 2+. In Coda and TextMate (but not Sublime), Ctrl+Right shares this difference -- just like CM master.
• IntelliJ/WebStorm, Notepad++, Eclipse, ACE/Cloud9 -- Ctrl+Delete treats any number of spaces the same (as does Ctrl+Right), i.e. spaces are never deleted along with non-space chars.

(* it's actually Alt+Delete on Mac, of course)

So the current CM behavior (after the patch here) does have precedent after all.

[marijnh]

Okay. I'm going to say 'close enough' and close this then.

[peterflynn]

Works for me, too! Thanks again.