Allow consult-grep to use --include

[ErnestKz]

In the upstream master, I noticed, given a conult-grep input of #gnu -- --include *md#, the --incude *md passed to grep by the consult--grep-make-builder has no effect in terms of filtering out files which do not match the include.

To me, using --include to select just the files I want operate on, is the more common use-case.

I hypothesised that this is because the arguments are passed to the end of the flag list of grep, and to test this, I put them at the start, and the --include *md works as expected.

I'm closely looking at this piece of documentation of man grep, which it seems to describe the behaviour.

--include=GLOB
       Search  only  files whose base name matches GLOB (using wildcard matching as described under --exclude).  If contradictory --include and --exclude options
       are given, the last matching one wins.  If no --include or --exclude options match, a file is included unless the first such option is --include.

It must be the following rule which this PR makes use of:

• If no --include or --exclude options match, a file is included unless the first such option is --include

It seems to be true, as something like

• grep --exclude *nonexistent --include *md -r -e gnu . doesn't use the --include flag
• grep --exclude *el --include *md -r -e gnu . does
• grep --exclude *el --exclude *nonexistent --include *md -r -e gnu . does
• grep --include *md --exclude *nonexistent -r -e gnu . does

Actually, now I realise, having an --exclude before an --include, changes the meaning of the succeeding --include entirely.

• An --include which is before an --exclude acts as a "filter everything out, except for the --include"
• An --include after an --exclude acts as "negate the --exclude with what is in the --include" (it does no filtering)

So in the consult-grep interface, we pre-pend the user-defined grep flags with an --exclude, and so the user is limited to the second meaning of the --include.

So either way we decide to insert the user-provided flags, we are compromising a little bit.

This PR contains a little hack to put the user-providing flags at the start .

Is it worth creating a more elegant solution for this?

Maybe there can be an additional -- separator which adds to the end/start, or there can be a way to expose environment variables which the user can splice consult related flags.

[minad]

Thanks. I see your point, but I cannot accept a hack like this. It would be good to find a better solution, and then apply it to consult-ripgrep, consult-grep and consult-git-grep consistently. The first step would be to investigate which options should come first and which should come late, how the different tools compare and so on. Feel free to open a discussion and then we seen how we can proceed with this.