Multi-line "Find in Files" searching

[chrisgraham]

It would be very useful to be able to search across multiple lines in "Find in Files". This doesn't work using patterns (\n) or by pasting in the line break character.

I realize this is all because grep doesn't really support multi-line searches, and it would be difficult to implement this request.

It might be possible to add support for pcregrep to do what we need, with Geany complaining if you are searching for a linebreak-containing string and there being no pcregrep installed.

Or, we could dump grep and move find in files internally, using the same engine as the current Find feature.

[elextr]

Glib contains regexen support and directory reading and file reading, so it would be a mere matter of programming to implement the search in Geany and do away with grep (which isn't available on windows by default, and isn't neccessarily GNU grep on BSDs etc.).

Just "somebody" has to do it :)

[ntrel]

I think you could already set pcregrep as the grep tool in Preferences. Then in the other options entry [of find in files] you can add any necessary flags for multi-line matching.

[ntrel]

to implement the search in Geany and do away with grep

That would basically have to reimplement grep. People can pass custom options, we don't know which extra ones they use. I don't think this is an effective use of time.

(which isn't available on windows by default,

I think it's bundled with the installer.

and isn't neccessarily GNU grep on BSDs etc.).

Is there a problem on BSD with any of the wrapped grep options?

[chrisgraham]

I think you could already set pcregrep as the grep tool in Preferences. Then in the other options entry [of find in files] you can add any necessary flags for multi-line matching.

Thanks, I wasn't aware of the option. It almost works, but I had to tweak the code:
chrisgraham@bff6c99
(maybe someone would like to merge this change if it looks okay?)

The only other remark is the exclude-dir and exclude and include syntax works via regexps not globbing (regexps is nicer IMO). So the user will need to change how they fill in the custom files filter, and their extra options.

As for whether we should use grep... I can see both sides of it, especially knowing I now can use pcregrep. I don't see why it would be hard to do this internally though, given that Geany already implements regexp searching of files. What's the big difference if it can do what it already does enumerating over a project directory? Possibly people are using some exotic options. For me, all I do is specify what directories/files to exclude, which already is a project property.

[ntrel]

It almost works, but I had to tweak the code:

Ok, thanks. Looks good, I didn't realize pcregrep doesn't have an -E option.

The only other remark is the exclude-dir and exclude and include syntax works via regexps not globbing

Hmm, it's frustrating that they repurposed those options, it's so close to being a drop in replacement. (They could have added regexp file matching with different option names). We could just disable the file filter row when pcregrep is set.

As for whether we should use grep...
I don't see why it would be hard to do this internally though, given that Geany already implements regexp searching of files

It doesn't. Geany loads files into scintilla. It would be simple to implement trivial file searching, but grep and pcregrep have many optimisations vs simple linear search and reading entire files into buffers.

Possibly people are using some exotic options

Yes, I expect we would struggle with this. For example, pcregrep has an option to treat lone CR or LF as a new line.

[chrisgraham]

Thanks.

To clarify, I don't consider the difference in include syntax a problem. After my patch, everything works, it's just the user has to type in different syntax. I think it works great, I like the additional control you get with /s/globs/regexps.

EDIT:
Also I had to make another change:
chrisgraham@7d768ac
as there's a better command pcre2grep. The backtracking is not properly configurable on pcregrep.

EDIT:
Also I'd like to point that pcregrep/pcre2grep/grep will not enumerate the filesystem in sorted order, meaning results are not sorted. It would be hard to fix when using these tools, so is another factor to consider.

[ntrel]

I'm now working on this, starting from your commits. I think -M shouldn't be the only regex option for pcre, because sometimes you don't want . to match EOL. The -M option could be manually enabled in the Extra Options field (perhaps we could have 2 or 3 of these fields, each with checkboxes to enable/disable).

To clarify, I don't consider the difference in include syntax a problem

It is, because of the tooltips in the FIF and Project dialogs' file patterns field - *.h *.c. (The Project field can't be changed to regex syntax because I have a PR to use it for a GtkFileFilter in the open dialog).

grep will not enumerate the filesystem in sorted order

Without the recursive option, Geany actually passes the filenames to grep itself. That can be sorted, we could implement recursive filenames too.

[ntrel]

Implementation in #2364.

[ntrel]

Without the recursive option, Geany actually passes the filenames to grep itself. That can be sorted

It actually is sorted already, so just the recursive option sorting needs implementing (which is currently handled by grep).

[chrisgraham]

Cool :).

A couple of notes:

• I do not believe "-M" makes "." match line breaks. My recent test confirms this, unless I'm going crazy. EDIT: It does not, but negative character classes will match line breaks unless a line break is added to the negative class.
• If we're passing in lots of filenames in recursive mode isn't that going to hit some kind of parameter string limit?