SlickEdit Community

Archived Beta Discussions => SlickEdit 201x Beta Discussions => SlickEdit 2018 v23 Beta Discussion => Topic started by: b on October 12, 2018, 10:57:51 PM

Title: Love the new vi support in RC1, but...
Post by: b on October 12, 2018, 10:57:51 PM
di" da" di' da' work wonderfully.

di< da> (and variants) are problematic.  same with di( and variants.

Example,

#include <stdio.h>

if I place the cursor anywhere within stdio.h (not the 's'), SE will display the error in the command bar "Not begin/end or paren pair, There is no active selection".    (This works within vim the same as the quotes).

Now, the oddity, if you place the cursor on the first character after the opening '<' (in this case the 's'), di< will delete the contents, but leave the 's' in the brackets.  da< will delete the string and the closing '>' leaving just the '<'.

Title: Re: Love the new vi support in RC1, but...
Post by: Clark on October 13, 2018, 03:42:31 AM
This issue with paren/bracket commands doesn't seem to be new (could be like a decade old). There seems to be a problem when the parens/brackets appear in a string or comment (not sure why). When the parens/brackets are outside of a comment or string, it works fine. We will look into this.

The string handling for things like di" is slightly different than VIM. In the case your cursor is inside an element color coded as a string, it doesn't really matter whether you type di", di', or di`. The results are the same. Multi-line strings are supported for this case. In addition, even if the string element doesn't start/end with quotes it will work reasonably. For example, the "#include <sdfsdf>" case works reasonably with di" when the cursor is inside the <> string (although it's treated like da" because the code's a bit lost).