evil-delete-line in visual state

[Frank Fischer]

Thomas Hisch <t.hisch at gmail.com> writes:

Hi Thomas,

> selecting a few lines in visual mode (not linewise visual mode) in vim
> and pressing D not only deletes text inside the selected region but
> also text until the beginning and end of the lines (i.e. D acts
> linewise in visual mode). This does not work in evil, evil-delete-line
> does not delete the whole line in visual state.
> In visual block mode/state "D" should delete text only to the end of
> each line in the block.

This seems to be a non-trivial issue. While the behavior for character
visual mode is easy, the visual-block mode causes more trouble. The
reason is that currently (unless Vegard tells something else ;)) it is
not possible to have a block selection that extends to the end of each
line unless the last (or the first) line is the longest and point is
placed there. Because operators (like `evil-delete') work exactly on
region descriptions and blocks are always rectangular and do not extend
to the end of line, there is currently no way to get the desired
behavior.

The best idea I have is the following (probably more for Vegard than
anyone else ;)). We need to introduce a new "type", say `block-end',
which describes block regions that extend to the end of each line. This
new selection type has to be respected in certain core operators like
`evil-yank' and `evil-delete' (and perhaps in `evil-paste', although I
think this is not necessary if trailing whitespaces are appended to the
short lines in `evil-yank'). Then it should be easy to get D and also C
to work as expected.

Furthermore one could introduce the following (maybe customizable)
behavior for block-visual-state, which is afaik not available in Vim (at
least as default). When point in visual-block is placed on a newline
character at the end of a line, then the selection is regarded as type
block-end instead of block. That way it would be easy to select a block
which extends to the end of the line visually. Not sure if this is
really useful given that the operators D and C work as desired, but
should not be too difficult to implement once the new type is available.

Frank