Error parsing regex near 'E:\Relea' at character offset 3: Unrecognized escape sequence: '\R'.

[jiangjianshan]

Hello,

I want to combine to use ripgrep and CtrlP together, but meet the following issue as the picure showing:

As you see my setting for the plugin CtrlP. I think the issue is came from the below line

let g:ctrlp_user_command = 'rg %s --files --color=never --glob ""'
The version of ripgrep I'm using is 0.4.0, which is installed from commad 'cargo install ripgrep'.
Is it something wrong for my setting for the rg command or any other reasong to cause this issue?

[BurntSushi]

I think this is a dupe of #326.

[jiangjianshan]

@BurntSushi, I have look through the #326 issue, it seems like it is still open. Below is what I'm try on my Windows 7 SP1 64bit system.

I have already following the instruction on your github website to build ripgrep.

[BurntSushi]

It is indeed still open. But it still looks like a duplicate to me. :-)

[jiangjianshan]

@BurntSushi , I have found a new strange behaviour for command "rg --files [path]"

As you see above, the command "rg --files .\doc" worked at the folder "E:\Releases\lua-5.3.3", but "rg --files .\gnu_regex" not work at folder "E:\Releases\ctags-5.8".
The version of Rust I'm using is 1.14.0, which target is x86_64-pc-windows-msvc.
When I'm using the command "cargo install ripgrep", I have noticed that the version of regex to compile ripgrep is 0.2.1 but not the 0.2 on this github.
I'm still finding the solution for the issue I meet.

[BurntSushi]

The bug is that the file path appears to be interpreted as a regex. If that's true, then your error messages make sense: \d is a valid escape sequence while \g is not.

When I'm using the command "cargo install ripgrep", I have noticed that the version of regex to compile ripgrep is 0.2.1 but not the 0.2 on this github.

ripgrep uses regex 0.2.1.

[jiangjianshan]

@BurntSushi, so what you mean this bug maybe came from regex 0.2.1?

[BurntSushi]

No. It's clearly a bug in ripgrep proper. For some reason, the file path is being parsed as a regex, but it shouldn't be. I haven't had a chance to investigate further.

…

On Jan 23, 2017 21:14, "jiangjianshan" ***@***.***> wrote: @BurntSushi <https://github.com/BurntSushi>, so what you mean this bug maybe came from regex 0.2.1? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#338 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAb34jBuz1xkzn6EZOU4ObwOd5cA4-cNks5rVV6VgaJpZM4LqRkw> .