Thomas Hisch <[email protected]> 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 _______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
