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
