Issue #137 invalid

Bug in quote text object: da" or ca" removes surrounding spaces

Takafumi Arakaki
created an issue

Hi, thanks for the great package.

There are two similar cases. I checked with the newest version from the repository (git rev = 5b6e5433a594480e7004fd65eab757fd41cf9a3a) and Emacs 24.0. In the following examples, spaces are replaced by dots for visibility reason.

== Case 1 ==

Original content:

{{{ aaa..."bbb" }}}

Excepted (3 spaces after aaa):

{{{ aaa... }}}

Got (no spaces after aaa):

{{{ aaa }}}

== Case 2 ==

Original content:

{{{ aaa..."bbb"...ccc }}}

Excepted (6 spaces between aaa and ccc):

{{{ aaa......ccc }}}

Got (3 spaces):

{{{ aaa...ccc }}}

See also: https://github.com/timcharper/evil-surround/issues/11

Comments (6)

  1. Frank Fischer repo owner

    As in vim you can use 2di" or d2i" or di2", i.e. providing a count of exactly 2 to the i" text object selects the text and the quotes but no whitespaces.

  2. Frank Fischer repo owner
    • changed status to open

    This is a quote from Vim's doc (and Evil follows these specifications):

    a"							*v_aquote* *aquote*
    a'							*v_a'* *a'*
    a`							*v_a`* *a`*
    			"a quoted string".  Selects the text from the previous
    			quote until the next quote.  The 'quoteescape' option
    			is used to skip escaped quotes.
    			Only works within one line.
    			When the cursor starts on a quote, Vim will figure out
    			which quote pairs form a string by searching from the
    			start of the line.
    			Any trailing white space is included, unless there is
    			none, then leading white space is included.
    			When used in Visual mode it is made characterwise.
    			Repeating this object in Visual mode another string is
    			included.  A count is currently not used.
    

    The textobject a" includes the trailing white space or leading white space. Thus the behavior you describe in both cases is indeed the expected behavior (unless I'm missing something).

    I changed the state to invalid because I found no other state that is more appropriate:

    • open -> I thought I pointed out that the behavior is indeed expected, so I didn't consider the issue as open anymore (sorry if I was wrong)
    • resolved -> Nothing has been changed, but I would imply that some code had been changed in order to call it resolved
    • wontfix -> IMHO it's not a bug because the behavior you describe is the expected behavior (according to the vim docs, unless I'm wrong)

    so invalid was just the one that was closest to "this bug is not a bug". Maybe I was a little fast, sorry for that. I'll leave the issue open for some time for discussion.

  3. Takafumi Arakaki reporter

    Thank you so much and I am sorry I used issue tracker like a newbie question thread! So, should I make it invalid again? Please do it if you want.

    BTW, I didn't mean to reopen the issue at the last time.

  4. Log in to comment