PR: Split Find in Files module

[rlaverde]

findinfiles/
├── __init__.py
├── plugin.py
├── tests
│   └── test_findinfiles.py
└── widgets.py

[goanpeca]

@rlaverde what is missing here to get tests to pass?

[rlaverde]

what is missing here to get tests to pass?

I forget to move the data used in the tests 🙈

[ccordoba12]

I'd like to make some more improvements to Find in Files before 3.2 is released, so I think we should hold this one until we release 3.2.

[rlaverde]

I'd like to make some more improvements to Find in Files before 3.2 is released, so I think we should hold this one until we release 3.2.

Should I merge master into split-pĺugins, and after that rebase this PR? or how should I bring that changes?

[ccordoba12]

Should I merge master into split-pĺugins, and after that rebase this PR?

Yep, I think that's what you need to do.

[rlaverde]

@ccordoba12 This is ready, I rebased it after the merging of split-plugins with master

[ccordoba12]

@rlaverde, let's take the opportunity to move the classes of widgets.py to different files, like this:

• SearchThread -> utils/search.py
• FindOptions -> widgets/options.py
• LineMatchItem, FileMatchItem, ItemDelegate, ResultsBrowser -> widgets/results.py
• FileProgressBar, FindInFilesWidget -> widgets/main.py

I know this will make merging PRs from 3.x to master much harder, but it's better to do things right in 4.0 to avoid this kind of refactoring in the future.

[ccordoba12]

I've been thinking on my last suggestion. So, the problem with splitting things further and still maintaining the 3.x branch is that it would make merging from 3.x to master or from master to split-plugins a real nightmare!

So a further splitting should be done only after we don't plan to do more 3.2.x releases (probably in six months or so).

@rlaverde, for now, please continue to do things as you've been doing them ;-)

[rlaverde]

So a further splitting should be done only after we don't plan to do more 3.2.x releases (probably in six months or so).

Well, I will open another PR with the split, when this happen, although I think the "double copied merging" trick will work for merging changes (I did that in #4812)

[ccordoba12]

I think the "double copied merging" trick will work for merging changes

Great! But just in case, let's wait until January or so to make further splittings. I think that's not that bad because it's simply more refactoring ;-)