Re: 'nowrapscan' breaks searching within fold

... I would argue that the current behavior is correct. Suppose there are no folds and there is one occurrence of foo . Then /foo moves to that foo when

Message 1 of 6
, Jan 11, 2013

0 Attachment

Christian Brabandt wrote:

> On Mi, 09 Jan 2013, Ben Fritz wrote:
>
> > This seems to be related to the cursor being within the fold.
>
> Yes, the source code says this:
>
> /* If the cursor is in a closed fold, don't find another match in the same
> * fold. */
> if (dirc == '/')
> {
> if (hasFolding(pos.lnum, NULL, &pos.lnum))
> pos.col = MAXCOL - 2; /* avoid overflow when adding 1 */
> }
>
> This means, the search starts actually after the fold. Because wrapscan
> applies, Vim will start searching from the beginning of the file again
> and find the match and open the fold. If wrapscan is not set, this will
> abort since the pattern is not found.

I would argue that the current behavior is correct. Suppose there are
no folds and there is one occurrence of "foo". Then /foo moves to that
"foo" when 'wrapscan' is set, also when the search is repeated. When
'wrapscan' is off then the second search fails.

In a closed fold it's like the cursor is already at the "foo" inside it.
When 'wrapscan' is set /foo finds it again. When 'wrapscan' is off it
doesn't find another foo and fails.

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Ben Fritz

... I don t like this, it s very unexpected. Especially if searching opens folds, users expect that searching looks inside folds. Also, we can get to some

Message 2 of 6
, Jan 11, 2013

0 Attachment

On Friday, January 11, 2013 3:24:24 PM UTC-6, Bram Moolenaar wrote:

> Christian Brabandt wrote:
>
> > This means, the search starts actually after the fold. Because wrapscan
>
> > applies, Vim will start searching from the beginning of the file again
>
> > and find the match and open the fold. If wrapscan is not set, this will
>
> > abort since the pattern is not found.
>
>
>
> I would argue that the current behavior is correct. Suppose there are
>
> no folds and there is one occurrence of "foo". Then /foo moves to that
>
> "foo" when 'wrapscan' is set, also when the search is repeated. When
>
> 'wrapscan' is off then the second search fails.
>
>
> In a closed fold it's like the cursor is already at the "foo" inside it.
>
> When 'wrapscan' is set /foo finds it again. When 'wrapscan' is off it
>
> doesn't find another foo and fails.
>

Create a file with "foo" only in one place. Fold the text surrounding "foo". Place the cursor on the fold and search for "foo". Search hits bottom without matches, and with your explanation above, I suppose that's expected. Searching again with "n" obviously finds nothing again.

But the cursor doesn't move. So searching with N also will fail, hitting the top with no matches.

So now we have a situation where "foo" exists in the file but can never be found by a search in either direction without first moving the cursor off the fold.

I think it is far less surprising, and more helpful, to start forward searches just before the fold, and backward searches just after the fold, to find anything inside the fold right away.

Also note that the search() function does NOT act in this way. Placing the cursor on the fold and doing :call search("foo") does not open the fold, but doing zv after that shows the cursor is now on the match inside the fold. I think it is also more intuitive if the search() function does the same as / searches as much as possible.

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Ingo Karkat

... I agree. In my mental model, folding is just a visual grouping that may affect the scope of certain modifications (e.g. :.substitute works on all lines of

Message 3 of 6
, Jan 14, 2013

0 Attachment

On 12-Jan-13 08:36:38 +0900, Ben Fritz wrote:

> On Friday, January 11, 2013 3:24:24 PM UTC-6, Bram Moolenaar wrote:
>> Christian Brabandt wrote:
>>
>>> This means, the search starts actually after the fold. Because
>>> wrapscan
>>
>>> applies, Vim will start searching from the beginning of the file
>>> again
>>
>>> and find the match and open the fold. If wrapscan is not set, this
>>> will
>>
>>> abort since the pattern is not found.
>>
>>
>>
>> I would argue that the current behavior is correct. Suppose there
>> are
>>
>> no folds and there is one occurrence of "foo". Then /foo moves to
>> that
>>
>> "foo" when 'wrapscan' is set, also when the search is repeated. When
>>
>> 'wrapscan' is off then the second search fails.
>>
>>
>> In a closed fold it's like the cursor is already at the "foo" inside
>> it.
>>
>> When 'wrapscan' is set /foo finds it again. When 'wrapscan' is off
>> it
>>
>> doesn't find another foo and fails.
>
> I don't like this, it's very unexpected. Especially if searching opens
> folds, users expect that searching looks inside folds.
>
> Also, we can get to some paradoxical behavior with 'nowrapscan' set.
>
> Create a file with "foo" only in one place. Fold the text surrounding
> "foo". Place the cursor on the fold and search for "foo". Search hits
> bottom without matches, and with your explanation above, I suppose
> that's expected. Searching again with "n" obviously finds nothing
> again.
>
> But the cursor doesn't move. So searching with N also will fail,
> hitting the top with no matches.
>
> So now we have a situation where "foo" exists in the file but can
> never be found by a search in either direction without first moving
> the cursor off the fold.
>
> I think it is far less surprising, and more helpful, to start forward
> searches just before the fold, and backward searches just after the
> fold, to find anything inside the fold right away.
>
> Also note that the search() function does NOT act in this way. Placing
> the cursor on the fold and doing :call search("foo") does not open the
> fold, but doing zv after that shows the cursor is now on the match
> inside the fold. I think it is also more intuitive if the search()
> function does the same as / searches as much as possible.

I agree. In my mental model, folding is just a visual grouping that may affect
the scope of certain modifications (e.g. :.substitute works on all lines of the
current fold), but it never actually hides text from commands, just from view.
I'd also except a search to always find text inside a fold.

-- regards, ingo

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Your message has been successfully submitted and would be delivered to recipients shortly.