Ctrl+Del behaviour is different from other editors

[DickvdBrink]

See my gif; I did test this on a Windows machine with a TypeScript file
I didn't expect it to remove the // or the . when pressing ctrl+del
If this is the right behaviour, feel free to close :)

[EthraZa]

On Linux it's doing the same. I too would expect a ctrl+del (or ctrl+d?) to
remove the line, not remove the next element.

2015-11-30 17:58 GMT-02:00 Dick van den Brink notifications@github.com:

See my gif; I did test this on a Windows machine with a TypeScript file
I didn't expect it to remove the // or the . when pressing ctrl+del
If this is the right behaviour, feel free to close :)
[image: ctrl del]
https://cloud.githubusercontent.com/assets/765657/11482759/f0538eaa-97a4-11e5-9275-34bd81ab11c2.gif

—
Reply to this email directly or view it on GitHub
#832.

[DickvdBrink]

Hmz, I would have thought it would do the same as it did on first line (function test) so only remove the whitespace

edit To clarify, I would expect it to remove white space only, because of my cursor position. If it was at the beginning of the word it it does remove it (like expected)

[DerTolleEmil]

This has been annoying me for quite a while now but I forgot to open an issue once it was published on github.

The behavior is especially weird not only because it behaves differently from any other editor I know but also because it is inconsistent if you ask me.

Pressing ctrl+del will delete the following word until it detects a double quote for example leaving the quote intact (ie $var = ooops"value"; will delete ooops only) but it will delete the quote if it is only removing white spaces. Detection up to which point text should get deleted is therefor inconsistent as well in my opinion.

[ctlajoie]

This one has been irritating to me as well. IMO Sublime Text has the most sane ctrl+del behavior. That is:

• if next char is not whitespace: delete word (with reasonable separators)
• if next char is whitespace (non-newline): delete whitespace up to next word or newline
• if next char is newline: delete 1 newline

In addition to its weird definition of "word" as @DerTolleEmil pointed out above, Code eats whitespace + 1 word when the next char (to the right of the caret) is whitespace (newline or not).

[glen-84]

+1 This is bizarre behaviour.

[alexdima]

I also hate it :)

[alexdima]

Done with b505eac.

[DickvdBrink]

Thanks! Think I'm going to refresh my custom build for VSCode! Thanks again!

[DickvdBrink]

@alexandrudima, I tried to build from source today and the behavior didn't match that of Visual Studio, is that by design?
For example
<cursor here> }
Pressing ctrl+del with the above code still removes the } while VS2015 doesn't - VS only removes the whitespace.

[ctlajoie]

Based on a quick look at the referenced commit (b505eac) I believe the change only affects ctrl+backspace behavior and not ctrl+del. Since this issue is now closed it might be best to make a new issue and reference this one.

[alexdima]

I adopted the new logic over multiple commits, abfaf52 adopts the new logic for Ctrl+Delete. The new logic does the following:

• If there is a single whitespace, then it deletes the whitespace + the next word
• If there is > 1 whitespace, then it deletes the whitespace

[alexdima]

e.g.:

|   /* Just some text a+= 3 +5-3 */  
|/* Just some text a+= 3 +5-3 */  
| Just some text a+= 3 +5-3 */  
| some text a+= 3 +5-3 */  
| text a+= 3 +5-3 */  
| a+= 3 +5-3 */  
|+= 3 +5-3 */  
| 3 +5-3 */  
| +5-3 */  
|5-3 */  
|-3 */  
|3 */  
| */  
|  

[ctlajoie]

Ahhh got it. That actually makes good sense.

[glen-84]

| +5-3 */
|5-3 */

This is not right. It's the same as the example provided by @DickvdBrink. It should not remove the +.

[alexdima]

@glen-84 The difference is 1 whitespace vs >1 whitespace.

There is only 1 whitespace in this case:

| +5-3 */

and >1 whitespace in this case:

|   /* ...

[glen-84]

@alexandrudima,

I understand that, but it doesn't follow the behaviour of other editors like VS and Programmer's Notepad, and is not really intuitive IMHO.

Edit: And Eclipse as well.

[alexdima]

Here is VS:

|   /* Just    some text a+= 3 +5-3 */  
|/* Just    some text a+= 3 +5-3 */  
|Just    some text a+= 3 +5-3 */  
|some text a+= 3 +5-3 */  
|text a+= 3 +5-3 */  
|a+= 3 +5-3 */  
|+= 3 +5-3 */  
|3 +5-3 */  
|+5-3 */  
|5-3 */  
|-3 */  
|3 */  
|*/  

[ctlajoie]

@glen-84 I admittedly haven't tried it yet, but I think it makes sense... there's no reason to use use ctrl+del or ctrl+bksp unless you want to remove more than one character at a time. And if you're holding them down or repeatedly pressing them you probably won't even notice because you just repeat the action until you have the result you want (in other words, you don't count the number of times you press it).

I'll try it out tomorrow, but this is my initial thoughts on it...

[alexdima]

I personally don't have a strong feeling about it, we can go and do what VS does, which in a way is nicer as it always deletes until the beginning of a word (not until the end of a word).

[glen-84]

@ctlajoie It's just easier to work with, as you don't want to have to count the spaces and then use a different key combination depending on how many there are, to avoid deleting too many characters.

@alexandrudima Yes, other editors have the same behaviour, and it's more intuitive for the key combination to perform one logical action, instead of varying it.

[ctlajoie]

@alexandrudima The way VS does it isn't necessarily better if you want to delete a word to replace it with another word.
If the new implementation isn't to everyone's liking, I would suggest doing what Sublime Text does... which is the same as your new implementation minus the 1 whitespace caveat.
Nevermind... that is not what ST does.

[alexdima]

I suggest to for now the current behaviour and get more feedback on it before changing it to the VS way.

[glen-84]

The way VS does it isn't necessarily better if you want to delete a word to replace it with another word.

Then you just have to tap delete twice (while holding down ctrl).

IMHO, it makes sense to follow what other editors do. Even WordPad has this behaviour.

[alexdima]

Given I didn't get any other negative feedback on the (new) current behaviour, I suggest to close this issue, since the initial bug is fixed.

[glen-84]

There's no sad face reaction. 😞

[alexdima]

@glen-84 I just pushed new word commands that allow, through the use of custom keybindings.json to pick which behaviour you want. Please also see #3577.

To get VS-style Ctrl+Delete, edit your keybindings.json and add:

{ "key":"ctrl+delete",       "command":"deleteWordStartRight",       "when":"editorTextFocus" }

This will overwrite the default:

{ "key":"ctrl+delete",       "command":"deleteWordRight",            "when":"editorTextFocus" }

[glen-84]

Thanks @alexandrudima! =)