vim-surround icon indicating copy to clipboard operation
vim-surround copied to clipboard

bug in "cs" and "ds" when newline before close-brace and none after open-brace

Open jpassaro opened this issue 8 years ago • 0 comments

Best illustrated with examples. In all examples below, quoted command is executed with the cursor on the word arg2.

# errortext
process_args({arg1,
              arg2
             })
# errortext after `cs}]`
process_args[arg1,
             arg2]({
             })
# errortext after `ds}`
process_argsarg1,
arg2({
             })

Both are obviously wrong. Similar results with different braces, using { instead of }, using cS instead of cs, etc.

Here are some control texts where the commands function normally:

# control1
process_args({arg1,
              arg2})
# control2
process_args({
    arg1,
    arg2
})

Here's where I think this is going wrong. Refer to plugin/surround.vim in current head (e49d6c2).

The first discrepancy between control texts and errortext occurs on line 396, which executes di} while the cursor is on arg2. This removes the block with arg1,\n arg2. In both control texts, after di}, the cursor is on the right brace; I believe this to be an assumption of the script. In errortext, the cursor winds up on the left brace after di}.

On line 424, as a prelude to da} on the next line, we move one character left. In errortext, the subsequent da} fails and all bets are off. This seems the logical place for a workaround -- i.e. to suppress the left-motion if the cursor happens to fall on the left brace.

I've got a draft of this workaround. But before I submit a pull request -- this discrepancy is kind of surprising! Why do these different cases of diw leave the cursor in different locations? Does anybody know if this is documented vim behavior, or a semi-intuitive corner case, or something that should be considered a vim bug? Dropping a note on the vim user list to find out and I'll report back if I glean anything useful.

jpassaro avatar Nov 23 '16 19:11 jpassaro