Find with collapsed folds

[Vicente]

Hello,

i found an issue when using the Find tool from the Search menu (Ctrl+F) with collapsed folds.

The easiest way to reproduce that i found is:

1.- Open a .c file so that the language is autodetected as "C / C++".

2.- Ctrl+Shift+Right-click on the fold margin in order to collapse all folds.

3.- Ctrl+F to open the Find strip.

4.- Type anything.

What happens is that all folds get openned, but the ones at the top level keep the "+" and the horizontal line indicating that it is closed.

The issue goes beyond that, but i don't know how to deterministically reproduce that, at every edit on the Find strip:

1.- the folds get openned and closed

2.- the file view scrolls at random positions

3.- the cursor moves

4.- the currently selected area changes

Those issues are found on Version 5.2.1   Scintilla:5.2.1   Lexilla:5.1.5  compiled for GTK:3.24.33 with the default SciTE.properties. It is reproducible on both X11 and Wayland.

Regards,

  Vicenç.

[Neil Hodgson]

Vicente:

> 2.- Ctrl+Shift+Right-click on the fold margin in order to collapse all folds.
> 3.- Ctrl+F to open the Find strip.
> 4.- Type anything.
> What happens is that all folds get openned, but the ones at the top level keep the "+" and the horizontal line indicating that it is closed.

This is caused by folding and filtering fighting. Both features want to hide and show lines in the file. When a find is performed in find or replace, any filtering is first removed which is done by showing all lines. This occurs even in the find strip which, unlike the replace strip, doesn’t include a filter option. The filter code believes it is in control of line visibility so doesn’t update the fold header states when it shows the lines.

Different fixes may be needed for different modes. It may be possible to fix finding by never performing a filter removal while the find strip is present. The replace strip is more complex as it includes filtering options. Its unlikely anything will be fixed by the next release.

Neil

[Vicente]

Hi Neil:

On Thursday, March 24, 2022 at 4:19:03 AM UTC+1 Neil Hodgson wrote:

This is caused by folding and filtering fighting. Both features want to hide and show lines in the file. When a find is performed in find or replace, any filtering is first removed which is done by showing all lines. This occurs even in the find strip which, unlike the replace strip, doesn’t include a filter option. The filter code believes it is in control of line visibility so doesn’t update the fold header states when it shows the lines.

Different fixes may be needed for different modes. It may be possible to fix finding by never performing a filter removal while the find strip is present. The replace strip is more complex as it includes filtering options. Its unlikely anything will be fixed by the next release.

What is filtering in that context? if this is related to the incremental option, it is disabled in the global properties file:

find.strip.incremental=0
replace.strip.incremental=0
 

Just tested disabling the strips:

find.use.strip=0
replace.use.strip=0

and it works, as a workaround.

Regards,

  Vicenç.

[Neil Hodgson]

Vicente:

> What is filtering in that context?

Filtering is the “Filter” command in the “Search” menu and the 3rd (“Filter") and 4th (“Context”) icon buttons in the replace strip. While the find strip doesn’t have these buttons, it shares most code with the replace strip.

There is a simple attempt at blocking this problem in the patch at
https://sourceforge.net/p/scintilla/scite/ci/fc8c3e68704a72c9cdf1e2b63e766b74b7e385eb/
It doesn’t try to fix the issue for the replace strip.

The macOS version unfolds the whole document before running the find or replace strip then restores the previous folding (where possible) after closing these strips. This might be a reasonable approach to fixing the replace strip. Another approach would add a property to disable filtering in the replace strip.

Neil

[Vicente]

I've just tested the upcoming 5.2.2 that includes the fix.

It works fine.

Thank you!