Move after end of word or Delete after cusor

Question

What is the fastest sequence to delete to the end of line after the cursor position?

Example:

I want to delete this line in a faster way

Sequence: 5eD will delete the last character of the word line

I want to delete this lin

Moving around with vim often put me on the first or last character of a word, forcing me to move by one more keystroke each time I want to delete to the end of line (in the example above, by adding one motion to the right: 5elD). Is there a more efficient way (by moving after the end of word or by deleting after the cursor)?

Answer 1

D is an inclusive command that works over a motion that includes the cursor at one end and the last printable character on the line at the other end. There is AFAIK no built-in way to turn an inclusive command into an exclusive command and vice versa.

The heaviest solution would be to define your own operators and motions/text-objects.

A somewhat lighter solution would be to define mappings for those corner cases.

An even lighter — but boring — solution would be to spend a few more keystrokes in visual mode.

Or, you could simply move in a slightly more "agile" manner:

5f D

Answer 2

There are multiple ways to achieve what you want:

5elD
6f D
6wDx
6whD
# ... probably others too

All these cost you just +1 keystroke.

If deleting starting from current position +1 was possible, then it will make sense to ask for deleting from current position -1 too. It would raise the question about other commands too, for example deleting until the end of the file from the current line +1, -1, and so on.

How can this possibly work? I see only two possible ways:

1. Pass a parameter to the existing commands to modify their behavior with the desired nuance. This will inevitably cost you +1 keystroke, so you won't be better off than what exists already
2. Have a new keystroke for this behavior. Most keys on the keyboard already have something else more important and powerful to do, it would be a very tough choice to assign one of the unused keys for such a small functionality

So, I don't see a way to have something better than the current features :-)

I agree that it's a bit unfortunate that there is no "atomic" command to delete from the next character. I see the practical use of what you're asking: when cutting short a text, I often want to delete starting from a space character, because I don't want to leave trailing whitespace at the end of lines (Git complains about it, for example). And the w and e word jumping commands are not very suitable for this, as w jumps to first letters and e jumps to last letters, and there's no shortcut to jump on the space after a word, except explicit searches like f. So I understand and even share your need. I just don't see where this can be squeezed in the existing functionality.

The best alternative I can think of is to record the action in a macro, let's say d. At the end of a word (on the last letter), record like this:

qdlDq

Then, you can redo this action at the end of another word with @d. To do it repeatedly, you can do @@. When doing it repeatedly this is faster to type than lD, but this might depend on your taste. If you don't do it repeatedly then the macro doesn't really help, as it's the same number of keystrokes anyway (+ the creation of the macro).

Answer 3

Probably not the shortest keystroke-wise, but I'd do it this way:

/ i<Enter>D

Unless you're trying to automate something, counting the number of words required for the motion is just more difficult than trying to aim to the exact location you want: the first space after the last word you want to keep.

So that's two more keystrokes, but if you're on a much longer line it will still work the same, and if you have search highligting enabled, you can make sure your motion is aiming at the right location and add a few characters if there are several matches. Not the fastest to type, but easier to apply to similar situations and long lines, and asking less thinking to the user (machines are good at counting, humans are not).