(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Visual Studion code does not keep the old search results in the search pane or provide a drop down list of previous search phrases. (#12184)

Do your files use CRLF line endings? Most likely #36309 (comment)

Yes. Agreed. Is there a recommended workaround? This is a terrible experience for a frequent use case on Windows.

I would go as far as to say that this is totally broken. The best case result is the user doesn't trust Code for regex searching and goes off and uses another tool (my case). And then eventually wastes their time and yours opening a dup issue. The worst case is they proceed on the understanding that a pattern doesn't match and never discover that it really does.

And why is the find in files behavior different if a file is open (i.e. we get a match, step 11 above)? Completely non-intuitive.

Cheap workaround is to insert \s+ before $, for example: ^The.*?:\s+$. But still!

Open files are searched in the editor model using the JS regex engine and there are a couple subtle differences between that and the Rust regex engine used by ripgrep, a tool that that search uses.

I guess #36309 is "\s matches CR" and this is "$ doesn't match CR".

This one we can actually work around automatically by replacing $ with \r?$. That's a hack but sounds like maybe the right thing to do...

A separate issue could be that when invoking Find in Files, the output should be the same regardless of whether a file is open. I understand there is a different engine used by Ctrl+F within a single file, and when using Ctrl+Shift+F across all files, but when using the latter, the output should not change when files are open or closed.

That would be ideal and I wish I could make it work, but if we want to support things like search finding matches in modified files, it's not practical.

It still seems counterintuitive that \r?$ matches more things than $. At first glance, it would seem that the former is a subset (or equal set) of the latter.

It's really foo$ vs foo\r?$ where the first matches nothing because ripgrep doesn't consider \r as matching $.

From my limited understanding, Windows uses CR+LF, or \r\n, but UNIX uses just line feed, i.e. \n. Is ripgrep equating $ with \n? If so, then why does it matter what precedes the line feed? Sorry, just want to understand fully :)

No problem at all. You are exactly right. But from ripgrep's perspective, \r is a character sitting between foo and $ (if the line is foo\r\n, and your regex is foo$).

If the regex doesn't have a match for that character, then the regex engine stops matching when it reaches \r. If we insert an optional \r in that place, then the regex will match.

Of course! Got it :)

Thanks, Rob!

(FWIW, adding support for CRLF line ending support is on my radar for future enhancements to Rust's regex engine, but it will be quite some time before it happens unfortunately.)