[vim/vim] Have ci[ look for next [ like ci" does for next " (#8670)

[Connor Lane Smith]

In runtime/doc/todo.txt is a known issue:

"ci[" does not look for next [ like ci" does look for next ".
(J.F. 2017 Jan 7)

For instance, if you are at the beginning of a line that reads #include "foo.h" then ci" will change the contents of the string, but if it reads #include <foo.h> then ci< will fail to find and change the contents of the angle brackets.

This patch has ci[ search forward for a bracket like ci" does.

There are two commits. The first is sufficient for a plain i[ or 1i[, but behaves a little strangely with numbers greater than 1. Specifically, di[ before a[b[c]d]e leaves a[]e, and 2di[ leaves a[b[]d]e, but any odd does the same as 1, and any even 2. This is just an artefact of the way it searches for a match. i" doesn't have this problem as 2+ is just a single special case.

The second commit fixes this so that 3i[ for example will enter the third nested bracket it finds, in a sort of inside-out version of what it would do if you were inside the brackets rather than outside of them. A higher number than there are nested brackets will fail. It's not entirely clear that this is the ideal behaviour, and it's a bit more code which is why I've kept it separate, but it seemed fairly reasonable.

This patch does not handle tag-blocks (it), only 'regular' blocks of '(', '{', etc.

Please let me know if there are any issues. Thanks.

---

You can view, comment on, or merge this pull request online at:

  https://github.com/vim/vim/pull/8670

Commit Summary

• Have ci[ look for next [ like ci" does for next "
• Treat c2i[ outside and before [[]] as ci[ inside inner brackets

File Changes

• M src/search.c (2)
• M src/textobject.c (23)

Patch Links:

• https://github.com/vim/vim/pull/8670.patch
• https://github.com/vim/vim/pull/8670.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[Yegappan Lakshmanan]

@yegappan commented on this pull request.

Can you add a test for this change?

[Connor Lane Smith]

@cls pushed 1 commit.

• 556f4b5 Add Test_textobj_find_paren_forward to test_textobjects.vim

—
You are receiving this because you are subscribed to this thread.

View it on GitHub or unsubscribe.

[Connor Lane Smith]

I've added a test, though I'm not especially familiar with Vimscript so hopefully it's acceptable. Running the test locally, it passes with my changes and fails without.

[Yegappan Lakshmanan]

Hi,

On Fri, Jul 30, 2021 at 9:26 AM Connor Lane Smith <vim-dev...@256bit.org> wrote:

I've added a test, though I'm not especially familiar with Vimscript so hopefully it's acceptable. Running the test locally, it passes with my changes and fails without.

Thanks for adding the test. The test looks good to me.

Regards,

Yegappan

[vim-dev ML]

Hi,

On Fri, Jul 30, 2021 at 9:26 AM Connor Lane Smith ***@***.***>

wrote:

> I've added a test, though I'm not especially familiar with Vimscript so
> hopefully it's acceptable. Running the test locally, it passes with my
> changes and fails without.
>
>
>
Thanks for adding the test. The test looks good to me.

Regards,
Yegappan

[codecov[bot]]

Codecov Report

Merging #8670 (556f4b5) into master (c9e7e34) will decrease coverage by 87.60%.
The diff coverage is 0.00%.

@@             Coverage Diff             @@

##           master    #8670       +/-   ##

===========================================

- Coverage   90.06%    2.46%   -87.61%     

===========================================

  Files         150      148        -2     

  Lines      169172   164990     -4182     

===========================================

- Hits       152372     4072   -148300     

- Misses      16800   160918   +144118     

Flag	Coverage Δ
huge-clang-none	?
huge-gcc-none	?
huge-gcc-testgui	?
huge-gcc-unittests	2.46% <0.00%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/search.c	0.00% <0.00%> (-92.59%)	⬇️
src/textobject.c	0.00% <0.00%> (-92.41%)	⬇️
src/float.c	0.00% <0.00%> (-98.91%)	⬇️
src/gui_gtk_f.c	0.00% <0.00%> (-97.54%)	⬇️
src/match.c	0.00% <0.00%> (-97.15%)	⬇️
src/crypt_zip.c	0.00% <0.00%> (-97.06%)	⬇️
src/evalbuffer.c	0.00% <0.00%> (-97.01%)	⬇️
src/sha256.c	0.00% <0.00%> (-96.94%)	⬇️
src/textprop.c	0.00% <0.00%> (-96.69%)	⬇️
src/cmdhist.c	0.00% <0.00%> (-96.67%)	⬇️
... and 138 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c9e7e34...556f4b5. Read the comment docs.

—
You are receiving this because you commented.

[Gabriel Dupras]

I tried your patch and I've noticed a difference in behavior when comparing di[ with di".

With the cursor on the first line:

1
2
[
3
4
5
]
6

doing di[ gives

1
2
[
]
6

So di[ also searches below and above the current line. However di" only searches the current line. With the cursor on the first line:

1
2
"
3
4
5
"
6

doing di" does nothing.

I don't mind but I thought I would point it out, especially since you don't have tests with multiple lines.

—
You are receiving this because you commented.

[Bram Moolenaar]

di" and di[ work differently, because the double quote does not indicate a direction. Therefore it only works in one line, assuming that the first double quote in the line is the start of the object. For a square bracket we can start anywhere, and know that [ is the start and ] is the end.

—
You are receiving this because you commented.

[Bram Moolenaar]

Closed #8670 via b9115da.

—
You are receiving this because you commented.