There's a new field in the find in files panel, which can be used to limit the files searched. Multiple wild card patterns can be used by separating them by semicolons (e.g., ".h;.cpp"). Prefixing a wild card pattern with a minus will result in it being used as an exclusion, e.g., "*.txt;-readme.txt".

F4 will now either go to the next find result, or the next build error, depending on which panel was used last. Shift+F4 goes to the previous result.

I noticed an inconsistency in minimap behavior depending on the value of clickToScroll. If it's set to "position" you can click outside the view and then drag to move. However, if it's set to "text" then click-then-drag won't move it.

I also have problems since the last beta (or the one before I believe), when I use find/find&replace with "search in selection" enabled (it's always on here), it doesn't work anymore if there is no selection, and sometimes screws up completely and even doesn't find anything within the selection. Once it found the first result in the file, which was out of the selection, and that was it.

Seladek: Search in selection does indeed work differently since the previous beta. The key difference is that now the area that it searches in is the selection as of when the find panel was opened. In the past it didn't work properly with find next.

ifni: There isn't an option for it, it should always be on. Is it not working for you at all, or just inconsistently?

ifni: There isn't an option for it, it should always be on. Is it not working for you at all, or just inconsistently?

It seems to work inconsistently. If you look at this image it seems related to the 'Unable to open...' string above the results (check out my 1337 mspaint skillz)So if I attempt to open a result that was proceeded by an 'unable to open' string, it fails, otherwise it works. It seems to apply to the entire set of results for a single file.

On a related note, is there any way to suppress those 'unable to open' messages? My projects have a lot of empty init.py files, which it fails to open, and it fills up the find in files buffer with unhelpful information.

But it would be nice to be able to double click a search result and load that file at the found line number.

Also there appears to be a bug that if a file is 0 length the a error is generated that it was unable to open the file. It is one thing if you can't open the file, it is another if you can open the file but there is no contents to search.

We use some 0 length files to enforce a directory structures in perforce.

otake, rbabiak: yeah, there's a bug in this version that's causing double clicking in the find results to not work as expected when there's a 'Unable to open...' message on the preceding line. It'll be fixed in the next beta.